これからのフロントエンドセキュリティ

これからの
フロントエンドセキュリティ
Frontend Conference Fukuoka 2019
はせがわようすけ @hasegawayosuke

View Slide

Secure Sky Technology Inc. Frontend Conference Fukuoka 2019 #fec_fukuoka
aaa
長谷川陽介 (はせがわようすけ)
@hasegawayosuke
(株)セキュアスカイ・テクノロジー取締役CTO
千葉大学非常勤講師
OWASP Kansai ボードメンバー
OWASP Japan ボードメンバー
CODE BLUE レビューボードメンバー
セキュリティ・キャンプ協議会
Internet Explorer、Mozilla FirefoxをはじめWebア
プリケーションに関する多数の脆弱性を発見。
Black Hat Japan 2008、OWASP AppSec APAC
2014、CODE BLUE 2016他講演多数。
gihyo.jp連載： JavaScriptセキュリティの基礎知識
https://gihyo.jp/dev/serial/01/javascript-security

View Slide

jjencode - 記号だけでJSを書く
$=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:+
+$,$_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$_
_:++$,$_$:++$,$$__:({}+"")[$],$$_:++$,$$$:++$,$___:++$,$__$:++$}
;$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$
])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($.$=(!""+"")[$.__$])+($.
_=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$
._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"¥"
"+$.$_$_+(![]+"")[$._$_]+$.$$$_+"¥¥"+$.__$+$.$$_+$._$_+$.__+"(¥¥
¥"¥¥"+$.__$+$.__$+$.___+$.$$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$
._$+",¥¥"+$.$__+$.___+"¥¥"+$.__$+$.__$+$._$_+$.$_$_+"¥¥"+$.__$+$
.$$_+$.$$_+$.$_$_+"¥¥"+$.__$+$._$_+$._$$+$.$$__+"¥¥"+$.__$+$.$$_
+$._$_+"¥¥"+$.__$+$.$_$+$.__$+"¥¥"+$.__$+$.$$_+$.___+$.__+"¥¥¥"¥
¥"+$.$__+$.___+")"+"¥"")())();
http://utf-8.jp/public/jjencode.html

View Slide

