Diskussion:Cross-Site-Request-Forgery
Der Artikel geht auf meine Kappe. Hatte mich nach dem Testen des Beispiels mit der Abmelden-Funktion nicht mehr eingeloggt :-) Gruß --Boris23 讨论 19:16, 29. Sep 2005 (CEST)
Page Token gegen jede Art von XSS angreifbar
BearbeitenEs ist falsch zu sagen, nur eine persistente XSS könnte diesen Schutz aushebeln. Ich kann genauso gut mit einer reflexiven XSS die Werte aus der HTML Seite auslesen. Nutzen kann ich diesen solange der Benutzer keine Erneuerung des PageTokens anfordert! (nicht signierter Beitrag von 87.159.46.169 (Diskussion) 05:46, 27. Jan. 2012 (CET))
„Überarbeiten“-Vorlage gesetzt
BearbeitenNachdem ich eben schon die Definition aufgrund einifer Ungenauigkeiten angepasst habe, fällt mir auf, dass auch der Rest des Textes noch mal ein bischen überarbeitet werden müsste. Dazu gehört insbesondere
- Eine beispielhafte Erklärung ist für eine Enzyklopädie nicht ausreichend (oder andersherum:)
- Das Beispiel beschreibt nur einen möglichen Angriff, XSRF kann auch durch XSS oder eine manipulierte IMG SRC auf der selben Seite eingeleitet werden
- XSRF kann auch durch manipulierte Mails mit eingebetteten Elementen ausgeführt werden
- Auch der Abschnitt Schutz beschreibt wieder nur beispielhaft die Gegenmaßnahmen
..jemand Interesse? ;-)
-- Togs 18:42, 5. Nov 2005 (CET)
Habe die entsprechenden Absätze jetzt selber ergänzt bzw. ausformuliert. „Überarbeiten“-Vorlage ist damit hinfällig. (..schön, dass ich hier mit mir selbe spreche) ;-) - Togs 13:13, 17. Dez 2005 (CET)
Hier sollte noch erwähnt werden, dass der Benutzer nichts zwangsweise auf einen Link klicken muss. Das Laden eines Bildes reicht aus, was letztendlich nicht auf ein tatsächliches Bild gelinkt ist, reicht aus.
Vielleicht sollte man die Überarbeiten-Vorlage wieder setzen? Das Prüfen des Referer hilft in kaum einer (außer der tatsächlich legitimen) Situation, da man Header auch fälschen kann. -- U7o 18:15, 6. Sep. 2007 (CEST)
Aber bei CSRF kommt doch der Request vom Opfer selbst, und dessen Browser fälscht den Referer normalerweise nicht, hoffe ich.. (nicht signierter Beitrag von 88.72.182.82 (Diskussion | Beiträge) 02:12, 11. Feb. 2010 (CET))
Ich hab mal eine Methode ergänzt, welche Web-Frameworks wie z.b. Django verwenden um sich vor CSRF zu schützen, wie weit die Methode Bullet-Proofed ist kann ich leider nicht sagen.
HTTP-Referrer-Prüfung: "Kein hinreichender Schutz"
BearbeitenIch stimme zu, wenn jemand sagt dass die HTTP-Referrer-Prüfung nicht zu empfehlen ist, weil sie bestimmte Nutzer ausschließt.
Jedoch bietet sie sehr wohl einen hinreichenden Schutz gegen die beschriebene CSRF-Attacke. NATÜRLICH kann man CSRF trotz Referer-Prüfung (fast) IMMER durchführen, wenn sich auf der Seite selbst noch eine XSS-Lücke befindet. Nach der momentanen Argumentation bietet aber, wenn man konsequent ist, KEINE Methode einen hinreichenden Schutz. Das stand ja sogar weiter oben schon: Wenn eine XSS-Lücke vorhanden ist, dann bringen auch die Nonces in den Formularen nichts.
Ich wünsche mir da etwas mehr Konsistenz in der Argumentation. Irgendwelche Einwände? --Johndoe17 00:09, 2. Apr. 2010 (CEST)
- Da es keine Einwände gibt habe ich mal einen entsprechenden Entwurf erstellt. --Johndoe17 15:33, 6. Apr. 2010 (CEST)
Quellen/Weblinks/Einzelnachweise
BearbeitenMir ist aufgefallen, dass das mit den Quellen, Weblinks und Einzelnachweisen vielleicht mal besser sortiert/organisiert werden sollte. Quellen/Weblinks überschneiden sich sehr stark und Einzelnachweise gibt es quasi keine. --Johndoe17 15:32, 6. Apr. 2010 (CEST)
Schutzmaßnahmen inkorrekt
BearbeitenDer Abschnitt zu den Schutzmaßnahmen stimmt nicht ganz mit der Wahrheit überein:
- Ohne weitere Lücken in der Webanwendung ist dieses Hidden-Field nicht auslesbar für den Angreifer.
Lässt sich unter anderem mit Javascript prima auslesen & damit nicht ganz korrekt, der Benutzer selber (nur Beispielhaft) kann das Prima im Quelltext sehen. (nicht signierter Beitrag von 85.16.71.3 (Diskussion) 20:39, 24. Apr. 2013 (CEST))
Lemma
BearbeitenHallo, ich werde den Artikel auf das Lemma Cross-Site-Request-Forgery verschieben. Begründung: der Begriff heißt im Orginal auf Englisch cross-site request forgery. Im deutschen Kontext berücksichtigt man die deutsche Orthografie, zum Beispiel Großschreibung von Substantiven und vollständige Durchkopplung mit Bindestrichen. Dass es ein deutscher Kontext ist, erkennt man zum Beispiel daran, dass man das Wort mit Artikel gebraucht: „Die Cross-Site-Request-Forgery“. Genauso ist es auch schon bei Cross-Site-Scripting gehandhabt. Hier die Erklärung des Dudens. --androl ☖☗ 17:00, 29. Apr. 2013 (CEST)
Verständlichkeit
BearbeitenKann man den Artikel auch so formulieren, dass ihn jemand versteht, der kein Spezialist für dieses Thema ist? Wer diesen Artikel versteht, hat bereits soviel Sachkenntnis, dass er ihn nicht braucht. Siehe gleich zu Beginn: "... bei dem der Angreifer eine Transaktion in einer Webanwendung durchführt." Fragt mal einen beliebigen Besucher einer Webseite, ob er schon mal eine Transaktion durchgeführt hat. Eine Transaktion bei der Bank? Eine Datenbank-Transaktion? Das Thema muss didaktisch dringend überarbeitet werden. So helft Ihr niemanden, weil Ihr nicht verstanden werdet. MichaelL2008 (Diskussion) 22:20, 7. Feb. 2015 (CET)
Defekter Weblink
Bearbeiten| Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|