Anhand von StudiVZ hatte ich vor einigen Tagen ja mal den Punkt
Security by Obscurity beleuchtet. Zusammengefasst: Für Web-Anwendungen ist so etwas eine schlechte Idee.
Nachdem Robert heute freudig seinen neuen Schutz gegen Kommentarspam
vorgestellt hat, bin ich zufällig auf ein anderes Beispiel für
Security by Obscurity gestossen. Das ist deswegen bemerkenswert, weil es jeder Anhand der Quelltexte selber nachvollziehen kann.
Robert benutzt (wie viele Andere auch) ein
Wordpress-Plugin (Version 2.0 ist Basis dieser Beobachtungen) bei dem bei der Absendung eines Kommentars eine kleine Rechenaufgabe gelöst werden muss. Er möchte damit automatisch das Web durchsuchende Programme, die Spam in Kommentare schreiben, ausfiltern. Vorerst mit gutem Erfolg.
Wie funktioniert das Plugin?
Bei der Anzeige des Kommentarformulars wird das bereichts errechnete Ergebnis der Rechenaufgabe verschlüsselt in einem unsichtbarem Feld übergeben. Schickt der User nun das Eingabeformular ab, wird das vom User eingegebene Ergebnis verschlüsselt und mit dem verschlüsseltem Wert in dem unsichtbaren Feld verglichen.
Die Blog-Software bekommt also Formulardaten zurück, bei denen in einem Feld das unverschlüsselte Ergebnis (vom User eingegeben) und in einem anderem Feld (vorher berechnet) das verschlüsselte Ergebnis steht, und nur aufgrund dieser beiden Felder wird auf einen "erlaubten" Kommentar entschieden.
Traue keinem User-Input!
Da Eingabefelder von Formularen beliebig verändert und manipuliert werden können, ist es meist keine gute Idee kritische Entscheidungen oder Berechtigungen nur auf zurückgelieferte Eingabefelder zu stützen, wie in diesem Fall.
Dazu muss mindestens sichergestellt werden, dass das "verschlüsselte" Eingabefeld kryptografisch so abgesichert ist, dass es von einem Angreifer nicht gefälscht werden kann.
Das kryptografische Verfahren
Schauen wir uns also das Verfahren zum Erzeugen des "verschlüsselten" Wertes an. Also das
"geheime Verfahren", welches bei einem
Security-by-Obscurity Prinzip nie veröffentlich werden darf. Und (weil es ein PHP-Plugin ist) im Quelltext beim Autor heruntergeladen werden kann.
Das "verschlüsselte Ergebnis" besteht aus einem MD5-Hash, bei dem die Reihenfolge umgekehrt wurde (Reihenfolge umkehren erhöht die Sicherheit nicht!) und aus dem nur verschiedene feste Teilbereiche benutzt werden.
Der Haustürschlüssel liegt unter der Fussmatte
Woraus wird der MD5-Hash berechnet? Aus
- dem Ergebnis der Rechenaufgabe
- dem aktuellem Datum samt Uhrzeit des Servers
- dem Blognamen/Titel des Blogs
Datum/Uhrzeit des Blogs lassen sich relativ leicht (zur Not durch probieren) herausfinden, und auch der Blogname findet sich je nach Wordpress-Template an verschiedenen automatisch abprüfbaren Stellen des Blogs.
Den Schutz aushebeln
Mit diesen Informationen kann sich also ein Angreifer zu einer beliebigen von ihm ausgedachten Ergebnis-Zahl das verschlüsselte Eingabefeld generieren und so die Rechenaufgaben-Überprüfung komplett aushebeln. Egal wie "unleserlich" die Rechenaufgabe im Kommentarformular ("1ins" statt "eins", "2wei" statt "zwei") gemacht wird.
Also zurecht ein Beispiel für "Security by Obscurity".
Fazit
Jetzt mag man nicht ganz zu Unrecht argumentieren, die Erkennung von Kommentarspam ist nicht besonders sicherheitsrelevant, und die Spammer würden sich nicht die Mühe machen, solch ein Verfahren zu implementieren. Das ist jedoch zu kurz gedacht. Die (Un-)Sicherheit von Web-Anwendungen fängt meist mit solchen vermeintlichen "Kleinigkeiten" an.
Kleiner Tipp für die Verbesserung des Plugins: Statt "get_bloginfo(name)" einen nach Aussen nicht sichtbaren für das Blog generierten Zufallswert verwenden, dann kann ein Angreifer von Aussen nicht so einfach den Hash-Wert selber erzeugen.
Geschrieben von af in am: Mittwoch, 13. Dezember 2006
Permalink
Tags: StudiVZ, Security, Obscurity, Datenschutz, Social Networks, Blogs
Diesen Beitrag bei folgenden Diensten bookmarken:
del.icio.us
- Digg it
- Mister Wong
- Technorati
- Ruhr.com Suchmaschine
Kommentare
Nächster Artikel: Web 2.0 Social Networks: Miete Deine Freunde
Vorheriger Artikel: Dummdreister Domaingrabber
Mein Plug-in generiert auf ähnlicher Weise einen MD5- oder wahlweise SHA1-Hash. Es wird der besagte WP_SECRET-String eingebunden und zudem eine ganze Menge Daten mehr, Stichwort "Entropy". Beispielsweise binde ich den Uni*-Timestamp der letzten Änderung von wp-config.php und dem Plug-in-Script selber ein.
Das alles ist zwar schön und gut und man kann auch noch zusätzlich etwas "Salz" reinstreuen in den String (siehe phpsec.org !), aber was nützt dies, wenn der Spambot vor jeder POST-Anfrage das Kommentarformular ausliest und den generierten Hash extrahiert? Der Spammer braucht dann nur einmal den "richtigen" Hash + Ergebnis finden und schon ist der Schutz wiedermal geknackt.
Ich denke, das mit dem WP_SECRET ist vom Ansatz her gut, aber vielleicht sollte auch der Titel des Beitrages und - wenn entsprechendes Plug-in installiert ist, auch die Anzahl Views vom Beitrag mit in den Hash eingebunden werden.
Dennoch: Insgesamt finde ich Deinen/Ihren (?) Beitrag zum Thema Security By Obsurity sehr gut und ich kann nur hoffen, dass dies bei vielen Bloggern nicht verhallt, mal ihre Plug-ins zu patchen. :)
Der Punkt ist aber, dass dazu die Seite geparst werden muss (was man Schritt für Schritt abhängig vom Spam-Aufkommen immer weiter über komplexere Captchas erschweren kann, das ist die Schutzfunktion), es aber in dem oben beschriebenem Verfahren eine einfache "Hintertür" gibt, um die eigentliche Schutzfunktion zu umgehen.