aaencode - 顔文字でJSを書く
ﾟωﾟﾉ= /｀ｍ´）ﾉ ~┻━┻ //*´∇｀*/ ['_']; o=(ﾟｰﾟ) =_=3; c=(ﾟΘﾟ) =(ﾟｰﾟ)-(ﾟｰﾟ); (ﾟДﾟ) =(ﾟΘﾟ)= (o^_ô)/
(o^_ô);(ﾟДﾟ)={ﾟΘﾟ: '_' ,ﾟωﾟﾉ : ((ﾟωﾟﾉ==3) +'_') [ﾟΘﾟ] ,ﾟｰﾟﾉ :(ﾟωﾟﾉ+ '_')[o^_ô -(ﾟΘﾟ)] ,ﾟДﾟﾉ:((ﾟｰﾟ==3)
+'_')[ﾟｰﾟ] }; (ﾟДﾟ) [ﾟΘﾟ] =((ﾟωﾟﾉ==3) +'_') [c^_ô];(ﾟДﾟ) ['c'] = ((ﾟДﾟ)+'_') [ (ﾟｰﾟ)+(ﾟｰﾟ)-(ﾟΘﾟ) ];(ﾟДﾟ) ['o']
= ((ﾟДﾟ)+'_') [ﾟΘﾟ];(ﾟoﾟ)=(ﾟДﾟ) ['c']+(ﾟДﾟ) ['o']+(ﾟωﾟﾉ +'_')[ﾟΘﾟ]+ ((ﾟωﾟﾉ==3) +'_') [ﾟｰﾟ] + ((ﾟДﾟ) +'_')
[(ﾟｰﾟ)+(ﾟｰﾟ)]+ ((ﾟｰﾟ==3) +'_') [ﾟΘﾟ]+((ﾟｰﾟ==3) +'_') [(ﾟｰﾟ) - (ﾟΘﾟ)]+(ﾟДﾟ) ['c']+((ﾟДﾟ)+'_') [(ﾟｰﾟ)+(ﾟｰﾟ)]+ (ﾟ
Дﾟ) ['o']+((ﾟｰﾟ==3) +'_') [ﾟΘﾟ];(ﾟДﾟ) ['_'] =(o^_ô) [ﾟoﾟ] [ﾟoﾟ];(ﾟεﾟ)=((ﾟｰﾟ==3) +'_') [ﾟΘﾟ]+ (ﾟДﾟ) .ﾟДﾟﾉ+((ﾟ
Дﾟ)+'_') [(ﾟｰﾟ) + (ﾟｰﾟ)]+((ﾟｰﾟ==3) +'_') [o^_ô -ﾟΘﾟ]+((ﾟｰﾟ==3) +'_') [ﾟΘﾟ]+ (ﾟωﾟﾉ +'_') [ﾟΘﾟ]; (ﾟｰﾟ)+=(ﾟΘﾟ); (ﾟ
Дﾟ)[ﾟεﾟ]='¥¥'; (ﾟДﾟ).ﾟΘﾟﾉ=(ﾟДﾟ+ ﾟｰﾟ)[o^_ô -(ﾟΘﾟ)];(oﾟｰﾟo)=(ﾟωﾟﾉ +'_')[c^_ô];(ﾟДﾟ) [ﾟoﾟ]='¥"';(ﾟДﾟ) ['_'] ( (ﾟ
Дﾟ) ['_'] (ﾟεﾟ+(ﾟДﾟ)[ﾟoﾟ]+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟ
εﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_ô) +(o^_ô))+ ((o^_ô) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+
((o^_ô) +(o^_ô))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+((ﾟｰﾟ) + (ﾟΘﾟ))+ (c^_ô)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟｰﾟ)+ ((o^_ô) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟ
εﾟ]+(ﾟΘﾟ)+ (ﾟΘﾟ)+ (c^_ô)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+
(ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ ((ﾟｰﾟ) + (o^_ô))+ (ﾟДﾟ)[ﾟ
εﾟ]+((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟｰﾟ)+ (c^_ô)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟΘﾟ)+ ((o^_ô) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟ
Θﾟ)+ (ﾟｰﾟ)+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_ô) +(o^_ô))+ ((o^_ô) +(o^_ô))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (ﾟΘﾟ)+ (ﾟ
Дﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_ô) - (ﾟΘﾟ))+ (o^_ô)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ (ﾟｰﾟ)+ (o^_ô)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_ô)
+(o^_ô))+ ((o^_ô) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((ﾟｰﾟ) + (ﾟΘﾟ))+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_ô) +(o^_ô))+
(c^_ô)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟΘﾟ)+ ((o^_ô) +(o^_ô))+ (ﾟｰﾟ)+ (ﾟДﾟ)[ﾟεﾟ]+(ﾟｰﾟ)+ ((o^_ô) - (ﾟΘﾟ))+ (ﾟДﾟ)[ﾟεﾟ]+((ﾟｰﾟ) +
(ﾟΘﾟ))+ (ﾟΘﾟ)+ (ﾟДﾟ)[ﾟoﾟ]) (ﾟΘﾟ)) ('_');
http://utf-8.jp/public/aaencode.html

View Slide

そもそもフロントエンドでの
セキュリティの必要性って？

View Slide

フロントエンドでのセキュリティの必要性
「セキュリティってバックエンド側の仕事では？」
多くの部分はバックエンド側
けれどフロントエンド側も無関係ではない
典型的にはDOM-based XSSなど
「Webアプリ」ではないstaticなWebサイトでも脆弱性が生まれる
// 脆弱なコード例
// http://example.jp/#
element.innerHTML = decodeURIComponent(location.hash);

View Slide

staticなWebサイトでも脆弱性が生まれる
実例: とあるサイトの404ページ

The requested URL was not found
on this server.

...
var url = location.href;
var elm = document.getElementById('link');
elm.innerHTML = '' + url + '';
http://example.jp/#">... などでXSS<br/>

View Slide

「Webアプリ」ではないstaticなWebサイトでも脆弱性が生
まれることがある
あらゆるサイトにおいてフロントエンドでもセキュリティへの配慮
が必要

View Slide

セキュリティの基礎概念：オリジン

View Slide

オリジン
オリジン - Webにおけるセキュリティの境界を指し示す概念
プロトコル、ホスト、ポートの組み合わせを「オリジン」と定義
正規化して表記
RFC 6454 - The Web Origin Concept https://tools.ietf.org/html/rfc6454
プロトコルポート
ホスト
URL オリジン
http://example.jp:8080/foo/ba http://example.jp:8080
http://example.jp:80/foo?q=abc#def http://example.jp
https://example.jp/ https://example.jp
https://www.example.jp/foo/ https://www.example.jp
http://example.jp:8080/foo/bar

View Slide

