nicht angemeldet
Hi dedlfix,
erst mal vielen Dank für die extrem ausführliche Antwort.
Wenn es das selbe Tool ist, an dessen Erwähnung im Heise-Newsticker ich mich erinnere, dann dürfte das ein kostenpflichtiges Tool gewesen sein, wenn meine Erinnerung stimmt.
Ah. Danke für die Info.
Also schon wieder ein Grund, warum ich die Zeitschrift umsonst (aber eben nicht kostenlos :-) ) gekauft hätte...
Auf sämtliche Sicherheitslücken kann man ein Script, ohne es zu kennen nicht prüfen. Manchmal reicht es, die üblichen Verdächtigen zu probieren, manchmal braucht man den Quelltext, um die Lücke gezielt ausnutzen zu können.
Stimmt voll und ganz - ich habe aber keine Ahnung, ob das Script den Quelltext nutzt oder nicht.
Übliche Verdächtige sind nicht initalisierte Variablen, auf die lesend zugegriffen wird und dazu ein eingeschaltetes register_globals.
[...]
Register_Globals ist bei mir selbst verständlich (da ich Einfluss darauf habe) deaktiviert - trotzdem danke für die Infos.
Dein gesuchter Online-Service kann solche Fehler auch nur dann finden, wenn er zufällig einen passenden Variablennamen trifft.
Oder den Quelltext einliest - ich weiß eben praktisch nichts über den Service.
Der nächste übliche Verdächtige ist Injektion von HTML- und clientseitigem Script-Code
Man gibt einfach ungeprüft und unbehandelt die Eingabe des Benutzers aus.echo $_GET['foo'];
Steht nun HTML-/Javescript-/Sonstwas-Code in foo, wird dieser in die Ausgabe eingebettet. Solche Lücken schließt man, indem man Daten von außerhalb zum einen auf legalen Inhalt prüft, zum anderen Ausgaben speziell für das Ausgabemedium behandelt. Im Falle einer Ausgabe als HTML bietet sich htmlspecialchars() an. Diese Art Fehler kann das Online-Tool relativ leicht finden.
Afaik kann er keinen PHP-Code einschleusen, da PHP das von selbst unterbindet (ich habe verschiedene Versuche dazu unternommen).
Wenn sich der Nutzer absichtlich die Daten zerstört, die er nachher ausgegeben bekommt - selbst schuld.
Auf Daten auf dem Server (Dateien, Datenbankinhalte etc.) kann er damit doch ohnehin keinen Einfluss nehmen, oder habe ich da etwas übersehen?
Für MySQL behandelt man Benutzereingaben vor dem Einfügen in das SQL-Statement mit mysql_real_escape_string() [...]
Mache ich - trotzdem danke!
Weitere Fehler, die das Online-Tool finden kann, wären bekannte Lücken in älteren PHP-Versionen. Dagegen hilft einfach up-to-date zu bleiben.
Immer hilfreich - gut das du mich wieder daran erinnerst (im Background läuft desshalb wieder ein Update - über cron mache ich es absichtlich nicht und irgend wie ist es aus meinem Terminkalender verschwunden - steht aber schon wieder drin).
Fazit: Man kann solche Hilfen einsetzen, um einige Fehler zu finden, aber man sollte nicht dem Trugschluss unterliegen, dass das Script sicher sei, nur weil irgendjemand/irgendwas keinen Fehler gefunden hat.
So weit so klar - aber jeder Fehler, den es findet ist immerhin schon mal raus.
Es gibt unter Garantie noch mehr Möglichkeiten, Script-Lücken auszunutzen, als mir gerade eingefallen sind ...
Klar - und notfalls werden die erst in der Zukunft gefunden oder entstehen erst in zukünftigen PHP-Versionen...
Also - noch mal vielen Dank für die viele Mühe für diese tolle Zusammenfassung der übelsten Fehler!!!
Grüße,
Maax