Nebenstehendes habe ich heute irgendwo auf einem Blog gefunden.
Das Problem ist hier scheinbar, dass in der Sidebar des Blogs ein externer Dienst eingebunden wird. Ein Lookup beim Diensteanbieter selbst und dem Infofilmchen zeigt, dass man sich serverseitige Scripte (PHP/Perl) generieren lassen kann, die man dann ins Blog einbinden kann. Konkret geht es hier um Linkvermarktung, und Blogger können dann in der Sidebar dieses Scriptchen einbinden, dass dann vom externen Diensteanbieter die AdLinks holt und diese dann in die Sidebar ausgespuckt werden.
Im ersten Moment an sich keine schlechte Idee, und auch ein toller Service, denn viele Blogs sind in PHP/Perl geschrieben und eine Einbindung scheint da einfach, zumal man als Betrachter kein JavaScript benutzen muss. Der Nachteil allerdings ist, wenn wie hier offensichtlich eine Fehlbedienung vorliegt und das Blog – aus welchem Grund auch immer – den integrierten Quellcode nicht ausführt, sondern einfach als Text anzeigt.
Wo ist dann jetzt genau das Problem? Nun, ein großes Problem ist sicherlich, dass der serverseitige (PHP-)Quellcode hier einfach in der Sidebar steht und über „View HTML Source“ zur näheren Betrachtung extrahiert und abgespeichert werden kann. Viel „schlimmer“ ist allerdings, dass der Quellcode Informationen zum Account des Blognutzers beim externen Diensteanbieter enthält. Hier also eine Art adspaceid, die keinem Integer Wert entspricht, sondern aus dem Hexadezimal-Raum besteht. Für einen potenziellen Angreifer ist dies recht nützlich, denn im Zuge der Informationsgewinnung konnte hier die ID eines echten Nutzeraccounts gewonnen werden, an die man sonst vielleicht nicht gekommen wäre (wobei man dies allerdings relativieren muss, viele JS-Widgets übergeben ja auch eine Art accountid an den externen Dienst). Desweiteren ist aus dem Quellcode zu entnehmen, wo das beim externen Diensteanbieter serverseitige Script liegt, dem die adspaceid übergeben wird und das dann die AdLinks zurückgibt, so dass man hier auch direkt weitere Informationen enthält, die sich für einen potenziellen Angriff beim externen Diensteanbieter nutzen lassen.
Zusätzlich bekommen wir noch Informationen über die Autoren der serverseitigen Scripte. Aus der Programmierweise könnte sich ableiten lassen, wie eventuell der Rest der Software beim externen Diensteanbieter programmiert ist, so dass sich Rückschlüsse daraus ziehen lassen könnten, wo man bei einem potenziellen Angriff noch ansetzen könnte. Die Referenz auf das externe Script ist mit der endung .php5 markiert. Wenn ich per telnet einen HEAD / HTTP/1.0 Request auf Port 80 des externen Diensteanbieters mache, dann sehe ich, dass expose_php vorbildlich auf Off gesetzt wurde, demnach die Webserver-Signatur (Apache 2.0.54) keine Auskunft darüber gibt, welche PHP-Version eingesetzt wird. Dank der Benamung auf .php5 wissen wir jedoch jetzt, dass PHP5 eingesetzt wird.
Was kann man daraus lernen? Meines Erachtens zwei Dinge:
- Als Blogger sollte man sein Blog gut konfigurieren und bei Änderungen lieber 2x nachschauen als nur flüchtig 1x. Klar, wie immer gilt auch hier, man ist auch nur ein Mensch, und Fehler können passieren
- Als Diensteanbieter mag es schön sein, für den Kunden (hier: der Blognutzer) serverseitige Scripte zu generieren (noch dazu vorbildlich nach PHPDoc dokumentiert), die dieser dann extern einbinden kann. Der augenscheinliche Vorteil liegt hier darin begraben, dass ein Besucher des Blogs kein JavaScript benötigt um sich dieses Widget anzusehen. Dies wird jedoch dadurch konterkariert, dass eine gewisse Restgefahr bleibt, dass der serverseitige Code nun doch nicht serverseitig bleiben wird, wie hier geschehen. Insbesondere hat man als Anbieter von Diensten und Services eine besondere Verantwortung gegenüber den Nutzern/Kunden. Dass dies im Zuge der teilweise extrem kurzen Releasezyklen im Web2.0-Zeitalter manchmal hinten unter fällt, konnte man in der jüngsten Vergangenheit leider häufiger beobachten.
Also doch lieber die Einbindung von Widgets via JavaScript?
Schreibe einen Kommentar