Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Beyond "Never in JS"

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on. →

Beyond "Never in JS"

Reviewing and modeling threats for modern browser-based cryptographic systems (OWASP Saitama MTG #33, talk #1)

Avatar for Takahiro Yoshimura

Takahiro Yoshimura

August 17, 2026

More Decks by Takahiro Yoshimura

Other Decks in Technology

Transcript

  1. 2026.08.17 OWASP SAITAMA MTG #33 TALK #1 BEYOND "NEVER IN

    JS" “Impossibles” by Chris Pizzitola, CC BY-NC-ND 2.0
  2. TEXT BACKGROUND ▸ ブラウザ (HTML5) 環境での暗号系実装 ▸ ProtonMail: End-to-end encrypted

    webmail ▸ Web3 Wallets ▸ etc. “crypto” by delgrosso, CC BY-NC-SA 2.0
  3. TEXT BACKGROUND ▸ 一般論として暗号系はhigh-stake →間違うと生命に関わる種類の問題領域 ▸ 緻密な実装とPeer-reviewが欠かせない →"Don't roll your

    own."がマントラ ▸ 暗号系を利用したプロトコルの実装については 良くある要求事項 → 認証系, E2EE etc. “Enigma” by Jim Rees, CC BY-NC-SA 2.0
  4. TEXT WHAT I DO ▸ Security research and development ▸

    iOS/Android Apps →Financial, Games, IoT related, etc. (>200) →trueseeing: Non-decompiling Android Application Vulnerability Scanner [2017] ▸ Windows/Mac/Web/HTML5 Apps →POS, RAD tools etc. ▸ Network/Web penetration testing →PCI-DSS etc. ▸ Search engine reconnaissance (aka. Google Hacking) ▸ Whitebox testing ▸ Forensic analysis
  5. TEXT WHAT I DO ▸ ▸ CTF ▸ Enemy10, Sutegoma2

    ▸ METI CTFCJ 2012 Qual.: Won ▸ METI CTFCJ 2012: 3rd ▸ DEF CON 21 CTF: 6th ▸ DEF CON 22 OpenCTF: 4th 発表・講演など DEF CON 25 Demo Labs (2017) DEF CON 27 AI Village (2019) CODE BLUE (2017, 2019) CYDEF (2020) etc. “DEFCON 2016” by Wiyre Media, CC BY 2.0
  6. TEXT THREAT MODELING ▸ 分析にあたり脅威モデリングの手法を適用… ▸ Asset (保護対象) を想定し、それらに対する ▸

    Threats (脅威) をモデルし、それらに対する ▸ Mitigation (対策) を考えてゆく。 “Playbook Page” by playability_de, CC BY-NC-ND 2.0
  7. TEXT HTML5 APP ASSETS ▸ 守るべきもの … 非常にざっくりとしているが ▸ キー類

    (公開鍵/秘密鍵/共有鍵 etc.) ▸ 実装 (暗号系実装/プロトコル実装 etc) ▸ 保護対象 (平文/認証済セッション etc.) “crypto engine” by jean-daniel pauget, CC BY 2.0
  8. TEXT HTML5 DEADLY THREATS ▸ これもかなりざっくりと ▸ #1. Passive Attackers

    ▸ #2. Active Attackers ▸ #3. Origin-based Trust Boundary ▸ #4. Immature Codebase ▸ 見ていこう… “Deadly Pineapples” by arbyreed, CC BY-NC-SA 2.0
  9. TEXT STATIC/LOG ANALYSIS ▸ #1. Passive Attackers ▸ 静的解析攻撃 ▸

    JSにおける実質的なソース公開強制 ▸ 解析されて困るものは基本的に渡せない ▸ ログ解析攻撃 ▸ Consoleからログが読める “Sneak” by Tim Williams, CC BY-NC-SA 2.0
  10. fi TEXT STORAGE ANALYSIS ▸ #1. Passive Attackers ▸ ストレージ解析攻撃

    ▸ SessionやCookieは読まれる →秘密の保持が困難 ▸ cf. SOP (Single-Origin Policy) rst-partyが信頼できることが大前提 “Sneak” by Tim Williams, CC BY-NC-SA 2.0
  11. TEXT TRAFFIC ANALYSIS ▸ #2. Active Attackers ▸ トラフィック解析攻撃 ▸

    Network Inspector ▸ 通信内容に対する読み書き ・転送中のファイル etc. (ProtonMail?) ・リクエストのreplay etc. ▸ エンドポイントにおける攻撃なのでTLSは 役に立たないことに注意 “Avaritia” by Kimberley Jade Bleeker, CC BY-NC-ND 2.0
  12. TEXT HOSTILE RUNTIME ENVIRONMENTS ▸ #2. Active Attackers ▸ デバッグ攻撃

    ▸ Web Debugger / Console ▸ 内部状態への干渉 ▸ Consoleを開くなと警告を表示するケースし かり (facebook etc.) ▸ 拡張機能 (Extensions) ▸ 内部状態への干渉 “Avaritia” by Kimberley Jade Bleeker, CC BY-NC-ND 2.0
  13. TEXT COMPROMISED SERVICES ▸ #3: Origin-based Trust Boundary ▸ CDN/サプライチェーンにおける侵害

    ▸ SRI… だが相応のメンテ負荷がかかる ▸ Webサーバ自体の侵害 ▸ SRIでは対処できない; 署名ではないため e.g. スクリプト本体+SRI宣言置換→素通し (...ProtonMail?) “Compromised Integrity” by Nikk, CC BY 2.0
  14. TEXT ... ON VERIFYING SIGNATURES ▸ #3: Origin-based Trust Boundary

    ▸ cf. Signed HTTP Exchange (Chr. >= 73) ▸ SOP的に大問題+DigiCert必須 ▸ なぜこういう実装にした... generic過ぎ →実際に脆弱性の原因に https://i.blackhat.com/BH-USA-25/ Presentations/USA-25-Chen-Cross-OriginWeb-Attacks-via-HTTP2-Server-Push-andSigned-HTTP-Exchange-Thursday.pdf
  15. TEXT TRUST BOUNDARY MESS ▸ #3: Origin-based Trust Boundary ▸

    完全性の担保手段が基本的にTLSしかない …のだが必要になりすぎているために完全性検証 としての意味が薄まっている →TLSはそもそもデータの完全性は保証するが… ▸ APIにおける意図的な分断 (特にChrome) →何がSecure Contextなのか知らないがFSoS的 に有害なのでやめてほしい (e.g. WebCryptoですらhttps only) “A 9/16" sprinkle rainbow” by Tom Magliery, CC BY-NC-SA 2.0
  16. TRUST BOUNDARY MESS .. ▸ #3: Origin-based Trust Boundary ▸

    SOP: rst-party vs. others ▸ rst-partyに信頼を置きすぎ 使い勝手とのバランスだろうが、 negrainedにするか同一性検証が欲しい… ▸ だからXSSなんかがまだ問題になっている →HTML5アプリの場合XSSが致命傷 ▸ CSPがこの辺の問題に対する一つの答え fi “Yin-Yang” by ithinkchaos, CC BY-NC-SA 2.0 fi fi TEXT
  17. TEXT QUALITY PROBLEM ▸ #4: Immature Codebase ▸ プロトコル系実装への攻撃 ▸

    Formal veri cation toolsがJSには使えない fi “bag build failure” by Simon Liu, CC BY-NC-SA 2.0
  18. TEXT DEFENSE IN DEPTH ▸ 要素ごとに対策を粛々と考えていく ▸ Layer 1: Veri

    ed protocol implementation ▸ Layer 2: Reproducible build attestation ▸ Layer 3: SRI/subresource integrity ▸ Layer 4: Key transparency / audit logs ▸ Layer 5: Out-of-band veri cation fi fi “Inside Ljubljana Castle (Explore)” by Bert Kaufmann, CC BY-NC 2.0
  19. TEXT CORRECT IMPLEMENTATION ▸ Layer 1: Veri ed protocol implementation

    ▸ 実装に対する検証 ▸ 数学的証明付き実装 ▸ Peer-reviewが行き届いている実装 ▸ ハードウェア実装など fi “Math is beautiful” by Quinn Daedal, CC BY-SA 2.0
  20. TEXT INTEGRITY CHECKED BUILDS ▸ Layer 2: Reproducible build attestation

    ▸ 実行しているビルドに対する検証 ▸ 自己に対する署名確認 ▸ 行き届いた起動時self-testなど “Self Test” by N., CC BY-NC-ND 2.0
  21. TEXT VERIFIED DEPENDENCIES ▸ Layer 3: SRI/subresource integrity ▸ 依存関係に対する検証

    ▸ 参照時における正当性検証など https://developer.mozilla.org/en-US/ docs/Web/Security/Defenses/ Subresource_Integrity “Supply Chain” by Matthias Weinberger, CC BY-NC-ND 2.0
  22. TEXT VERIFIED ENTITIES ▸ Layer 4: Key transparency / audit

    logs ▸ 通信先およびその変遷に対する検証 ▸ 否認不能性の担保とほぼ同義 “Just Sign Here” by sbluerock, CC BY-NC-SA 2.0
  23. TEXT VERIFIED SERVICE ▸ Layer 5: Out-of-band veri cation ▸

    サービス提供元に対する検証 ▸ フィッシング対策とほぼ同義 fi “hello” by Alena Navarro- Whyte, CC BY-ND 2.0
  24. TEXT PICK YOUR DEFENSES ▸ 全部を完全に実施している必要はない ▸ 全て必要なケースもあれば ▸ 3と5だけあれば良いケースもある

    ▸ 脅威の分析とリスクの評価が大事 →大抵の場合3と5で十分だろうか… Untitled by Ryan Dickey, CC BY 2.0
  25. TEXT IMPLEMENTATION SHALL BE CORRECT ▸ 1を忘れてはいけない ▸ 暗号系については1 =

    WebCrypto ("Don't roll your own.") ▸ だが…プロトコルについては a) RFCなどに沿った信頼できる実装、か b) 証明付き実装 ▸ 証明を付けるのは大変なので一般的には a) …だが “Correcting…” by Eric E Castro, CC BY 2.0
  26. TEXT BRING YOUR PROOF ▸ 証明付き実装をしたい場合はどうしよう? ▸ WebAssembly (WASM) を使おう

    ※JSへの対応は多分時間の問題 ▸ e.g. Noise Framework [1]: NE [2] → ProVerif → Rust → WASM ▸ cf. Signal: F* → WASM ▸ [1] https://noiseprotocol.org/ [2] https://noiseexplorer.com/ “QED, bitch on the chalkboard” by Sharat Ganapati, CC BY 2.0
  27. TEXT SECURE YOUR ORIGIN ▸ Originの完全性をどう保証しよう? ▸ WebAuthnを使おう ▸ Passkey

    + SRIでそこそこの抵抗性 (RP attestation: サービス提供者に対する保証) ▸ もう少し緻密にやるなら: Passkey + PRFを使ってat-rest保護 (※1) したものを配 信し長期に渡りキャッシュさせておく (※2) など (mutual attestation: 妥当性の相互保証) ※1: 後述; ※2: must-revalidateなど付けてはいけない “Vintage Keys...” by Heartlover1717, CC BY-NC-ND 4.0
  28. TEXT CAN YOU KEEP A SECRET? ▸ 秘密をどう守ろう? ▸ WebAuthnのPRF拡張

    (§10.1.4) を使おう https://webauthn-passkeys-prfdemo.explore.corbado.com/ ▸ identityにbindされた256-bitの乱数を生成する拡張 ▸ 例えば以下のように暗号化キーを生成 (Kt = in-xit保護, Kr = at-rest保護) Kt = HKDF(s, M, b'transit', 256) Kr = HKDF(s, M, b'at_rest', 256) ※s=適当なsalt, M=PRF “Secret” by val.pearl, CC BY-NC-ND 2.0
  29. TEXT HTML5 DEADLY THREATS, RECTIFIED ▸ #1. Passive Attackers ▸

    静的解析攻撃 → WASM ▸ ストレージ解析攻撃 → at-rest保護 ▸ #2. Active Attackers ▸ トラフィック解析攻撃 → WASM/in-xit保護 ▸ デバッグ攻撃 → WASM “200128-N-CU072-1498” by U.S. Pacific Fleet, CC BY-NC 2.0
  30. TEXT HTML5 DEADLY THREATS, RECTIFIED ▸ #3. Origin-based Trust Boundary

    ▸ CDN/サプライチェーンにおける侵害 → SRI ▸ Webサーバ自体の侵害 → WebAuthn [mutual attestation] ※ただしdefacement程度に限る ▸ #4. Immature Codebase ▸ Insecure Protocol → formally veri ed WASM fi “200128-N-CU072-1498” by U.S. Pacific Fleet, CC BY-NC 2.0
  31. TEXT ... WITH HONEST LIMITATIONS ▸ だいぶ良くなったとは思うが… カバーし切れていないものはこんなところ ▸ Extensions:

    これでも保護し切れない ▸ ログ解析攻撃: ワークフローの工夫が必要 →リリースビルド時のログ出力自動撤去など ▸ Consoleからの干渉: API設計の工夫が必要 →JS interfaceを最小化するなど “Jailbreak” by Rachel Gonzales, CC BY-NC-ND 2.0
  32. TEXT TAKEAWAYS ▸ HTML5でも安全な実装は不可能ではない →証明付き実装とハードウェアによる相互確証が必要 →特にE2EE…これは一段と高い理想 ▸ WASMは重要な要素 →証明付き実装には必須 (F*,

    ProVerif, etc.) →解析耐性/デバッグ耐性に一定の優位性 ▸ WebAuthnは機密性/完全性に対する福音 →ハードウェアをrootに相互確証ができる →PRF拡張は暗号キーの生成に有用 “Summer takeaway” by Henry Söderlund, CC BY 2.0