Webブラウザセキュリティ
どんな本
Webブラウザが備えるセキュリティ機構について体系的にまとめた本。
目次
第1章 WebとWebセキュリティ
1.1 Webを構成する基本の3つのコンポーネント
1.2 プラットフォームとしてのWeb
1.3 Webセキュリティ
1.4 サーバーサイドWebシステムのセキュリティ
1.5 クライアントサイドWebシステムのセキュリティ
1.6 まとめ
第2章 Origin を境界とした基本的な機構
2.1 Webリソース間の論理的な隔離にむけて
2.2 OriginとSame-Origin Policy(SOP)
2.3 CORS(Cross-Origin Resource Sharing)
2.4 CORSを用いないSOPの緩和方法
2.5 SOPの天敵、XSS(Cross-Site Scripting)
2.6 CSP(Content Security Policy)
2.7 Trusted Types
2.8 まとめ
第3章 Webブラウザのプロセス分離によるセキュリティ
3.1 Webブラウザが単一のプロセスで動作することの問題
3.2 プロセスを分離した場合の問題
3.3 Process-per-Browsing-Instanceモデルに対する攻撃
3.4 Process-per-Site-Instanceモデルとその補助機能
3.5 まとめ
第4章 Cookie に関連した機構
4.1 Cookieの導入の動機
4.2 属性によるCookieの保護
4.3 Cookieの性質が引き起こす問題とCookieの今後
4.4 まとめ
第5章 リソースの完全性と機密性に関連する機構
5.1 問題と脅威の整理
5.2 HTTPSとHSTS
5.3 Mixed Contentと安全でないリクエストのアップグレード
5.4 Webブラウザが受け取るデータの完全性とSRI
5.5 Secure Context
5.6 まとめ
第6章 攻撃手法の発展
6.1 3種類の攻撃手法
6.2 CSP下でのXSS
6.3 Scriptless Attack
6.4 サイドチャネル攻撃
6.5 まとめ
メモ
第1章 WebとWebセキュリティ
サーバーサイドのセキュリティ
大方のWeb開発者がすべきこと
サーバーサイド Web アプリケーションをセキュア に作り、それと他のソフトウェアをセキュアにつなげるための知識を身につけるこ と
まずWebシステムを構成する各種コンポーネント(クライアント・サーバー・ブラウザ・ネットワークなどなど)のセキュリティを意識して作ること、そしてそれらを適切に接続するのが重要。
ブラウザのセキュリティ
リソースの隔離
論理的な隔離(CORSみたいな処理)
プロセスレベルの隔離(タブからアクセスできるメモリを分離するとか))
Cookieの扱い
Webリソースとブラウザのデータストレージの分離
出入りするリソースの信頼性
レスポンスの中身の改ざんなど
第2章 Origin を境界とした基本的な機構
考慮すべき事案(リソースとリソースの境界をどう制限するか)
webページAがローカルストレージにデータを保存しているとして、webページBからそのデータにアクセスできるていいか? => ブラウザ内アクセス
webページAからwebページBのDOMにアクセスできて良いか? => ネットワーク越しのアクセス
webページAからwebページBのサーバーに好きなリクエストを送れていいか?
Cross Originによるリクエストの制約を受けない。
下記を全て満たすものが対象
許可されているメソッドのうちのいずれかであること。
GET
HEAD
POST
ユーザーエージェントによって自動的に設定されたヘッダー (たとえば Connection、 User-Agent、 または Fetch 仕様書で禁止ヘッダー名として定義されているヘッダー)を除いて、手動で設定できるヘッダーは、 Fetch 仕様書で CORS セーフリストリクエストヘッダーとして定義されている以下のヘッダーだけです。
Accept
Accept-Language
Content-Language
Content-Type (但し、下記の要件を満たすもの)
Content-Type ヘッダーでは以下の値のみが許可されています。
application/x-www-form-urlencoded
multipart/form-data
text/plain
XMLHttpRequest オブジェクトを使用してリクエストを行う場合は、 XMLHttpRequest.upload プロパティから返されるオブジェクトにイベントリスナーが登録されていないこと。すなわち、 XMLHttpRequest インスタンスを xhr とした場合、どのコードも xhr.upload.addEventListener() が呼び出してアップロードを監視するためのイベントリスナーを追加していないこと。
リクエストに ReadableStream オブジェクトが使用されていないこと。
Origin
スキーム, ホスト名, ポート番号の組(document.domainも含むこともある)
SOP(Same-Origin Policy) <=> Cross Origin
Origin単位でアクセス可能なリソースに制限を加える仕組み
CORS(Cross-Origin Resource Sharing)
SOPを回避したい時にやるやつ
ブラウザ内アクセスの許可
レスポンスにAccess-Control-Allow-Origin: アクセスを許可するOriginを明記するだけ
さらにCookieとかも付与してCross Originアクセスをしたい場合
リクエスト時にcredentials: includeの指定
レスポンス時にAccess-Control-Allow-Originに*じゃなく明示的なOriginの指定
レスポンス時にAccess-Control-Allow-Credentials: trueの指定
ネットワーク越しのアクセスの許可(単純リクエスト以外のもの)
OPTIONSメソッドでプリフライトリクエストを発行(これは単純リクエストでない場合にブラウザが勝手に発行する)
リクエスト発行元のOriginを値として持つOriginヘッダ
発行したいリクエストのメソッドを値として持つAccess-Control-Request-Method
発行したいリクエストに付与したいヘッダ名のリストを値として持つAccess-Control-Request-Headers
プリフライトリクエストのレスポンスが下記を満たす
Access-Control-Allow-OriginがリクエストのOriginヘッダを含む
Access-Control-Allow-Methodsがリクエストのしたかったメソッドを含む
Access-Control-Allow-Headersがリクエストのしたかったヘッダを含む
Access-Control-Max-Ageがレスポンスに含まれている場合は上記レスポンスをブラウザはキャッシュしてプリフライトリクエストの発行をスキップする
CORS以外のSOP緩和方法
JSONP
document.domain
SOPの弱点
XSS(Cross-Site Scripting)をはじめとしたContent Injectionを防げない
CSP(Content Security Policy)
ヘッダーで事前にそのwebサイトで許可されるタグや処理の実行を明示しておいて制限できる仕組み
Webアプリケーションを一定の制約を満たすように作ってもらい、それをWebブラウザに伝えてもらうことで、制約に反した挙動をWebブラウザが検出、ブロックする仕組み = Webページに課したい制限をWebブラウザに伝えるための仕組み
ディレクティブや指定方法がたくさんあるので都度ドキュメント見た方が良さそう
残念なことに、CSP はそれ以前の提案の中に見られた欠点をも取り込んでしまっています
とは
Googleおすすめ
code:txt
Content-Security-Policy:
object-src 'none';
script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
base-uri 'none';
Googleの実際のレスポンスヘッダーを見てみるのも面白い。cspとかstrict-transport-securityとか色々ついてる。
curl -I https://accounts.google.com/
DOM-based XSSの対応難しい問題
反射型XSS・格納型XSS
webサーバ側にエスケープ漏れなどの脆弱性があり生成されたHTMLに悪意のあるスクリプトが含まれて発生するXSS
DOM-based XSS
サーバ上でのHTMLの⽣成に関係なくブラウザ側のJSに脆弱性がありそれ起因で発生するXSS
ソース・シンク
ソース
location.hash などの攻撃者が実際の攻撃のためのJavaScriptコードを含めていた箇所
シンク
HTMLElement.innerHTMLなどのソースに含まれる文字列を受け取り、文字列からJavaScriptを生成、実行してしまう箇所
Trusted Types
DOM-based XSS対策の特化版
シンクに代入する処理前の文字列をTrustedTypesという型で保護された文字列しか受け付けないようにすることで不正なソースの注入を防ぐことができる
第3章 Webブラウザのプロセス分離によるセキュリティ
単一プロセスで動作するモノリシックなアーキテクチャから複数プロセスで動作するアーキテクチャへ
複数プロセスで動作する場合に互換性の問題がある
Browsing Instance/Site/Site Instanceのプロセス分離モデルが導入される
https://scrapbox.io/files/63877106446d0d001dc511ae.pnghttps://scrapbox.io/files/63882bcb4c7ca50020ed876d.png
参照: Webブラウザセキュリティ 第3章 Webブラウザのプロセス分離によるセキュリティ P85~86
Browsing Instance は、ウィンドウオブジェクトに対する参照が存在するような ウィンドウやフレームの集合
Site は、URL 中の「スキーム部分」と、「ホスト部分から取り出した登録可能なド メイン名」からなる組
Site Instance は、「Browsing Instance の部分集合であって、同じ Site を持 つウィンドウ同士からなる集合」のこと
レンダラプロセスにページやフレーム処理を分散させる3つの方針
Process-per-Browsing-Instance
新しく開いたウィンドウ単位でレンダラプロセス生成&処理
Process-per-Site-Instance
同一Site-Instance単位でのみレンダラプロセスが処理
Process-per-Site
同一Schemafull-Site単位でのみレンダラプロセスが処理
Process-per-Browsing-Instanceは実装が容易である程度のプロセス隔離を実現できるがセキュリティ的には同一レンダラープロセスに複数Siteのコンテキストを混在させられるのでメモリを読み出されたりする可能性がありガバガバになりがち
renderer exploit attacker
memory disclosure attacker
投機的実行でマイクロアーキテクチャレベルの状態に変更を加えるが、命令セットレベルには何も変更を加えない命令 = Transient Instruction/ Execution
↑のようにProcess-per-Browsing-Instanceはrenderer exploit attackerやmemory disclosure attackerに脆弱なのでChromeはProcess-per-Site Instance(Site Isolation)の仕組みを使ってる。
とはいえSite Isolationだけではimgタグやiframeなどからのクロスオリジンなリクエスト発行の余地はあるから下記が用いられる
CORB
CORBだけではJSON/HTML/XMLは保護できるがその他のリソースも保護したい
CORP
COOP/COEP
上記の緩和策も取れるようにするためのヘッダ
第4章 Cookie に関連した機構
HTTP0.9 = GET URL [CR][LF]の1行だけ!!!シンプルすぎる
HttpOnly属性の注意
セッションハイジャック対策でありXSS対策ではない
Cookie上書き攻撃
XSSなどの脆弱性を使いcookieを大量にセットして既存のcookieを上書きする。cookieも無限に保存できるわけではないので確かに。。
歴史的経緯による独特な仕様
1. Cookieは自動で保存される(いちいち保存していいか聞かれるとUXクソすぎる)
2. Cookieはそれがセットされた範囲へのリクエストであれば、いかなる場所から発行されたリクエストに対しても付与され、保存される(imgタグやiframeタグからのリクエストなども対象)
3. 独特なセキュリティ境界を利用して運用されている(domain属性とpath属性)
結果的にCSRF/プライバシー問題/SOPの相違、を引き起こしておる
3rd party cookie排除の流れ -> 不透明なやり方が蔓延る
フィンガープリント(OS情報やversion,fontの種類などなどから個人を割り出す)
Supercookie(localstorageなどを使う)
SOPの相違
https://example.com:1234とhttps://example.com:9876はCrossOriginだがクッキーは送られる
Cookieの代替
第5章 リソースの完全性と機密性に関連する機構
そもそもwebサーバー/ネットワークなどの中間経路に脆弱性があってコンテンツに改ざんがあった場合(リソースの完全性と機密性が損なわれている)などにどうするか
CSPに反していなければWebブラウザには知る由もない
それに対応できるWebブラウザ側の仕組みも必要
webアプリ側の脆弱性により発生する問題はWebブラウザ側ではどうしようもない
一方で中間経路のネットワークの脆弱性に関してはセキュアな通信をブラウザ側で担保できれば良さそう
Webアプリケーションとの間では、できるだけセキュアな通信路を利用する
受け取ったデータの完全性を可能な範囲で検証する
HTTPS
『プロフェッショナルSSL/TLS』が薦められていた
HTTP の Strict-Transport-Security レスポンスヘッダー (しばしば HSTS と略されます) は、ウェブサイトがブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示するためのもの
ブラウザにどのくらいHTTPSを強制させるか指示できる。cookieはサブドメインでも送られてしまう一方でHSTSはドメイン単位で指定するとサブドメインは対象外になるのでincludeSubDomainsをつけると良い。
code:txt
Strict-Transport-Security: max-age=31536000; includeSubDomains
HSTS Preload
HSTSはレスポンスヘッダの中身を見て行うので初回のアクセスのみはHTTPで行われてしまう。これも避けたい。
「HTTPS を強制すべきドメイン」の リストが事前に Web ブラウザに埋め込まれる
MixedContent
Upgrade-Insecure-RequestsをレスポンスヘッダーやCSPで指定するとMixedContentによるブロックをimgやvideoにも適用できる
SRI
サブリソース完全性 (Subresource Integrity, SRI) は、 (CDN などから) 取得したリソースが意図せず改ざんされていないかをブラウザーが検証するセキュリティ機能です。 SRI を利用する際には、取得したリソースのハッシュ値と一致すべきハッシュ値を指定します。
リソースのハッシュ値を事前に指定しておいてブラウザがそれを検証してくれるみたいな機能
Secure Context
ContextがSecureであるとは?
Workerなどの強力なAPIはセキュアな通信路を経由して配信されたページでありセキュアな通信路を経由して配信されたページとのつながりを持たないという状態
例
code:example.js
if (window.isSecureContext) {
// Service Worker が実行されているので、このページは安全なコンテキストです
navigator.serviceWorker.register("/offline-worker.js").then(() => {
// …
});
}
第6章 攻撃手法の発展
CSP下でのXSS
脆弱な CSP の設定をバイパスして JavaScript 実行を試みようと する攻撃
script-srcディレクティブに許可リストを指定するのは抜け道が発生しやすい
何かが「ない」ことを保証をするのは本 当に難しいことです。そう考えると、script-src ディレクティブに許可リストを指 定するのはできるだけ避けて、nonce や hash ベースの値を採用するのが好ましいで しょう。
Script Gadgets
要約
unsafe-inline が含まれた CSP: 特に工夫なくバイパスできる
許可リストベースのCSP: 許可リスト内のJSONPエンドポイントやJavaScript ライブラリ、オープンリダイレクタを悪用することによりバイパスできる場合がある
hash/nonce ベースの CSP: Script Gadgets によりバイパスできる場合がある
(特に strict-dynamic キーワードの指定がある場合はバイパスの可能性が高 まる)
base-uri ディレクティブが含まれない CSP:<base> タグの挿入によりバイパ スできる
Scriptless Attack
CSP の設定で制限されていない機能を用いた、JavaScript を 必要としない攻撃
CSSに脆弱性があると下記のような感じでCSSからHTML上の属性値を推定するらしい...ヒェ〜
code:css
}
}
...
罠ページから攻撃対象の Web アプリケーションの挙動をサイ ドチャネル的に観測することで行う攻撃
ひたすらこの章は攻撃手法集みたいな感じだ...
CSPはXSS 攻撃に対する銀の弾丸ではない!!!
Web ブラウザセキュリティの世界は、本書に閉じたいわば「枯れた」世界ではな く、これからも絶えず変化していく世界
感想
この本は全体的になぜこのセキュリティ機構が必要なのか?というモチベーションやブラウザがその機能を導入するに至った経緯がちゃんと書かれているのでどの概念に対しても納得感が得られる。
2,4,5章はSOP,CSP,Cookie,MixedContentsとか大体理解はしているはずだったけど結構知らない概念とか使ったことない機能とか沢山あって学びだった。3章に至っては全然知らなかった...。MDNと睨めっこしながら読んだ。
リソース