generated at
Content Security Policy (CSP)


CSPの主なモチベーションは、XSSなどのContent Injectionの根絶
一般的にContent Injectionを防ぐのは難しい
攻撃者は隙間を見つけてscriptを埋め込んでくる
基本的にBrowserは、resourceの送信元を信頼する
もし悪意のあるscriptが送られてきたら実行してしまう
対策としては、Webページ中に、攻撃者の指定した文字列を表示できなくすればいい
しかし、Browser目線では、
どれが正当な開発者の用意したscriptで、
どれが攻撃者が仕込んだscrpitなのか
を判断する術がない
そこで、例えばresourceの取得に制限を設ける
Content Injectionのあるある攻撃ポイントに対して項目がある感じ
例えば
指定していないoriginからはscriptをfetchしない
こういう制限をfontとかcssとか画像とかにも設けられる
scriptタグ内のscriptは実行しない
そもそもJSを実行させない
「こういう制限のもとで作ってまっせ」ということをserverがheader経由でbrowserに伝える
「この辺のものは最初から使わないよ」と宣言している感じ
制限に違反したものは攻撃者のscriptだと判定してブロックすることができる


directiveの構造
CSPには多くのdirective setが用意されている
ざっと30種類ぐらいあるmrsekut
Content-Security-Policy: という1つのheaderに対して、複数の key value; を指定することになる
例えば object-src とか script-src というkeyがあって、それぞれに対応するvalueを指定する
dircetiveはざっくり5つに分類されている


directiveの分類
Others Dirctive


結局何を指定すればいいのか?
Strict CSPを参考にする




計測する




参考
概要や、各directiveの解説


概要
ヘッダ関連






指定する方法は2つ
response header
response body内のmetaタグ




>CSPはコンテンツを取得する側が読み込むコンテンツを制限するために設定するのに対し、CORSはコンテンツを提供する側がアクセス権を与える先を制限するために設定するものです。ref



以下のような攻撃の対策になる





CSPへ至る歴史
afterParseHookという関数を用意しておき、
ブラウザがJSをparseしたあとに、その関数を適用して、実行の許可をしたりする仕組み
これでは不十分で、Return To JavaScript攻撃を受ける