nicht angemeldet
Hallo,
In einem Projekt, in das ich involviert bin, wurde (u.A.) eine Cross-Site-Request-Forgery-Sicherheitslücke gemeldet.
Hast du sie denn verursacht? Und sollst du sie nun schließen?
Alle Projekte, die mit Cookie-Authentifizierung arbeiten, sind von CSRF betroffen, sofern sie KEINE Gegenmaßnahmen ergreifen (wie CSRF-Token). Das ist das "täglich Brot" eines Webprogrammierers. Das sollte man unbedingt wissen, bevor man irgendwelche Projekte mit User-Authentifizierung online stellt.
In einem der Beiträge wird auf einen CSRF-Token verwiesen. Was macht der? Wie funktioniert der?
Der CSRF-Token ist eine weitere vertrauliche Information, die bei nicht-idempotenten Requests (PUT, POST, DELETE) zur Authentifizierung an den Server gesendet werden muss. Im Gegensatz zum Cookie wird der CSRF-Token nicht automatisch gesendet, wenn eine fremde Seite einen Request auf deine Seite initiiert. Der CSRF-Token wird üblicherweise in der User-Session auf dem Server gespeichert. Er wird z.B. in jedes Formular als Hidden Input geschrieben und wird mit den Formulardaten mitsendet. Erst wenn Cookie und CSRF-Token valide sind, dann ist der Request gültig.
Es wird auch noch auf zwei weitere Lücken hingewiesen. Ich kann, da ich mir den betreffenden Code noch nicht angeschaut habe, keine Aussage darüber treffen, ob eine oder beide Lücken mit der oben beschriebenen in Zusammenhang stehen.
<input type="hidden" name="email" value="test@example.comle3d4"> <script>alert(1)</script>"/>
- Im gezeigten Originalcode sind das Ausführungszeichen und das Größer-Als-Zeichen, welche die Emailadresse und das input-Tag abschließen, als maskierte Zeichen notiert.
- Sollten sie damit nicht ungefährlich sein?
Ja, was diesen Kontext angeht schon.
- Kann es sein, dass die Maskierungen aus dem Test des Fehlermelders stammen, aber der Angriffscode so, wie in meiner Auflösung notiert, unmaskiert sein müsste?
Ja – das kannst du testen, indem du <script>alert(1)</script> als Wert ins Formular eingibst. Wird der JS-Code ausgeführt auf der Folgeseite oder auf irgendeiner Seite, wo die E-Mail vorkommt, bist du verwundbar.
- Wenn die Emailadresse serverseitig validiert wird, ist ja nach „.comle3d4“ Schluss. Wem wird das Alert untergeschoben?
Allen Usern die sich diese Seite ansehen bzw. durch einen Link oder eine fremde Seite zum Reflected XSS geführt werden. JavaScript wird ja im Browser ausgeführt. XSS bedeutet dass ein Angreifer JavaScript-Code in deine Seite einschleust.
Lücke Numero 3 betrifft CSS-Injektion über den relativ angegebenen Pfad zur CSS-Ressource im Link-Element des Dokumentkopfes. Diesen Umstand zu beheben und daraus eine absolute URL zu machen, ist einfach. Ich verstehe aber leider den Angriffsvektor nicht.
Das wird mir aus deiner Beschreibung auch nicht klar.
Ich habe leider keine Vorstellung, wie solche Angriffe funktionieren.
Falls du Webanwendungen entwickelst, solltest du dich informieren/weiterbilden. XSS und CSRF sind das "Einmaleins" der Websicherheit.
Wie kommt eine andere Website, die gleichzeitig mit der des Projektes im Browser geöffnet ist, an die Anmeldung in Form des Cookie, wie es die oben verlinkte Wikipedia-Seite und auch der Melder der Lücken beschreiben?
Die fremde Seite kommt nicht an den Cookie selbst. Muss sie auch nicht. Sie initiiert einfach nur einen Request an deine Seite. Das Senden des Cookies (und damit die erfolgreiche User-Authentifizierung) macht der Browser des Opfers automatisch. Sämtliche URL- oder Formulardaten erscheinen deiner Anwendung daher als "legitim", sie kommen aber vom Angreifer.
Wie kann mir jemand externe CSS-Ressourcen unterschieben, bloß, weil der originale Aufruf mit einer relativen Pfadangabe erfolgt?
Ich wüsste nicht dass dies möglich ist.
Wer ist das Ziel des JavaScript-Codes, wenn dieser bei der serverseitigen Verarbeitung der Eingaben nicht gefunden und zurückgewiesen wird?
Schau dir einmal mal die Definition von "Reflected XSS" an. Das sollte genau diese Frage klären.
- XSS (Cross Site Scripting) Prevention Cheat Sheet
- Types of Cross-Site Scripting
- Excess XSS: A comprehensive tutorial on cross-site scripting
- Google Application Security: Cross-site scripting
Und was bleibt von diesem Angriff übrig, wenn die serverseitige Validierung funktioniert?
Eigentlich nichts. Eine serverseitige Validierung plus eine saubere Maskierung in allen Kontexten verhindern XSS.
Hans
Auge