オリジンの比較
リソース間が同じオリジンかどうかは正規化して比較する
URL 1 URL 2 オリジン
http://example.jp/index.html http://example.jp/favicon.ico 同一オリジン
http://example.jp/index.html http://example.jp/test.txt 同一オリジン
http://example.jp/index.html https://example.jp/test.txt
スキーム名が異なるので
同一オリジンではない
http://example.jp/index.html http://img.example.jp/image.png
ホスト名が異なるので
http://example.jp/index.html http://example.jp:8080/index.html
ポート番号が異なるので

View Slide

同一オリジンとクロスオリジン
同一オリジン - 同じオリジン内のリソースへのアクセス
クロスオリジン - 異なるオリジンへのリソースのアクセス
example.jpのJSからapi.example.jpのJSONを読む等
同一オリジンのアクセスは無制限、クロスオリジンのアクセ
スでは制限がある - 同一オリジンポリシー(Same Origin
Policy; SOP)
フロントエンドのセキュリティ = オリジン間でのアクセスをコ
ントロールすること

View Slide

DOM-based XSS

View Slide

DOM-based XSS
JavaScriptによってHTMLを操作する際に発生するXS
// http://example.jp/#
element.innerHTML = decodeURIComponent(location.hash);
// 脆弱なコード例その2: もう少しだけ複雑な例
// http://example.jp/#/foo/bar.html などを想定しているが攻撃者が
// http://example.jp/#http://攻撃者.jp/ などに誘導するとXSSとなる
const url = decodeURIComponent(location.hash.substr(1));
fetch(url)
.then(res => res.text())
.then(text => element.innerHTML = text);

View Slide

DOM-based XSS
攻撃者の与えた文字列をもとにHTMLを操作することで発生
攻撃者の与えた文字列をもとにHTMLを操作することで発生
処理シンク
ソース
location.hash
xhr.responseText
document.referrer
Fetch / Response
postMessage
window.name
location.search
location.href document.write
eval
location.href
innerHTML setInterval
Function
setTimeout
攻撃者のコントロールできる文字列文字列からHTMLを生成したりコードとし
て実行する箇所
ソースシンク

View Slide

DOM-based XSS
対策
文字列ではなく正しくDOMを操作する
textContentやsetAttributeなどを用いる
リンク生成時はhttp://あるいはhttp://のみに制限する
javascript:スキームなどを生成させない
JSライブラリの更新も忘れずに。
JSライブラリにDOM-based XSSが存在することもある
JavaScriptセキュリティの基礎知識：連載｜gihyo.jp … 技術評論社 https://gihyo.jp/dev/serial/01/javascript-security
最近のJavaScriptフレームワークでのXSS | ">はい https://blog.ssrf.in/post/modern-javascript-framework-xss/
クリック!

View Slide

mXSS – Mutation-based XSS
HTMLElementから文字列、文字列からHTMLElementへ
の変換は非対称となる場合がある
String HTMLElement
HTMLElement
異なるHTML
// 古いIEで発見されたmXSSの始祖

...
div2.innerHTML = div1.innerHTML; // となる
mXSS Attacks: Attacking well-secured Web-Applications by using innerHTM Mutations https://cure53.de/fp170.pdf
文字列からHTMLを組み立てる話 http://utf-8.jp/public/20140807/shibuyaxss.pdf

View Slide

IEだけの問題ではない

<a id="">

...
div2.innerHTML = div1.innerHTML; // 脆弱性あり
Write-up of DOMPurify 2.0.0 bypass using mutation XSS https://research.securitum.com/dompurify-bypass-using-mxss/
▼
▼

▼<br/><a id="">

▼

<a id="

"">
"

View Slide

対策 : HTMLElementを文字列として操作しない
innerHTMLのコピーではなくcloneNodeを使う
iframe sandboxを使う
DOMPurifyなどのmXSSを考慮したライブラリを使う
GitHub - cure53/DOMPurify https://github.com/cure53/DOMPurify
HTML5 and Security Part 4 : DOM based XSS http://utf-8.jp/public/20140908/owasp-hasegawa.pdf

View Slide

オープンリダイレクト

View Slide

オープンリダイレクト
攻撃者が指定した任意のサイトにリダイレクトさせられる脆
弱性
// http://example.jp/#/next/page など自サイト内の遷移を想定
const url = decodeURIComponent(location.hash);
if (url.charAt(0) === '/') {
location.href = decodeURIComponent(location.hash);
}
攻撃者が http://example.jp/#//evil.example.com/ などを
与えると他のサイトにリダイレクトされてしまう

View Slide

