同一オリジン ポリシー
それは何ですか？
同一生成元ポリシーは、ブラウザ間で標準化されたセキュリティ対策です。「オリジン」は主に「ドメイン」を指します。Cross Site Request Forgeryなどの攻撃を防ぐために、異なるオリジンが相互にやり取りするのを防ぎます。
CSRF 攻撃はどのように機能しますか?
ブラウザーは、Web サイトが Cookie の形式でクライアントのコンピューターに情報を保存できるようにします。これらの Cookie には、Cookie の名前、作成日時、有効期限、Cookie の設定者などの情報が添付されています。Cookie は次のようになります。
Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]
これはチョコレート クッキーで、http://bakery.comとそのすべてのサブドメインからアクセスできる必要があります。
この Cookie には機密データが含まれている可能性があります。この場合、そのデータは... chocolate. ご覧の通り高感度。
そのため、ブラウザはこの Cookie を保存します。また、ユーザーがこの Cookie にアクセスできるドメインにリクエストを送信すると、そのドメインのサーバーに Cookie が送信されます。ハッピーサーバー。
これは良いことです。サーバーがクライアント側で情報を保存および取得するための非常に優れた方法。
しかし問題は、これにより、ユーザーが知らないうちにhttp://malicious-site.comがそれらの Cookie をhttp://bakery.comに送信できるようになることです。たとえば、次のシナリオを考えてみましょう。
# malicious-site.com/attackpage
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();
悪意のあるサイトにアクセスし、上記のコードが実行され、同一生成元ポリシーが存在しない場合、悪意のあるユーザーはあなたに代わって注文し、彼の場所で注文を受け取ります...これは気に入らないかもしれません.
これは、ブラウザーがチョコレート クッキーをhttp://bakery.comに送信したために発生しました。これにより、 http://bakery.comは、新しい注文のリクエストを意図的に行っていると見なされます。しかし、あなたはそうではありません。
これは、簡単に言えば、CSRF 攻撃です。サイト間で偽造されたリクエストが行われました。「クロスサイトリクエストフォージェリ」。同一生成元ポリシーのおかげで、それは機能しません。
Same-origin ポリシーはこれをどのように解決しますか?
Malicious-site.com が他のドメインにリクエストを送信するのを阻止します。単純。
つまり、ブラウザは、どのサイトも他のサイトにリクエストを送信することを許可しません。AJAX のように、このようなリクエストを介して異なるオリジンが相互にやり取りするのを防ぎます。
ただし、画像、スクリプト、スタイルシート、iframe、フォーム送信などの他のホストからのリソースの読み込みは、この制限の対象ではありません。CSRF トークンを使用して、ベーカリーを悪意のあるサイトから保護するために別の壁が必要です。
CSRFトークン
述べたように、悪意のあるサイトは、同一オリジン ポリシーに違反することなく、次のようなことを行うことができます。
<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>
ブラウザはその URL から画像を読み込もうとするため、その URL への GET リクエストですべての Cookie が送信されます。これを防ぐには、サーバー側の保護が必要です。
基本的に、適切なエントロピーのランダムで一意のトークンをユーザーのセッションに添付し、サーバーに保存し、フォームと共にクライアントに送信します。フォームが送信されると、クライアントはリクエストとともにそのトークンを送信し、サーバーはそのトークンが有効かどうかを検証します。
これを実行すると、悪意のある Web サイトが再度リクエストを送信しますが、悪意のある Web サイトがユーザーのセッションのトークンを知るための実行可能な方法がないため、リクエストは常に失敗します。
CORS
クロス サイト リクエストが必要な場合は、必要に応じてポリシーを回避できます。これはCORSとして知られています。クロスオリジン リソース共有。
これは、「ドメイン」がブラウザを冷やすように指示し、そのようなリクエストを許可することで機能します。この「伝える」ことは、ヘッダーを渡すことで実行できます。何かのようなもの：
Access-Control-Allow-Origin: //comma separated allowed origins list, or just *
したがって、http://bakery.comがこのヘッダーをブラウザに渡し、http://bakery.com へのリクエストを作成するページがオリジン リストに存在する場合、ブラウザはリクエストを Cookie と一緒に手放します。 .
原点を定義する規則があります1。たとえば、同じドメインの異なるポートは同じオリジンではありません。したがって、ポートが異なる場合、ブラウザーはこの要求を拒否する可能性があります。いつものように、親愛なるInternet Explorer は例外です。IE はすべてのポートを同じように扱います。これは非標準であり、このように動作するブラウザは他にありません。これに頼らないでください。
JSONP
パディングを使用した JSONは、CORS がオプションでない場合に、同一生成元ポリシーを回避する方法にすぎません。これは危険であり、悪い習慣です。これを使用しないでください。
この手法に含まれるのは、次のように他のサーバーにリクエストを行うことです。
<script src="http://badbakery.com/jsonpurl?callback=cake"></script>
同一生成元ポリシーはこの2 つの要求を妨げないため、この要求の応答がページに読み込まれます。
この URL はおそらく JSON コンテンツで応答します。しかし、その JSON コンテンツをページに含めるだけでは役に立ちません。もちろん、エラーになります。したがって、 http://badbakery.comはコールバック パラメータを受け入れ、JSON データを変更して、コールバック パラメータに渡されたものにラップして送信します。
だから、戻るのではなく、
{ user: "vuln", acc: "B4D455" }
これは無効な JavaScript であり、エラーをスローすると、次のように返されます。
cake({user: "vuln", acc:"B4D455"});
cakeこれは有効な JavaScript であり、ページ上の残りの JavaScript がデータを使用できるように、実行され、おそらく関数に従ってどこかに保存されます。
これは主に、他のドメインにデータを送信するために API によって使用されます。繰り返しますが、これは悪い習慣であり、危険を伴う可能性があるため、厳密に避ける必要があります。
JSONP が悪いのはなぜですか?
まず第一に、それは非常に限られています。リクエストが失敗した場合、エラーを処理することはできません (少なくとも正気ではありません)。リクエストなどを再試行することはできません。
また、グローバルcakeスコープに関数を持たせる必要がありますが、これはあまり良くありません。異なるコールバックで複数の JSONP リクエストを実行する必要がある場合、クックがあなたを助けてくれますように。これは、さまざまなライブラリによる一時的な関数によって解決されますが、依然としてハック的な方法です。
最後に、ランダムな JavaScript コードを DOM に挿入しています。リモート サービスが安全なケーキを返すという 100% の確信がない場合は、これに頼ることはできません。
参考文献
1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin
2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
その他の価値ある読み物
http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
https://www.rfc-editor.org/rfc/rfc3986 (すみません:p)
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)