Lightning Talk @ pixiv TECH SALON
pixiv Inc.
2019.3.5
2
● 2018/04 ~
● 技術開発本部 品質改善PJ
● サービスセキュリティ
○ Content Security Policy
○ 脆弱性報奨金制度
● コーポレートセキュリティ
○ CSIRT
● Content Security Policy
○ 💥XSS
● SameSite Cookie
○ 💥CSRF
● => ウェブの多層防御機構(Defense in depth)
3
4
● リソースのフェッチ・実行を制限する
○ スクリプトの実行を防ぐ(*XSSを防ぐ*)
■ script-src, object-src, base-uri
○ コンテンツの改ざんを防ぐ
■ img-src, style-src, frame-src, require-sri-for, etc
○ 通信先を制限する
■ connect-src, form-action, frame-ancestors
5
HTTP/2 200
content-type: text/html
content-security-policy: img-src *.pixiv.net; style-src *.pixiv.net;
<!DOCTYPE html>
<html>
<body>
<img src="https://www.pixiv.net/img/icon.jpg">
<img src="https://evil.example.com/phishing.jpg">
<style src="https://www.pixiv.net/css/app.css"></style>
<style> * { display: none } </style>
</body>
</html>
6
HTTP/2 200
content-type: text/html
content-security-policy: script-src 'nonce-R0hqdW1BYU1LWFo=' 'strict-dynamic'
<!DOCTYPE html>
<html>
<body>
<!-- nonceが正しい => 実行 -->
<script nonce="R0hqdW1BYU1LWFo=" src="/js/app.js"></script>
<script nonce="R0hqdW1BYU1LWFo=">doNiceThings()</script>
<!-- nonceが無い又は間違っている => 実行しない -->
<p>「<script>alert('XSS')</script>」の検索結果</p>
</body>
</html>
7
HTTP/2 200
content-type: text/html
content-security-policy: script-src 'nonce-R0hqdW1BYU1LWFo=' 'strict-dynamic'
<!DOCTYPE html>
<html>
<body>
<!-- nonceが正しい => 実行 -->
<script nonce="R0hqdW1BYU1LWFo=" src="/js/app.js"></script>
<script nonce="R0hqdW1BYU1LWFo=">doNiceThings()</script>
<!-- nonceが無い又は間違っている => 実行しない -->
<p>「<script>alert('XSS')</script>」の検索結果</p>
</body>
</html>
8
?
● CSP Level 3 (まだドラフト) で追加された仕様
● nonceで許可されたscriptから動的に生成されたscriptも実行を許可される
○ createElement('script') -> appendChild()
● これが無いと動かないJSが多い
○ Google Tag Manager
○ Google Maps widget
○ Zendesk widget
○ CSP導入の障壁だったが、クリアされた
9
10
11
● 'strict-dynamic'サポート済みのブラウザ
○ Chrome, Firefox, Opera
○ Safari, Edge / IEは未サポート
● まだユーザーエージェントごとの出し分けが必要
○ nonceが'unsafe-inline'よりも優先されるため
12
13
● CSRFやタイミングアタックの対策
● SameSite属性を付けたcookieはクロスオリジンのリクエストに付与されなくなる
○ Set-Cookie: PHPSESSID=754d3b148d; path=/; secure; HttpOnly; SameSite=Strict
● セッションIDに付ければクロスオリジンで認証が通らない→CSRFが原理的に不可
● うかつに使うと本来セッションが必要な遷移でセッションが消える
○ 関連サイトや検索エンジンからの遷移など
14
15
16
● VRoid Hub
○ セッションIDにSameSite=Lax
○ クロスオリジンのGETは通常通り
POSTはセッションIDが付かない
○ CSRF対策:
カスタムHTTPヘッダ + SameSite cookie
17
● GitHub
○ read-only cookie (通常のセッションID) & write cookie (SameSite=Strict)
○ 従来のセッションID (read-only cookie) はそのまま
○ POSTリクエスト時にwrite cookieの存在を確認し、無ければ弾く
○ RFCでも提案されている方法
○ CSRF対策: CSRFトークン + SameSite cookie
18
● 主要ブラウザは全てサポート済み
● 未サポートであってもビジネスロジックに影響なし
○ cookieが普通のcookieとして扱われるだけ
19
● 包括的な対策
○ 従来のエスケープ処理やCSRFトークンの検証は網羅的な対策が難しい
● Defense in Depth
○ 脆弱性を作り込んでもセーフティネットとして機能する
○ Secure By Defaultのアプローチ
○ 開発者の懸念や手戻りを減らす=> 開発効率向上
20
● ブラウザの新しい防御機構が使用され始めている
● 従来のサーバサイドの脆弱性対策にプラスして包括的な対策が可能
● 数年後のセキュリティスタンダードを見据え、ピクシブでも使用を始めている
21
● Content Security Policy Level 3におけるXSS対策 - pixiv inside
● Strict CSP - Content Security Policy
● AppSec EU 2017 So We Broke All CSPs You Won't Guess What Happened Next
○ https://youtu.be/YBBqtrJmMRc
● Cookie の性質を利用した攻撃とSame Site Cookie の効果 | blog.jxck.io
● Cross-Site Request Forgery is dead!
22
終
制作・著作
23

New Layers of Web Application Security