対策
URLインターフェースを使ってオリジンを確認する
// http://example.jp/#/next/page など自サイト内のみ遷移可能
const url = new URL(
decodeURIComponent(location.hash), location.href);
if (url.origin === location.origin) {
location.href = decodeURIComponent(location.hash);
}

View Slide

オリジン間の保護のしくみ

View Slide

オリジン間でデータを保護するための様々な仕組みが用意
されている
X-Frame-Options will soon die
CSP – Content-Security-Policy
CORS – Cross-Origin Resource Sharing
CORP – Cross-Origin Resource Policy
CORB – Cross-Origin Read Blocking
SameSite Cookie

View Slide

X-Frame-Options
クリックジャッキングを防ぐためのレスポンスヘッダー
指定することで、同一オリジン以外のページからframe/iframe等
で埋め込むことができなくなる
…が、徐々に規格が縮退方向
これからはCSPの frame-ancestors を使うのがいい
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: sameorigin
X-Frame-Options: Allow-From ディレクティブが削除されました | Firefox サイト互換性情報
https://www.fxsitecompat.dev/ja/docs/2019/x-frame-options-allow-from-directive-has-been-removed/

View Slide

されている
SameSite Cookie

View Slide

CSP – Content-Security-Policy
レスポンスヘッダーで指定することでリソースの読み込み
元を制限できる
 リソースはデフォルトで自ドメインに限定される
 画像は任意のサイトから取得可能
 それ以外のオリジンからのリソースは読み込まれない。インラインのスクリプ
トも動作しない
攻撃者がXSSで挿入したスクリプトは動かなくなる
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Security-Policy: default-src 'self'; img-src *
alert(1) // 動かない
// 動かない
// 動く

View Slide

違反時のレポート送信
ブロックせずレポート送信のみ
様々なソース指定
フレームの親の制限
フォームの送信先の制限
Content-Security-Policy: default-src 'self'; report-uri https://example.jp/
Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://example.jp/
コンテンツセキュリティポリシー (CSP) - HTTP | MDN https://developer.mozilla.org/ja/docs/Web/HTTP/CSP
Content-Security-Policy - HTTP | MDN https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Content-Security-Policy
img-src / media-src / font-src / script-src / style-src / ....
Content-Security-Policy: frame-ancestors 'self' https://example.jp
Content-Security-Policy: form-action 'self' https://example.jp

View Slide

適切にCSPを設定することでXSSの脅威を大きく低減するこ
とが可能
report-onlyであっても攻撃を早い段階で把握可能
許可したサイト上にDOM-based XSSのある古いJSライブラ
リが残らないように注意
example.jp上にXSSのある古いJSライブラリが存在していると
CSPをバイパスされてしまう
Content-Security-Policy: script-src https://example.jp

View Slide

されている
SameSite Cookie

View Slide

CORS – Cross-Origin Resource Sharing
他のオリジンからデータを読んでいいかの許可を与える
GET / HTTP/1.1
Host: example.jp
htpps://example.jp/ htpps://sub.example.jp/
fetch('//sub.example.jp/')
.then(text => ...);
GET / HTTP/1.1
Host: sub.example.jp
Origin: https://example.jp
HTTP/1.1 200 OK
Content-Type: text/plain
Access-Control-Allow-Origin: https://example.jp
オリジン間リソース共有 (CORS) - HTTP | MDN
https://developer.mozilla.org/ja/docs/Web/HTTP/CORS
fetch('//sub.example.jp/')
.then(text => ...);

View Slide

Origin:ヘッダー自体は攻撃者は自由に送信可能
ブラウザー内で読み込ませないために使う
（受動的攻撃への対策)
機密情報に対しての認証は別途必要
$ wget --header='Origin: https://example.jp' https://sub.example.jp/
fetch('https://sub.example.jp/', {credentials: 'include'}).then(...)
GET / HTTP/1.1
Host: sub.example.jp
Cookie: session=0123456789ABCDEF
Origin: https://example.jp
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.jp
Access-Control-Allow-Credentils: true
Access-Control-Allow-Credentials - HTTP | MDN https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Access-Control-Allow-credentials

View Slide

CORSで指定することでクロスオリジンなJSからリソースを
操作することができる
Access-Control-* レスポンスヘッダーで細かな制御が可能
XHR / fetch APIだけでなくimgやvideo要素でのcrossorigin属
性も利用可能
特定条件を満たさない場合(Content-Typeが標準的でない等)、
プリフライトリクエストと呼ばれるOPTIONSメソッドが事前に発行
される(今日は説明を省略)
画像の読み込みに認証付きのCORS通信が使われ、画像提供側がACAOヘッ
ダーを適切に返せば画像データをJSから操作可能になる

