■http://anond.hatelabo.jp/20170309042831

この話は、途中で「危ない」の意味がすり替わっているので混乱してるんじゃないかな？

1. クロスドメイン制約で他ドメインのサーバにリクエスト投げられません ← わかる

これが許可された場合に攻撃の危険性にさらされるのは「リクエストを受ける側」のサーバだ。

この場合、攻撃者である可能性を持つ「リクエストを投げる側」は不特定多数である。

2. ＜script src=""＞なら他ドメインも取れるよ ← まあわかる

3. じゃあここを動的に変えて、実体はスクリプトファイル(JSONP)で関数呼んでデータ貰おう ←！？

ただのJSONだったころよりもっとあぶねーじゃん？

関数実行しちゃってんだぜ？

これが許可された場合に攻撃の危険性にさらされるのは「リクエストを投げる側」であり、先ほどとは攻撃者と被攻撃者が逆転している。

この場合、攻撃者である可能性を持つ「リクエストを受ける側」は、「リクエストを投げる側」が明示的に指定したサーバだ。

この問題は信用できないドメインに対して自分側からリクエストを送らないようにする、という明確な対策が可能である。

JSONPは、「リクエストを受ける側」にとってXMLHttpRequestでWebAPIを叩かれるよりも安全だからドメインを超えた通信が出来るわけ。

つまりこういうことね。

【XMLHttpRequestの危険性 (実際にはこの動作は禁止されている)】
ブラウザ←ーーー「攻撃者WEBサーバ」（悪意あるリクエストを投げるコードをブラウザに渡す）
　　　　ーーー→「被攻撃者WEBサーバ」
　　　　　　　　(悪意あるリクエストに答えてしまう)

【JSONPの危険性】
ブラウザ←ーーー「WEBサーバ」（攻撃者WEBサーバへリクエストを投げるコードをブラウザに渡す。※このサーバは、攻撃者WEBサーバに悪意があることを知らない)
　　　　ーーー→「攻撃者WEBサーバ」（レスポンスとして悪意あるコードをブラウザに渡す）
ブラウザ←ーーー
(悪意あるコードを実行してしまう)

Permalink | 記事への反応(0) | 12:55

ツイートシェア