Für Fragen ist das PHP-Forum gedacht und nicht dieses Schwerpunktthema, in dem – wie aus dem Eingangsbeitrag hervorgeht – keine Fragen zu bestimmten Quellcodes oder Algorithmen gewünscht sind. Diese sind hier zwar auch erlaubt, sollen aber nur zusammen mit einer Lösung des Problems in der Form „Problem → Ursache → Lösung“ genannt werden. Für Fragen zu spezifischen Problemen soll bitte ein eigenes Thema eröffnet werden.

Gareth Hayes hat in seinem Blog einen Eintrag über die Anfälligkeit von PHP_SELF veröffentlicht, sofern man es nicht richtig filtert.

The Spanner - Exploiting PHP_SELF

Sean Coates hat nicht nur diese Sicherheitslücke eher als Gareth Hayes „entdeckt“, sondern beschreibt zusätzlich sowohl die Ursache als auch eine Lösung.

Die Ursache ist nämlich Apaches „AcceptPathInfo“-Feature, mit dem auch nur Teile des Pfads für eine erfolgreiche Abbildung auf das Dateisystem dienen können. So reicht in dem genannten Beispiel bereits das „…/php_self.php“ aus, das auf die gleichnamige Datei abgebildet wird. Der Rest wird in der Umgebungsvariable PATH_INFO gespeichert.
Das Problem hierbei ist wieder einmal der naive Umgang mit den von außen kommenden Benutzereingaben, zu denen auch die URL zählt. Und da PHP_SELF nicht nur den tatsächlichen Pfad zur Skriptdatei sondern auch den PATH_INFO-Teil enthält, der wiederum beliebig sein kann (und so auch Schadcode enthalten kann), ist dieser Variablenwert ebenfalls mit Vorsicht zu behandeln.

Ersteinmal, recht herzlichen Dank für diesen interessanten Threat.

Was mich bezüglich des PHP_SELF sehr interessieren würde, wie sieht es denn hier bei Smartys SCRIPT_NAME aus? Wurde das von Seiten der Smarty-Entwickler ausreichend entschärft, oder muss man bei den Templates in denen man SCRIPT_NAME verwendet nacharbeiten?

kind regards
JCB

Supi Thread das hier is
Hab mir bislang auch nicht wirklich Gedanken, um die Sicherheit meiner Skripte gemacht...
Andererseits ist mir aufgefallen, dass ich einige Tipps/Ratschläge diese Threads bereits instinktiv befolgt habe

Was mich persönlich dazu interessieren würde, wäre, wie bereits genannt, wie man solche Ausnutzungen von Sicherheitslücken selber nutzen kann...
Wie kann ich selber dafür sorgen, dass ich meine Skripte "missbrauche"?

Die nun folgende Frage ist verständlicherweise richtig dumm und unangebracht, aber ich möchte sie trotzdem stellen:
Könnte mir jemand einen "Beispiel"-Skript nennen, der sämtliche "Löcher" auf meiner Web-Site findet, nutzt und/oder ausbügelt?

Geht mir dabei nich darum, was fertiges zu haben, dass ich benutze, sondern nur darum, dass ich sehe wie man sowas macht... Ne entsprechende Klasse o.ä. zum verwenden auf meiner Site schreibe ich mir dann selber...

[EDIT]:
Was mir grad noch einfällt... Hab ne Idee, die meiner Überlegung nach zumindest theoretisch die Unsicherheit von $_GET-Übergaben in der URL beheben könnte...
Unzwar halt statt $_GET einfach $_POST verwenden...
Aber wie benutze ich in einem Link $_POST!?
Meine Idee dazu:
Anstelle des Links ein unsichtbares Formular, welches die nötigen Daten POSTet...
Und den submit-Button entsprechend formatiert, sodass er aussieht wie ein einfacher Link...

Was haltet ihr von dem Gedanken?

Ich finde die Nutzung von GET nicht grundsaetzlich unsicherer als POST. Klar, GET-Daten zu manipulieren ist einfacher, da es einfach ueber die Addresszeile geht, aber vernuenftig validieren muss man die Daten eh, egal wie sie nun zum Server gelangen.

Zum Thema Testing der eigenen Seite: Ich hab mal angefangen, auf Basis meiner HTTP-Klasse, eine Klasse zum Penetration Testing zu schreiben.
Hab aber schon lange nicht mehr daran gearbeitet, und die bisher existierende Version kann auch noch nichts.
Zudem gibt es wohl auch bessere Tools fuer sowas.

Was die Transparenz der Daten angeht, ist GET eindeutig unsicherer als POST. Denn der Webserver protokolliert gewöhnlich sämtliche Anfragen samt Anfragezeile, in der auch die angefragte URL enthalten ist.

