Security by Obscurity Teil III: Qype und Javascript
Wie man aus Teil 1A, Teil 1B und Teil 2 meiner kleinen unregelmäßigen Reihe über "Security by Obscurity" erkennen kann, halte ich dieses Konzept für ziemlich unsicher, weshalb ich von Zeit zu Zeit Websites vorstelle, die damit arbeiten. Eher durch Zufall hat es dieses mal Qype erwischt.
Angenommen, jemand schützt seine Haustür mit dicken Schlössern und blitzenden und ehrfurchteinflössenden gepanzerten Stahltüren. Kaum jemand würde versuchen, diese Tür aufzubrechen.
Wenn aber jetzt der Haustürschlüssel unter der Fussmatte versteckt wird ("Da kommt bestimmt kein Einbrecher drauf..."), und damit jeder die Haustür einfach aufschliessen kann, wird der Denkfehler (einige nennen es Irrsinn, einige Dämlichkeit...) im Konzept offensichtlich.
Wenn man nun auf die Website en.qype.com geht, erscheint eine scheinbar normale Qype Homepage, die nach einem kurzem Moment etwas verdunkelt wird, und von oben schwebt die Meldung herunter:
Man wird nach einem Keyword gefragt, um auf die Seite zuzugreifen.
So weit, so sicher, scheint es.
Was also, so könnte man denken, passiert wohl, wenn man in seinem Browser Javascript einfach abschaltet (wie es ca. 5% aller User ebenfalls haben, und wie es völlig legitim ist)?.
Antwort: Man kann ganz "normal" und ohne Passwortabfrage auf die "Closed Beta" zugreifen und alle Funktionen, die bei Qype kein Javascript erfordern, nutzen (z.B. erscheint statt Google-Maps nur ein Kasten). Die Passwortabfrage ist ausgehebelt.
Dieses Ergebnis hat mich nun doch ziemlich überrascht, denn mit solch einem Verhalten habe ich wirklich nicht gerechnet. Jeder Programmieranfänger von Webanwendungen sollte doch wissen, dass man den Sicherheitsüberprüfungen in Javascript nicht trauen darf, und wenn man es dennoch macht, die vom Browser kommenden Daten auch zusätzlich immer noch Serverseitig zu überprüfen sind.
Tja, bei über 300.000 Seiten im Google Index kann man das nicht mehr so recht als einen "Closed Beta Test" bezeichnen, eher als eine "Public Beta".
Deswegen: Liebe Webprogrammierer, wenn Ihr Sicherheitschecks macht, macht diese bitte bitte immer Serverseitig. Vertraut keinem User-Input und vertraut keinen clientseitigen Sicherheitsprüfungen. Wenn Ihr Javascript Sicherheitsfeatures einbaut, dann bitte bitte nur als nette, komfortable und redundante Ergänzung zu den bereits implementierten serverseitigen Sicherheitsfunktionen.
Security by Obscurity
Was steckt hinter Security by Obscurity? Hier wieder das klassische Haustürbeispiel:Angenommen, jemand schützt seine Haustür mit dicken Schlössern und blitzenden und ehrfurchteinflössenden gepanzerten Stahltüren. Kaum jemand würde versuchen, diese Tür aufzubrechen.
Wenn aber jetzt der Haustürschlüssel unter der Fussmatte versteckt wird ("Da kommt bestimmt kein Einbrecher drauf..."), und damit jeder die Haustür einfach aufschliessen kann, wird der Denkfehler (einige nennen es Irrsinn, einige Dämlichkeit...) im Konzept offensichtlich.
Das Qype Beispiel
Die englische Website von Qype (en.qype.com) befindet sich nach dortiger Information in einem "Closed Beta Test". Ein geschlossener Betatest ist erstmal sehr zu begrüssen (siehe: Das Web 2.0 Perpetual Beta Dilemma).Wenn man nun auf die Website en.qype.com geht, erscheint eine scheinbar normale Qype Homepage, die nach einem kurzem Moment etwas verdunkelt wird, und von oben schwebt die Meldung herunter:
Limited access!
Thank you for visiting the english version of Qype.
This site is currently in a closed beta test.
Man wird nach einem Keyword gefragt, um auf die Seite zuzugreifen.
So weit, so sicher, scheint es.
Was liegt wohl unter der Fussmatte?
Schicke, interaktive und manchmal nutzlose Sachen im Web 2.0 werden heutzutage ja meist in Javascript umgesetzt.Was also, so könnte man denken, passiert wohl, wenn man in seinem Browser Javascript einfach abschaltet (wie es ca. 5% aller User ebenfalls haben, und wie es völlig legitim ist)?.
Antwort: Man kann ganz "normal" und ohne Passwortabfrage auf die "Closed Beta" zugreifen und alle Funktionen, die bei Qype kein Javascript erfordern, nutzen (z.B. erscheint statt Google-Maps nur ein Kasten). Die Passwortabfrage ist ausgehebelt.
Dieses Ergebnis hat mich nun doch ziemlich überrascht, denn mit solch einem Verhalten habe ich wirklich nicht gerechnet. Jeder Programmieranfänger von Webanwendungen sollte doch wissen, dass man den Sicherheitsüberprüfungen in Javascript nicht trauen darf, und wenn man es dennoch macht, die vom Browser kommenden Daten auch zusätzlich immer noch Serverseitig zu überprüfen sind.
War da nicht etwas mit Javascript und Google?
Ach ja, richtig. Auch Google ignoriert Javascript. Seit Jahren versuche ich das Webdesignern einzuprügeln (damit diese keine Javascript basierte Navigation verwenden, die von Google ignoriert wird... ). Da ist es dann nicht weiter verwunderlich, wenn ein bei Google eingetipptes "site:en.qype.com " 328.000 Seiten findet, die auch alle im Google-Cache zu finden sind.Tja, bei über 300.000 Seiten im Google Index kann man das nicht mehr so recht als einen "Closed Beta Test" bezeichnen, eher als eine "Public Beta".
Fazit
Über die Tragweite und Schwere dieser Sicherheitslücke kann man durchaus unterschiedlicher Meinung sein. Es ist ja nur ein Beta-Test. Leider zeigt die Erfahrung, dass solch eine Technik leicht von anderen Programmierern übernommen wird, um dann bei anderen, wesentlich kritischeren Sicherheitsabfragen, verwendet zu werden.Deswegen: Liebe Webprogrammierer, wenn Ihr Sicherheitschecks macht, macht diese bitte bitte immer Serverseitig. Vertraut keinem User-Input und vertraut keinen clientseitigen Sicherheitsprüfungen. Wenn Ihr Javascript Sicherheitsfeatures einbaut, dann bitte bitte nur als nette, komfortable und redundante Ergänzung zu den bereits implementierten serverseitigen Sicherheitsfunktionen.
Geschrieben von af in am: Dienstag, 15. Mai 2007
Permalink
Nächster Artikel: Der bessere Agentur Anbieter: Full-Service oder Spezialist?
Vorheriger Artikel: Web 2.0: Verlassen die Ersten das sinkende Schiff?
es stimmt, was Du entdeckt hast. Die Passwort-Abfrage ist leicht auszuhebeln.
Die englische Version der Site muss nicht besonders geschützt sein, sie ist ja mit der öffentlichen deutschen Version identisch, d.h. nicht besonders schutzbedürftig.
Umgekehrt ist es für uns extrem wichtig, dass die Site schon früh von Google gespidert wird.
Der Sinn des private Beta-Test besteht nur darin, die Site dahingehend abzuschotten, dass nicht darüber berichtet wird, so lange sie noch nicht fertig lokalisiert ist. Wir wollen nicht, dass unsere Englischen Nutzer auf eine noch teilweise deutsche Site kommen.
danke für Deine offene Antwort. Eure Motivation kann ich gut verstehen.
Wenn die Website nicht schutzbedürftig (hier: abschotten) wäre, wäre ja jeder Passwortschutz überflüssig.
Eine Website in den Google-Index (damit ist sie öffentlich) zu bekommen, aber gleichzeitig vor fremdem Zugriff, vor fremden Blicken abzuschotten, ist halt ein unmöglicher Spagat.
Habt Ihr schon einen Termin für die \"offizielle\" Sichtbarkeit (d.h. Wegfall der Javascript Passwortabfrage) der englischsprachigen Seiten?