CSPとは XSSをどこまで防げるか

このレッスンで学ぶこと

CSP(Content Security Policy)は、実行してよいスクリプトの出所をサーバーが応答ヘッダで宣言する仕組みです。この回は、それがXSSをどこまで防げるかを確かめます。

読み終えるころには、DevToolsのNetworkでこのヘッダの有無を見て、効き方と限界を自分で確かめられるようになります。

CSPは実行してよいスクリプトの出所を宣言する

CSPは、そのページで読み込み・実行してよいスクリプトの出所を、サーバーが応答ヘッダで宣言する仕組みです。

Content-Security-Policy: script-src 'self'

この宣言があると、ブラウザは自分のオリジンから来たスクリプトだけを実行し、HTMLに直接書かれたインラインの <script> を既定で止めます。注入が入っても、実行の段でブラウザが弾けることがあります。

入門編の同一生成元ポリシーはブラウザが最初から持つ仕切りでしたが、CSPはサイトが自分で足す方針です。既定の仕切りに、サイトが上乗せする1枚だと考えると位置づけがはっきりします。

変換の代わりにはならない

CSPだけに頼れない理由は次のとおりです。

• 設定を緩めると効かない。unsafe-inline を許すとインラインのスクリプトが通り、宣言はあっても素通りする
• 回避の手立てが知られている。許可した出所に乗る形など、抜け道が残る
• 欠陥そのものは消えない。文字列がHTMLに混ざる穴は残り、CSPが無い経路や古い環境では通る

だからCSPは、出力時の変換と安全なAPIで穴を塞いだ上に重ねます。塞ぐのをやめてCSPで受け止める、という順序にはしません。

手を動かす

練習用のショップの応答を、DevToolsのNetworkで開き、Content-Security-Policy ヘッダが付いているかを見ます。CSPを入れて、注入した <script> を試すと、Consoleに実行を止めた旨が出ます。ただし出力時の変換をしていないと、CSPの効かない書き方や経路では通ることも、あわせて確かめます。

まとめ