So schützen Sie Widgets vor gefälschten Anfragen

Question

Nehmen wir an, Sie haben ein JavaScript -Widget, das eine Anfrage an Ihre Webanwendung ablassen muss, wenn der Benutzer darauf klicken möchte. Sie möchten nicht, dass diese Anfrage für CSRF anfällig ist, damit Sie einen Iframe auf die Seite schreiben. Basierend auf Ursprungs -Inheritanzregeln Die übergeordnete Website kann das CSRF -Token nicht lesen. Was ist jedoch mit ClickJacking (oder Jacking )? Wegen CSRF müssen Sie in einem Iframe und dort für die X-Frame-Optionen kann nicht helfen, und das gleiche gilt für Rahmenbustern.

Der Angreifer wird eine anwenden SVG -Maske Der Iframe nach dem geladenen Widget. Diese Maske macht den Iframe unsichtbar. Zu diesem Zeitpunkt kann der Angreifer entweder die Größe des Iframe als Größe der Seite ändern oder dieses unsichtbare Iframe dem Cursor folgen. In jedem Fall, wenn der Benutzer irgendwo auf der Seite klickt, erhält der IFrame das Click -Ereignis und sein Spiel.

Es gibt also eine Dualität, es scheint, dass Sie zwischen CSRF und ClickJacking festhalten. Was ist die beste Lösung (falls vorhanden) zu diesem Problem?

Answer 1

Wenn Sie auf das Widget klicken, muss ein Popup-Fenster mit einer neuen Seite geöffnet werden-ein Iframe ist nicht gut genug, es muss ein neues Fenster sein-das vollständig unter der Steuerung Ihrer Webanwendung steht. Bestätigen Sie die Aktion, was auch immer sie ist, auf dieser Seite.

Ja, das ist etwas unelegant, aber die vorliegende Websicherheitsarchitektur bietet Ihnen keine besseren Optionen.

Answer 2

Es gibt keine Möglichkeit, eine Anfrage zu verhindern, wenn sie unter einem ClickJacking -Angriff angeregt werden. Es gibt keine CSRF -Verteidigung, die einem ClickJacking -Angriff standhalten kann, da es keine Möglichkeit gibt, einen echten Klick von einem gefälschten Klick auf die Client -Seite zu unterscheiden.

Owasp erwähnt in ihrer CRSF -Präventionskalkulation Dass eine der Voraussetzungen für die CSRF -Token -Verteidigung zur Arbeit ist, ist, dass kein XSS -Angriff im Gange ist.

Meiner Ansicht nach sollte dies auch ClickJacking enthalten, da das CSRF -Token, das in Iframe sogar versteckt ist, nicht gegen ClickJacking verteidigen kann. Die Anfrage wird von einem direkten Benutzerklick gefälscht.

Am Ende stecken wir also nicht wirklich zwischen CSRF und ClickJacking fest - CSRF -Verteidigung sind für eine andere Art von Angriffen gedacht, bei denen auf der Seite des Angreifers viel weniger Leistung vorhanden ist.

Auf die Fragen, die Sie in Bezug auf ClickJacking und CSRF erwähnen:

• Was ist die beste Lösung (falls vorhanden) für dieses Problem? - Die beste Verteidigung für das ClickJacking auf der Kundenseite besteht darin, eine neue Browser -Registerkarte oder ein Browserfenster mit einer Seite mit einer Seite von Ihrer Website zu öffnen und die dort erwähnte Aktion zu bestätigen. Dies ist, was die Twitter -Schaltfläche tut, und es kann auch in diesem Szenario keine Forderung geben.

• Es gibt also eine Dualität, es scheint, dass Sie zwischen CSRF und ClickJacking festhalten - Die CSRF -Verteidigung sind nicht für Fälle wie XSS oder ClickJacking -Angriffe bestimmt, sie sind nur gegen weniger leistungsstarke Angriffe wirksam (E -Mail mit bösem Link, böswilliger Link im Forum usw.).

Answer 3

Es gibt keinen guten programmierbaren Lösung zum ClickJacking. Einige Unternehmen verklagen Spammer als Verteidigung gegen ClickJacking. Andere zeigen Popup-Windows, sobald der Benutzer in Iframe geklickt hat, obwohl dies die Benutzererfahrung beeinträchtigt, insbesondere bei Einzelklick-Button. Genau das tun Twitter für die Schaltfläche "Retweet". Facebook stellt diesen Ansatz derzeit für die Schaltfläche „Gefällt mir“ ein und fordert nach Bestätigung, wenn Anfragen von Domains auf der schwarzen Liste stammen. Ich habe gehört, dass GoogleBot einige ClickJacking -Heuristiken ausführt und gleichzeitig Seiten mit seiner Schaltfläche „+1“ (Überprüfung berechneter Stile, Elemente überlappend usw.) durchführt.

Answer 4

--AKTUALISIEREN--Wenn Sie "Widget" sagen, wenn Sie etwas außerhalb Ihrer Anwendung meinen, mit denen nicht authentische Personen interagieren, ignorieren Sie diese Antwort. Ich habe Ihre Frage erneut gelesen und Sie sagen nie wirklich, was Sie mit "Widget" meinen. Wir haben alle Arten von "Widgets", die in unserer Anwendung zusammen sind. Ich dachte, das haben Sie gesprochen, alles in einer Anwendung, mit der nur authentifizierte Benutzer interagierten. Wenn dies der Fall ist, ist diese Antwort das, was OWASP empfiehlt.

-Original-Antwort--"Sie möchten nicht, dass diese Anfrage für CSRF anfällig ist, damit Sie einen Iframe auf die Seite schreiben." Nein, machen Sie keinen Iframe, so können Sie die normale OWASP -Empfehlung zum Schutz vor Cross -Standort -Rahmen erstellen.

