Beveiliging
Pagina: « vorige 1 2 3 4 volgende »
Inderdaad het is in dat soort gevallen (ongevraagd fouten opsporen) slim om de mensen liever dom dan geinformeerd te laten. Meestal is hun ego aangestast of willen het niet erkennen. Maar jij (wie de hack doet) is in principe wel in overtreding.
@Dem,
Misschien wil Chris wel dat je het perse via de pay-by-tweet methode doet, anders had hij hem hier wellicht zelf zo gedeeld.
extra rijen bij de tabel 'users':
Bruteforce_pogingen // maximaal 5
Bruteforce_datum // als er 5 pogingen zijn wordt de datum ook meegegeven.
Bruteforce_ip // slaat het ip adres op als er 5 keer een verkeerde wachtwoord is opgegeven.
Zou ik nog iets kunnen doen?
Met cookies of sessies kan ik niet werken?
Ik zou misschien ook een extre tabel kunnen maken?
Toevoeging op 16/05/2012 15:12:11:
@Chris, heb me bericht aangepast.
Chris op 16/05/2012 15:02:00:
Op een aantal sites, die ik hier helaas niet kan vermelden vanwege de gebruikersvoorwaarden, zijn volledige fora's met subcategorieën die zelfs je wildste dromen waar maken. Het zijn volledige tutorials, soms zelfs met een video waarop je in het (soms gebrekkig) Engels extra info krijg. Je hoeft daar niets voor te downloaden en is dus veilig.
Ik heb het over downloaden gehad, omdat die SQL tool goed werkt, en site's waar je dit kunt geen localhost ondersteunen.
En 'is dus veilig' lijkt me geen juiste opmerking voor iemand die audits doet. Ondanks dat ik niks download, kun je nog tracking cookies, trojans, malware binnen te krijgen zonder ook maar iets te downloaden. Nomaals denk aan het NU.nl verhaal, mensen die alleen de hoofdpagina laden waren al de pineut (met verouderde java of flash versies).
Chris op 16/05/2012 15:02:00:
Gezond verstand houden op iedere website is een goede gedachte, en een virusscanner is voor de meeste sites voldoende. Als je je toch niet veilig genoeg voelt, doe je goed aan een volledig geïsoleerde sandbox door middel van bijvoorbeeld VMWare. Binnen die virtuele omgeving kun je dus dingen downloaden om te testen.
Dan houden nog steeds 'hacker sites' die niet uit zijn op informatie delen (maar wel gedeeltelijk doen om je te lokken), niet je IP loggen en vervolgens alles wat via dat IP naar buiten gaat ook maar gelijk even aanvalt.
Chris op 16/05/2012 15:02:00:
Ik ben overigens blij dat je het idee van de tweet begrijpt, én waarom ik hier niet alles ga neerzetten.
Uiteraard kennis is macht ;)
Gewijzigd op 16/05/2012 15:16:14 door Chris PHP
ik heb ook al eens gehoord dat er een hack manier bestaat die de verbinding tussen database en server kan omleiden naar de hacker zelf, en zo de data kan wegkapen of database wachtwoorden en namen etc. En zo kunnen zelfs SQL query's worden uitgevoerd. Om dit te verkomen hebben sommige webhosts een SSL verbinding.
Verder zijn programmeertalen zoals PHP vanzelf al veilig. Maar PHP kan er bijvoorbeeld niks aan doen als je niet op een veilige manier met data omgaat. Let vooral op als je mensen iets kunnen uploaden op je site!! Dit is heel onveilig als je het niet goed aanpakt! let op de bestandsgrootte, bestandextensies, en "scan" het bestand op schadelijke tekenreeksen (schadelijke scripts).
Als mensen bijvoorbeeld op je site een profielfoto kunnen uploaden, maar ze uploaden het bestand "bom.exe" dan zie je vanzelf dat dit geen afbeelding is...
Gewijzigd op 16/05/2012 15:16:33 door Obelix Idefix
Dan zal de 'hacker' toch nog steeds een SQL account moeten hacken om queries te mogen uitvoeren. Je kunt niet gewoon bladeren in een database als je er verbinding mee hebt. Je zult toch echt eerst moeten inloggen.
Als een site op datum A veilig is, kan het dan zo zijn dat een site op datum B niet meer veilig is? Met andere woorden, is eenmaal veilig altijd veilig?
Net wat ik in een vorig reply al zei.
Hackers zijn net inbrekers, als ze binnen willen komen, komen ze dat toch wel. :D
Where there is a will, there is a way.
Als PHP weer een lek 'vindt', dan is het niet veilig.
Het pakket: Acunetix web vulnerability scanner.
Ver uit de beste scanner om lekken te ontdekken. Kijkt bijvoorbeeld naar:
- open poorten
- 404 error (rechten op een map/bestand)
- SQL injecties
- XSS/CSS -> Cross side scripting.
Een tip om de SQL injecties te voorkomen:
http://php.net/manual/en/security.magicquotes.php Magic Quotes zijn géén beveiligingsmiddel, houd hier rekening mee![/modedit]
Gewijzigd op 16/05/2012 15:24:25 door Chris -
@Demian; hier een simpele gedachte voor de anti-bruteforce. Hoop dat je er wat aan hebt: Anti bruteforce bij inloggen
Toevoeging op 16/05/2012 15:23:46:
@Roy; dat is de slechtste tip ooit. Magic quotes zijn al sinds het begin van PHP 4 uit den bozen en worden, thank god, uit de nieuwste PHP versies gehaald. Magic quotes zijn géén beveiligingsmiddel!
En Hosting bedrijven zijn over het algemeen wel goed beveiligd tegen brute force en dictionary attacks
Toevoeging op 16/05/2012 15:25:57:
@Roy,
het pakket is dat een betaalde of gratis versie?
Idd wat Chris zegt, gebruik dan gewoon mysql_real_escape_string() daarvoor.
Tevens geeft je link (php.net) dit aan, zegt al genoeg.
Quote:
Warning
This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
Gewijzigd op 16/05/2012 15:27:18 door Chris PHP
Dus... met andere woorden, wordt er via de site zelf ingebroken... of breken ze in op de server waardoor ze bij jouw files kunnen komen?
Waar worden de gegevens bijgehouden?
In de tabel users?
Of een nieuwe tabel? Ik zou voor een nieuwe tabel gaan?
En als de gebruiker weer probeert in te loggen?
Hoe wordt het account dan weer 'geactiveerd'?
Wat ik overigens wel erg slecht vindt is dat er erg veel webhosts achterlopen met bijv: Apache versie ( In de oudere versies zijn al een aantal exploits ontdekt )
database wachtwoord, gebruikersnaam, databasenaam, die in config.php staan naar de database server die ook in config.php staat. daarom moet je ook een database server aangeven in mysql_connect();
Bij het sturen van die dingen naar de database server kan het dus worden afgekeken.
Pagina: « vorige 1 2 3 4 volgende »