Von automatisierten Tests halte ich allerdings nicht viel. Denn ich halte es für schwierig, einem Algorithmus einerseits das Finden von Schwachstellen und andererseits das Ausnutzen dieser Schwachstellen zu überlassen. Bis auf die üblichen Angriffe wie Schadcode-Injektionen ist da nicht viel zu machen.

Hallo,

ich programmiere seit kurzer Zeit für ein paar Leute das cms und dazu habe ich halt ein Loginsystem gebastelt.

nun stellt sich mir die Frage der sicherheit.
Eine Frage: Die verschlüsselung. Bringt die was?

Ich meine, wenn man das verschlüsselte passwort hat, dann muss man doch nur einmal schnell md5 in google eingeben und entschlüsselt es schnell... ich meine, das bringt's doch nicht.

Wie warscheinlich ist es, dass jemand die Daten für den Server über z.B. Suchprogramme finden kann?

habe z.B. eine Datenbank, in der der komplette Inhalt der Seite ist.
Dann habe ich eine Suchfunktion, die auf die Datenbank zugreift und die ergebnisse auflistet.

Gibt es irgendwie unsichere Loginverfahren? oder ist php von haus aus sicher?

Ist PHP sicher? Nein, es gibt auch hier immer wieder Lücken.
Ist dein Skript sicher? Keine Ahnung, man kann es nicht sehen.

PHP ist ein beliebtes Angriffsziel weil es einfach zu erlernen ist, dabei man aber wichtige Dinge oft außer Augen lässt. Wie z. B. folgendes Motto:
"Filter Input, Escape Output"

Sprich: Alles was reinkommt ist böse und sollte validiert und gefiltert werden.
Alles was rausgeht, sollte sicherheitshalber nochmal maskiert werden.

Und md5 ist keine Verschlüsselung, sondern eine Hash-Funktion.

Ich meine, wenn man das verschlüsselte passwort hat, dann muss man doch nur einmal schnell md5 in google eingeben und entschlüsselt es schnell... ich meine, das bringt's doch nicht.

Teste es doch einfach mal.
Ich wette du schaffst es nicht

habe md5 in google eingegeben:

http://www.google.de/search?q=md5&ie...ient=firefox-a

drittes erbegnis: MD5-Decrypter by xpzone.de

Wenn ich jetzt bei einer Übertragung den mitgesnifften Hash da eingebe, bekomme ich die eingabe, die der Benutzer getätigt hat.

das hier z.B.: 21232f297a57a5a743894a0e4a801fc3

in meinem PHP-Buch steht das "hashen" unter Sicherheit... aber was soll das bringen? da kann man das Passwort doch auch unverschlüsselt versenden

... Ok wenn du mein DB Passwort rauskriegst, bekommst du nen Preis... das steht in der DB: 6b60cfd4b896e17cc09097a33d37e48b

Eine Programmiersprache selbst kann nur grundlegende Sicherheit wie etwa Typsicherheit, Geltungsbereiche bieten. Dadurch werden die damit geschriebenen Anwendungen aber noch lange nicht sicher.

PHP ist in diesem Sinne eine leider zu einfach zu lernende Sprache. Die subjektive Erfolgskurve ist steil, die objektive hingegen eher flach. Dadurch überschätzt sich so manch einer in seinen Fähigkeiten und grundlegende Regeln für den Umgang mit Benutzereingaben, wie Felix sie beispielsweise nannte, werden völlig außer Acht gelassen. Das Resultat davon ist millionenfach im Internet in der Form von schlechten Tutorials und Code-Schnipseln zu finden, die dennoch allzu gerne kopiert werden. Viele verstehen nicht einmal, was der kopierte Code tatsächlich tut. Es klingt fast absurd, aber selbst die einfachsten Probleme stellen für manche Programmierer eine unüberwindbare Hürde dar.

Zitat von Herror

Wenn ich jetzt bei einer Übertragung den mitgesnifften Hash da eingebe, bekomme ich die eingabe, die der Benutzer getätigt hat.

das hier z.B.: 21232f297a57a5a743894a0e4a801fc3

Ein kennwortgesichertes System ist nur so sicher wie das Kennwort selbst. Wenn du ein häufig verwendetes Kennwort wie „test“, „12345“ oder eben „admin“ verwendest, ist es kein Wunder, dass dies bereits in einer MD5-Datenbank zu finden ist. Verbesserung kann neben der Verwendung eines ungeläufigeren Kennworts übrigens auch durch so genannte Salted Hashes mit konstantem oder auch zufälligem Salt-Wert bieten.

Guter Beitrag und gut erklärt, danke

Can You Hack Your Own Site? A Look At Some Essential Security Considerations