■ 1. 徳丸本第3版への改訂
- 8年ぶりの改訂:
- 『体系的に学ぶ 安全なWebアプリケーションの作り方』は2011年に初版、2018年にWeb API関連を中心に200ページ近く加筆した第2版を刊行
- Web技術の進化と複雑化により新たなリスクや脆弱性が浮上したため、2026年現在は第3版への改訂に向けた執筆が進行中
- 第2版以降の最大の変化:
- 個人情報漏えいから事業被害へのシフトと捉えている
- 2026年7月のHack Fes. 2026で「徳丸本アップデート2026」と題し、最新動向と改訂ポイントを2部に分けて解説した
- 初版から貫く方針:
- 手を動かしながら勉強できること
- 実務に即したバランスの良い記述を心掛けること
- 「セキュリティのためなら会社が潰れてもいい」という極端な主張ではなく、事業を守るためのセキュリティを重視する
- 開発者だけでなく脆弱性診断員にとっても必携の書となっている
■ 2. 第3版の構成
- 実用性の高い順に配列:
- 新たな状況に対応した記述を追加するとともに構成も見直す
- CORSの理解にはCSRFの知識が前提になるなど、順序立てての理解が必要なものは順に読み進められるよう整理する
- セキュリティ要件に一章:
- 基礎知識、主要な脆弱性に続けて、丸々一章を割いてセキュリティ要件を記述する
- 第2版まであまり書いてこなかった、セキュリティ要件とは何か、どう組み立てるかをしっかり入れる
- ブラウザセキュリティと技術的な基礎:
- 同一オリジンポリシー、CORS、CSP、TLS、DNS、文字コードに関する説明をまとめる
- 前半の章で触れられなかったレースコンディション（TOCTOU脆弱性）やHTTPリクエストスマグリング（HRS）といった高度な脆弱性にも言及する
- 古典的な脆弱性の章:
- クリックジャッキングやOSコマンドインジェクションなど、時間がたちながらも現役の脆弱性は9章にまとめる
- セキュア開発プロセス:
- 8章でCI/CD環境を前提としたツールやリスク分析のフレームワークを解説する
- 昨今話題となっているソフトウェアサプライチェーンの問題にも触れる
- グローバルスタンダードへの追随:
- OWASP ASVSがだいぶこなれてきたため、ASVS 5.0やNIST SP 800-63 Rev.4といった最新の基準に合わせる
■ 3. 実習環境のアップデート
- Docker Composeベースの実習環境を用意する
- 従来のPHPに加え、Node.jsやLaravelなど現在の開発環境に即したフレームワークを題材に取る
- OWASP ZAPに代えてBurp Suiteを用いた実習環境を用意する
■ 4. レースコンディションとTOCTOU競合
- 昔から存在する問題:
- 初版から言及しており、他人の個人情報が見えてしまう、ECサイトで在庫が1つしかないのに2人以上に販売できてしまうのが典型例
- 割とよく見つかっていた問題である
- 第3版で取り上げる背景:
- 厚生労働省をはじめ複数省庁のWebサイトで、レースコンディションに起因するセキュリティ問題が顕在化した
- デジタル庁の「政府情報システムにおける脆弱性診断ガイドライン」でも、実装に起因する脆弱性の冒頭に「レースコンディションによるデータの不整合」が挙げられている
- 脆弱性診断員の友としての徳丸本を考え、レースコンディションもしっかり書く
- TOCTOU競合の仕組み:
- 「もし在庫が1以上あれば、在庫を減らして注文を記録する」というif文はWebアプリケーションでよく見掛ける実装である
- if文でのチェックからthenの処理を実行するまでのわずかな時間的ギャップを狙った事象がTOCTOU競合である
- 重要な同一ファイルが上書きされて他人の情報が見えたり、在庫が1つしかないのに複数人に販売してしまう事態が生じる
- 原因と対策:
- 原因はSELECT文による確認とUPDATEによる操作が不可分（アトミック）ではなく、別々に実行されている点にある
- 違和感があるかもしれないが、いきなりUPDATEする、もしくは行ロックをかけて排他制御をすることが重要である
- 実習環境での再現:
- Burp Suiteを用い、自然なif・then文の処理でTOCTOU競合が起きることを再現できる環境を用意し、講演ではデモも披露した
- 対策を済ませれば適切な結果が返ってくることも確認できる
■ 5. HTTPリクエストスマグリング
- 診断で時折検出される問題:
- Burp Suiteを用いた脆弱性診断で時折検出される
- 2つ以上のリクエストを1つに見えるよう細工して送信し、リバースプロキシなどによる検査をかいくぐる手法である
- 前提となるHTTP/1.1の仕様:
- ボディーの長さを伝える手段には、長さを直接指定するContent-Length（CL）と、チャンク単位で分割送信するTransfer-Encoding（TE）の2種類がある
- RFCでは両方が記述されている場合はTransfer-Encodingが優先されると明記されている
- しかし仕様に反してContent-Lengthを優先してしまう実装が存在する
- 解釈の不一致が原因:
- フロントエンドがCL、バックエンドがTEで解釈する「CL-TE」のパターンが実務的には圧倒的に多い
- Nginxをリバースプロキシに用いた場合、TEを優先し転送時に不要なCLヘッダを削除するため、構造上HRSは起こり得ない
- 判定やヘッダの扱いが緩いリバースプロキシを挟んでいる場合にHRSが発生する
- 根本対策:
- 仕様に準拠し適切にヘッダを処理する、脆弱性のないリバースプロキシを使うというだけである
- 診断時にHRSというキーワードが出てきたらこのことを思い出してほしい
■ 6. JWTによるセッション管理
- JWTはOpenID ConnectでIDトークンを用いるための形式であり、扱いやすさからセッション管理に広く用いられるようになった
- 推奨しない理由:
- 有効期間中は即時取り消しができないという欠点があるため、結論としてはあまりお勧めできない
- 攻撃手法:
- 辞書攻撃、「alg=none」攻撃、アルゴリズム交換攻撃といった非常に素朴で基本的な攻撃が存在する
- 第3版ではHRSと同様に実習環境で試しながら学べる
■ 7. セキュリティ要件の整理
- 問題意識:
- セキュリティ要件の検討が不足したまま開発が進み、不正利用が発生してサービス終了に追い込まれた残念なWebサービスが幾つか存在してきた
- 発注段階からセキュリティ要件を明確にし、それに沿って開発を進めるべきという考え方が浸透しつつある
- 誰がどう決めるかが不明確:
- そもそもセキュリティ要件を誰がどう決めるのかは、実はあまりはっきりしていない
- 発注仕様書には「個人情報が漏れないように作りなさい」といった当たり前であいまいな記述しかない場合がある
- これだけでは見積もりもテストもできず、セキュリティ要件とはいえない
- 4つの観点:
- セキュリティバグ（SQLインジェクションなどの狭義の脆弱性）
- 汎用セキュリティ機能の実装（認証・認可機能やログ機能など）
- 業界の規制・ガイドライン（PCI DSSやキャッシュレス推進協議会のガイドラインなど）
- アプリケーション固有の脅威への対策
- 初版出版当時から自問自答を続けてきたテーマであり、第3版で整理して説明する
■ 8. アプリケーション固有の脅威
- 観点1から3までの3つはどのようなWebアプリケーションにも共通し、徳丸本でも言及してきたため、問題は4点目である
- 認識されにくかった背景:
- Webアプリケーションには登場当初の「CRUDを簡単に作れる、掲示板みたいなもの」というイメージがつきまとってきた
- それゆえアプリケーションごとの固有のリスクを把握する必要性が認識されにくかった
- 現在の状況:
- Webアプリケーションは生活にもビジネスにも深く関わり、レストランでの注文にもチケット販売にも活用されている
- 転売業者がbotで人気商品を大量に買い占める問題のように、ビジネスロジック全体の問題をどう防ぐかという課題が浮上する
- 細かくばらせば既知の課題かもしれないが、Webシステム全体として見ると新たな課題となる
- これこそが、1から3の問題のようにこれまでリスト化されてこなかったアプリケーション固有の脅威である
- 第3版では、ビジネスロジックに固有の脅威を洗い出す道具としてリスク分析にも触れる
- シフトレフトの重要性:
- アプリケーション固有の脅威はできるだけ早く検討・対策を実行し、お金がかかるのであれば予算も手当しておくべきである
- 上流で実施すべき重要な事柄である
■ 9. リスク分析の進め方
- OWASP ASVS 5.0の位置付け:
- アプリケーション固有の脅威に限らず、観点1や2を検討する際の参考になる
- 初めにリスク分析をして要件を決めるべきという記述もある
- 裁量部分の判断にリスク分析が必要:
- セッションタイムアウト3時間は、オンラインバンキングでは長過ぎるが、頻繁に利用されるSNSでは利便性が損なわれる
- 必ず守るべき項目は抑えつつ、各Webサイトの裁量で決めるべき部分もあり、後者の検討にリスク分析が必要になる
- 一般的な流れ:
- アプリケーションのゴールという目指す姿について合意する
- 資産・機能の洗い出し、脅威の洗い出し、影響度・発生可能性の評価、対応方針と対応の検討を経てセキュリティ要件を定義する
- 事業側の巻き込み:
- 情報資産だけでなく、機能や機能にひも付く事業被害を洗い出すことがポイントであり、ビジネス・経営的な観点も求められる
- 目指す姿の合意にはDevやOpsに加えBiz、つまり事業主体が非常に重要である
- 全てのセキュリティは経営マターだと考えるのであれば、事業側の責任者を連れてくる必要がある
- STRIDEプラス1:
- なりすまし、否認、サービス妨害なども考えられるWebサービスの特性から、脅威分析モデルのSTRIDEが参考になる
- botによる大量購入のように正規の機能を悪用される脅威は枠組みからはみ出てしまう
- 無理にこじつけてSTRIDEに載せるくらいなら言葉で書き、STRIDEプラス1としてビジネスの問題として考える方がよい
- リスク分析における4種類のアプローチと、回避・低減・移転・受容というリスク対応の4つの方針を紹介した
- 最終的には人間が判断を下す必要があるが、AIを壁打ちに利用するのも非常に便利である
■ 10. 脅威の洗い出しと評価の実践
- ワークショップでは「レストランにおけるモバイルオーダーシステム」を例に、脅威の洗い出しと評価をする時間を設けた
- 洗い出しのヒント:
- Webサービスに関わる関係者にはどのような人がいるかを想像し、それぞれの立場で考える
- 過去に発生した事例を調べ、蓄積しておく
- アプリケーション固有のリスクもパーツに分解すれば他でも似たインシデントが起きているため、隣接領域の事例把握も有効である
- 評価の方法:
- 事象が発生したらどれくらい困るのかを3段階程度で分類し、発生可能性と掛け合わせてリスクの度合いを評価する
- 悪意ある顧客が他人のテーブルのQRコードを読み込んで注文する脅威は影響が中程度、発生可能性は高と評価した
- 解決策の検討姿勢:
- セキュリティ原理主義に走らず、ビジネス的な視点も考慮する
- 場合によっては一定のリスクを受容する
- システム的な改善だけでなく運用での回避も念頭に置く
- 「運用で対応」は批判されがちだが必ずしもそうとは限らず、効率的に対応できるのであれば選択肢の一つである
■ 11. 対策から要件への変換
- 列挙した対策がそのまま要件定義書に載るわけではない:
- 対策をそのまま記載すると、なぜそれが必要かという観点が失われてしまう
- 対策と要件を区別し、対策を満たすべき状態としての要件に変換していく
- 検証可能な記述:
- あまりに抽象的な記述では何をどうしたらよいか分からなくなり意味がなくなる
- 要件からテストまでを一気通貫でできる記述が望ましい
- 最上流での実施:
- 開発のど頭である最上流でリスク分析をすることで、結果に基づき固有の要件を追加できる
- 汎用的なセキュリティ機能をどの程度満たせばよいかの水準も選択できる
- アジャイル開発といえども、サービスの全体像を踏まえてどのようなリスクがあるかを上流で考えなければいけない
- 第3版では、リスク分析の指標としてOWASP ASVS 5.0の他、フランス国立情報局が作成したEBIOSというフレームワークを紹介する
■ 12. 結び
- これまでふんわりとした議論に陥りがちだったセキュリティ要件も、アプリケーション固有の脅威を含めた4つの観点で整理することでより考えやすくなる
- その際にはビジネス・事業責任者も巻き込んで検討することが重要である
- 日頃からリスクや脅威に対する思考を鍛え、習慣化しておくことが大切である
- 単純なものでも短時間でもよいので、ぜひ手を動かしてほしい