View Slide

されている
SameSite Cookie

View Slide

CORP – Cross-Origin Resource Policy
他サイトからの画像やJSの読み取りを制限する
このリソースは同一オリジンからのみ読み込みが可能
潜在的なサイドチャンネル攻撃への対策
HTTP/1.1 200 OK
Cross-Origin-Resource-Policy: same-origin
攻撃者は罠サイト上で example.jp の画像やスクリプトを読みこみ他の脆弱
性(Meltdown/Spectre等)と組み合わせて内容を盗み見ようとする

Cross-Origin Resource Policy (CORP) - HTTP | MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

View Slide

されている
SameSite Cookie

View Slide

CORB – Cross-Origin Read Blocking
クロスオリジンでのリソースの読み込み時にContent-Type
が不一致であれば読み込みをブロックする機能
JavaScriptや画像としてJSONやHTMLを読み込むのを防ぐ
CORPと同様に潜在的なサイドチャンネル攻撃への対策
レスポンスヘッダーの指定などは不要
自動でブロックされる
// ブロックされる

Cross-Origin Read Blocking (CORB) - Chrome Platform Status https://www.chromestatus.com/feature/5629709824032768
3.5. CORB - Fetch Standard https://fetch.spec.whatwg.org/#corb

View Slide

CSP, CORS, CORP, CORBの位置付け
攻撃者の作成した罠サイト経由でデータを読み込まれるこ
とへの防御機構が充実
攻撃者による罠サイト
htpps://攻撃者.jp/
攻撃対象となる正規サイト
htpps://example.jp/
CORS CORP
CORB
攻撃者による罠サイト
htpps://攻撃者.jp/
攻撃対象となる正規サイト
htpps://example.jp/
CSP
img, script,
iframe, ...
XSS, form,
...
CSP
frame-ancestors

View Slide

されている
SameSite Cookie

View Slide

SameSite Cookie
Cookieの送信を同一サイト内に限定する仕組み
サイトが異なるリソースからのや XHR、fetch などでCookieが送
信されなくなる
 strict
クロスサイトでのCookieを一切送信しなくなる
 lax
リンククリックでのページ遷移など(top-level navigation)を除きCookieを送信しなくなる。
、などではCookieが送信される
Set-Cookie: session=0123456789ABCDEF; httponly; secure; samesite=strict
Set-Cookie: session=0123456789ABCDEF; httponly; secure; samesite=lax
draft-ietf-httpbis-rfc6265bis-03 - Cookies: HTTP State Management Mechanism https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.3.7

View Slide

SameSite Cookie
攻撃者の作成した罠ページからのiframeやscript、form
postなどでCookieが送信されなくなる
CSRFへの対策となる
クロスオリジンでのデータ漏洩を低減させる
今後、各ブラウザーのCookieは samesite=lax がデフォル
トになる
Chrome、Firefox、Edgeなどは、IETFの提案であるIncrementally Better Cookiesに沿ってデフォルトの動作を
変更し、次のようにします。
① SameSite 属性のないCookieは SameSite=Lax として扱われ、デフォルトの動作でCookieをファースト
パーティコンテキストのみに制限されます。
② クロスサイトで使用するCookieには明示的に SameSite=None; Secure を指定することでサードパーティ
のコンテキストに含めることができます。
これは、Chrome 80のデフォルトの動作になり、2020年2月の安定版リリースが予定されています。現在、クロス
サイトでの使用を目的としたCookieを提供している場合、新しいデフォルトをサポートするには、その日までに変
更する必要があります。 SameSite cookie recipes https://web.dev/samesite-cookie-recipes/

View Slide

まとめ

View Slide

まとめ
静的なHTML+JSだけでもセキュリティの問題が発生する
DOM-based XSS等
セキュリティの境界条件としてオリジンという概念が使われ
る
オリジン = プロトコル + ホスト + ポート
オリジン間のデータ保護の仕組みが多数ある
CSP、CORS、CORP、CORB、SameSite Cookie
今日紹介できなかったもの
SRI、Fetch metadata、XS-Search、XS-Leaks、...

View Slide

質問?
[email protected]
@hasegawayosuke
セキュアスカイ・テクノロジー検索

View Slide

これからのフロントエンドセキュリティ

これからのフロントエンドセキュリティ

hasegawayosuke

More Decks by hasegawayosuke

Other Decks in Programming

Featured

Transcript