Um vor CSRF -Hash zu schützen, geben Sie ihn in Ihr Formular (oder AJAX -Postdaten) ein und überprüfen Sie dann den Hash -Wert am hinteren Ende. Wenn es übereinstimmt, stammt es von Ihrer Website. Je spezifischer Daten Sie in den Hash einstellen können, desto besser.

Beispiel: Wenn sich ein Benutzer anmeldet, kann Sie eine lange zufällige Zeichenfolge erstellen und diese an seine Sitzung binden. Diese Zeichenfolge darf auf Ihrer Website oder beim Anzeigen der Quelle niemals sichtbar sein. Angenommen, der Benutzer zieht einen bestimmten Datensatz an, den er bearbeiten möchte. Sie können dann diese Benutzer mit einer langen zufälligen Zeichenfolge mitnehmen, die Sie erstellt haben, diese Aufzeichnungen dazu anhängen und dann sie dann hassten. Das Ergebnis dieses Hashs, das Sie in Ihr Formular als verborgenes aufnehmen können. Dann auf Ihrem Backend, bevor Sie etwas tun, das Sie auf die Anwesenheit dieses verborgenen überprüfen, falls es nicht existiert, lassen Sie es ab. Wenn es vorhanden ist, nehmen Sie die zufällige Sitzungszeichenfolge und den von ihnen eingereichten Grundschlüssel für den Klaren.

Und es ist einfach, dies überall hinzufügen, selbst wenn Ihre Website bereits geschrieben ist (vorausgesetzt, Ihre Website enthält ein einzelnes Code auf allen Seiten wie eine Fußzeile). Machen Sie den Hashed -Wert und legen Sie ihn irgendwo in Ihrer Fußzeile in eine versteckte DIV. Anschließend können Sie jQuery verwenden, um diesen Hash -Wert dynamisch hinzuzufügen, der allen Formularen auf der Seite versteckt ist. Und Sie können jQuery.ajaxpreFilter verwenden, um es allen AJAX -Posts automatisch hinzuzufügen, falls Sie einen AJAX -Post und nicht einen normalen Formularposten ausführen. Wir schützen einige sehr große Websites, die bereits auf diese Weise codiert wurden.

https://www.owasp.org/index.php/cross-ite_request_Forgery_(csrf)_prevention_cheat_sheet

Wenn dies nach diesem Weg klingt, den Sie einschlagen möchten, könnte ich einige der JQuery -Code dafür zeigen. Soweit Sie Hashing sind, wie Sie es im Backend usw. überprüfen möchten, hängt alles ab, wenn Sie Coldfusion, PHP, PL/SQL (PSP) usw. verwenden. Ich kann Sie in die Richtige Richtung, wenn es eine davon ist.

Answer 5

Ich glaube, ich verstehe, was du tust. Sie möchten zulassen, dass jeder Website Ihr Widget iframen. Daher hat ein Angreifer die vollständige Kontrolle über den Quellcode des Elternteils und kann ClickJacking -Routinen erstellen, um Benutzer zum Klicken auf das Widget zu zwingen.

Der Iframe könnte also ein CSRF -Token verwenden, wie es sollte, was vor dieser Art von Angriff schützt, solange der übergeordnete Rahmen das Token nicht lesen kann.

ClickJacking ist, wie ich sicher bin, ein völlig anderer Angrifftyp als CSRF und braucht eine andere Verteidigung.

Wirklich, wenn das Widget sehr wichtig ist, als die 2-Phasen-Authentifizierung zu implementieren. Verwenden http://twilio.com Rufen Sie den Benutzer an und lassen Sie ihn eine PIN eingeben. Oder senden Sie eine E -Mail an den Benutzer mit einem Überprüfungslink. Oder bitten Sie den Benutzer, die Aktion beim nächsten Mal zu überprüfen, wenn sich der Benutzer auf der Website Ihres Widgets anmeldet.

Wenn Sie die Kontrolle über den übergeordneten Rahmen hätten, hätten Sie mehr Optionen. Es wäre dann eine XSS -Schutzmaterie.

Aktualisieren Sie, nachdem die richtige Antwort ausgewählt wurde

Mein Ansatz zum Schutz vor ClickJacking ist also etwas über Bord. Sieht so aus, als ob es mit einem Popup -Fenster mit einer Bestätigungsaktion geschützt werden kann.

Answer 6

Wegen CSRF müssen Sie in einem Iframe sein ...

Nein. Sie können CSRF nicht mit Formularen und anderen Nonce -Tricks befreien. Es spielt keine Rolle, wo Sie sie setzen.

Es gibt also eine Dualität, es scheint, dass Sie zwischen CSRF und ClickJacking festhalten. Was ist die beste Lösung (falls vorhanden) zu diesem Problem?

Um CSRF zu mildern, müssen Sie die Bedrohung entfernen, indem Sie den Server mit der Injektion oder im böswilligen Code beheben, die Phishing-E-Mail stoppen usw. Wenn keine gutartige Umgebung vorhanden ist, müssen Sie den Benutzer erneut authentifizieren (oder eine andere Herausforderung stellen /Antwort, um einen interaktiven Benutzer zu gewährleisten). Sehen:

• CSRF-Cheat-Blatt des CSRF (Cross-Site-Anfrage Forgery (CSRF)

TE RemDiate ClickJacking, verwenden Sie X-Frame-Options oder Frame-Breaking-Code in JavaScript. Aber ich denke auch nicht narrensicher. Sehen:

• ClickJacking Defense Cheat Sheet