php Script Sicherheit automatisch prüfen

[Maax]

Hi,
in der aktuellen Internet Professional 10/06 findet sich (laut testticker.de) ein Artikel dazu, wie man mit einem online Tool ein PHP-Script automatisch auf Sicherheitslücken überprüfen kann.

Da ich allerdings schon x mal Computerzeitschriften gekauft habe und danach enttäusch war, dass ich 95% eh schon wusste, die 5% nicht sooo interessant waren und die Zeitschrift auch noch ziemlich viel gekostet hat (15 Euro für praktisch nichts ist ja nicht gerade billig) wäre ich euch ganz dankbar, wenn ihr mir diesen einen Link auch so verraten könntet und ich mir damit die "Investition" in diese Zeitschrift sparen könnte.

Vielen Dank,
Maax

[dedlfix]

echo $begrüßung;

in der aktuellen Internet Professional 10/06 findet sich (laut testticker.de) ein Artikel dazu, wie man mit einem online Tool ein PHP-Script automatisch auf Sicherheitslücken überprüfen kann.

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.

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.

Übliche Verdächtige sind nicht initalisierte Variablen, auf die lesend zugegriffen wird und dazu ein eingeschaltetes register_globals.
Beispiel: Ein Anmeldevorgang

if (stimmt($username, $password))
    $angemeldet = true;

Stimmt $username und $password nicht, bleibt $angemeldet uninitialisiert. Bei einem

if ($angemeldet)
    irgendwas();

liefert es null, womit die Bedingung nicht erfüllt ist. Das Script sieht also so aus, als ob es zuverlässig arbeitet. Aber denkste. Der Angreifer muss nun den Variablennamen $angemeldet kennen und übergibt ihn einfach als GET-Parameter

http://example.com/script.php?angemeldet=1

Das register_globals macht daraus ein $angemeldet = '1'; und man ist angemeldet, ohne irgendeinen Benutzernamen oder Passwort zu kennen.

Voraussetzung für einen erfolgreichen Angriff dieser Art ist die Kenntnis der verwendeten Variablennamen. Verhindern kann man ihn, indem man konsequent Variablen mit definierten Werten initialisiert. Das muss natürlich so erfolgen, dass sämtliche Entscheidungswege (if, switch, while) berücksichtigt werden. register_globals auszuschalten, ist ein Bekämpfen der Symptome, doch deren Ursache bleibt bestehen.

Dein gesuchter Online-Service kann solche Fehler auch nur dann finden, wenn er zufällig einen passenden Variablennamen trifft.

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.

Eine weitere Injektionsmöglichkeit ist bei SQL gegeben. Für jedes Datenbank-System gelten eigene Regeln, wie bestimmte Sonderzeichen zu notieren sind, damit nicht ihre besondere Bedeutung zum tragen kommt, wenn diese Zeichen in den Nutzdaten vorkommen. Magic Quotes ist ein PHP-Feature, das Abhilfe gegen SQL-Injection bringen soll, doch da es auf sämtliche Eingaben wirkt und nicht nur auf die, die auch in der Datenbank landen, ist sein Handeln manchmal ungewünscht. Und da es auch noch weniger Sonderzeichen berücksichtigt, als beispielsweise MySQL kennt, arbeitet es auch noch unzureichend.

Für MySQL behandelt man Benutzereingaben vor dem Einfügen in das SQL-Statement mit mysql_real_escape_string() oder, wenn man PHPs mysqli-Extension oder PDO einsetzt, mit den dort vorgesehen Mitteln.

SQL-Injection zu finden stelle ich mir für ein automatisches Tool recht schwer vor. Denn man braucht Intelligenz, um Herauszufinden, ob man mit dem Ergebnis der SQL-Injection das Script zu seinen Gunsten beeinflusst hat.

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.

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.

Es gibt unter Garantie noch mehr Möglichkeiten, Script-Lücken auszunutzen, als mir gerade eingefallen sind ...

echo "$verabschiedung $name";

[Maax]

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