Webアプリケーションセキュリティの定番『徳丸本』が8年ぶりに改訂するという。2026年7月に開催された「Hack Fes. 2026」で、第3版の改訂ポイントを著者・徳丸浩氏が解説した。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Webアプリケーションの開発やセキュリティに携わるITエンジニア必携の書と言ってもいい『徳丸本』こと、『体系的に学ぶ 安全なWebアプリケーションの作り方』は、2011年に初版が発行され、2018年には、Web API関連を中心に200ページ近く記述が加わった「第2版」が刊行された。
しかし、Web技術の進化と複雑化に伴い、新たなリスクや脆弱(ぜいじゃく)性が浮上している。こうした背景から2026年現在、「第3版」への改訂に向けた執筆が進められているという。
2026年7月に一般社団法人日本ハッカー協会が開催した「Hack Fes. 2026」に、筆者である徳丸浩氏が登壇。「徳丸本アップデート2026」と題して講演・ワークショップを実施した。同氏は第2版以降の大きな変化を「個人情報漏えいから事業被害へのシフト」と捉えており、その最新動向と第3版の改訂ポイントを2部に分けて解説した。
もともとWebアプリケーション開発者向けに書かれた徳丸本だが、脆弱性診断に携わる診断員にとっても「必携の書」となっている。そんな同書が初版から貫いてきた方針の一つは、手を動かしながら勉強できること。
もう一つは「実務に即したバランスの良い記述を心掛けていること」(徳丸氏)だ。「セキュリティのためなら会社が潰れてもいい」といった極端な主張ではなく、事業を守るためのセキュリティという点を重視して書かれてきた。
Webを取り巻く技術の進化は速く、Webブラウザに搭載される機能も増えている。それに伴って脅威も変化し、対応が求められる基準やガイドラインも更新されてきた。
第3版では、そうした新たな状況に対応した記述を追加するとともに、構成も見直し、実用性の高い項目から順に紹介する方針とした。「クロスオリジンリソースシェアリング」(CORS)を理解するには「クロスサイトリクエストフォージェリ」(CSRF)の知識が前提になるといった具合に、順序立てての理解が必要なものについては、その通りに読み進められるように整理しているという。
構成面での大きなポイントは、脆弱性やWebセキュリティに関する基礎知識、主要な脆弱性に続いて、丸々一章を割いて「セキュリティ要件」を記述していることだ。「第2版まであまり書いてこなかったセキュリティ要件とは何か、どう組み立てるかといった事柄をしっかり入れようとしています」(徳丸氏)
そして「ブラウザセキュリティと技術的な基礎」として同一オリジンポリシーやCORS、CSP(Content Security Policy)、TLS(Transport Layer Security)、DNS(Domain Name System)、さらに文字コードに関する説明をまとめる他、前半の章で触れられなかったレースコンディション(TOCTOU脆弱性)やHTTPリクエストスマグリング(HRS)といった高度な脆弱性に言及するという。一方で、クリックジャッキングやOSコマンドインジェクションといった、時間がたちながらも現役の脆弱性については、9章で「古典的(レガシー)な脆弱性」としてまとめていく。
8章では「セキュア開発プロセス」について言及し、CI/CD(継続的インテグレーション/継続的デリバリー)環境を前提としたツールやリスク分析のフレームワークなどを解説する他、昨今話題となっているソフトウェアサプライチェーンの問題にも触れていく。
徳丸本の特徴である実習環境もアップデートされる。Docker Composeベースの実習環境を用意し、従来利用してきたPHPの他、Node.jsやLaravelなど、現在の開発環境に即したフレームワークを題材に取り、「OWASP ZAP」に代えてWebアプリケーションセキュリティツール「Burp Suite」を用いた実習環境を用意していく。
また「『OWASP ASVS』(OWASP Application Security Verification Standard)がだいぶこなれてきたこともあり、『ASVS 5.0』や『NIST SP 800-63 Rev.4』といった最新のグローバルスタンダードに合わせています」(徳丸氏)という。
講演では、徳丸本第3版で網羅するトピックの中から、レースコンディション、HTTPリクエストスマグリング(HRS)、JWTによるセッション管理とそれに対する攻撃の3つについて、深掘りした説明が行われた。
レースコンディション(競合状態)は昔から存在する問題で、徳丸本でも初版から言及されていた。「他人の個人情報が見えてしまう、あるいはECサイトに在庫が1つしかないのに2人以上に販売できてしまう、というのが典型例で、割とよく見つかっていた問題です」(徳丸氏)
では、なぜ第3版でこのトピックを取り上げる予定なのか。
背景にあるのが、厚生労働省をはじめ複数省庁のWebサイトでレースコンディションに起因するセキュリティ問題が顕在化したことだ。デジタル庁の「政府情報システムにおける脆弱性診断ガイドライン」においても、Webアプリケーションの実装に起因する脆弱性の冒頭に「レースコンディションによるデータの不整合」という項目が挙げられている。
「『脆弱性診断員の友』としての徳丸本を考えますと、レースコンディションもしっかり書いておこうという考えです」(徳丸氏)
レースコンディションに起因する問題は幾つかあるが、中でも厄介なのが「TOCTOU(Time-of-check to time-of-use)競合」だ。
if文を用いた「もし在庫が1以上あれば、在庫を減らして注文を記録する」といった処理はWebアプリケーションでよく見掛ける実装だ。だが、if文でのチェックからthenで記述された処理を実行するまでの間にはわずかなギャップがある。「この時間的ギャップを狙った事象がTOCTOU競合です」(徳丸氏)
TOCTOU競合が発生すると、重要な同一ファイルが上書きされて他人の情報が見えてしまったり、前述のようにデータベースでは在庫が1つしかないのに複数人に販売してしまったりする事態が生じてしまう。
徳丸本第3版では、Burp Suiteを用いてTOCTOU競合の動きを確認できる実習環境が用意されており、「『もしも在庫があったら購入できる』という実に自然なif・then文の処理によって、TOCTOU競合が起きることを再現できる」(徳丸氏)と、講演ではデモも披露された。
「原因は、SELECT文による確認と、UPDATEによる操作が不可分(アトミック)ではなく、別々に実行されていることにあります。違和感があるかもしれませんが、いきなりUPDATEする、もしくは行ロックをかけて排他制御をすることが重要です」(徳丸氏)
このような対策を済ませれば適切な結果が返ってくることも、実習環境で確認できるという。
次に言及した「HRS」は、Burp Suiteを用いた脆弱性診断で時折検出される問題だという。端的に言えば、2つ以上のリクエストを、1つに見えるような形で細工して送信することで、リバースプロキシなどによるリクエストの検査をかいくぐる手法だ。
HRSを理解するためには「HTTP/1.1」の仕様を知る必要がある。HTTPリクエストにおいて、コンテンツ本体の「ボディーの長さ」を伝える手段には、長さを直接指定する「Content-Length」(CL)と、データを「チャンク」単位で分割送信する「Transfer-Encoding」(TE)の2種類が存在する。
RFCにおいては「両方が記述されている場合はTransfer-Encodingが優先される」と明記されている。しかし徳丸氏によると、仕様に反してContent-Lengthを優先してしまう実装が存在するという。
この解釈の不一致がHRSを引き起こす。実務的には、フロントエンドがCLで解釈し、バックエンドがTEで解釈する「CL-TE」のパターンが圧倒的に多いという。
Nginxをリバースプロキシに用いた場合、TEを優先するだけでなく転送時に不要なCLヘッダを削除するため、構造上HRSは起こり得ない。一方で、判定やヘッダの扱いが緩いリバースプロキシを挟んでいる場合に、HRSが発生することになる。
徳丸氏は「根本対策は『脆弱性のない(仕様に準拠し、適切にヘッダを処理する)リバースプロキシを使う』というだけですので、診断時にHRSというキーワードが出てきたらこのことを思い出してください」と述べた。
続けて徳丸氏が言及したのが「JWT」(JSON Webトークン)だ。
JWTは、OpenID ConnectでIDトークンを用いるための形式だ。扱いやすいことから、セッション管理に広く用いられるようになったが、「有効期間中は即時取り消しができないという欠点もあるため、結論としてはあまりお勧めできません」と徳丸氏は述べた。
辞書攻撃や「alg=none」攻撃、アルゴリズム交換攻撃といった「非常に素朴な、基本的な攻撃」(徳丸氏)が存在しており、徳丸本第3版では、HRSと同様に実習環境で試しながら学ぶことができるという。
「パスワード平文保存」が今なお繰り返される真因 徳丸浩が警告する「形だけのセキュリティ」
「ChromeとEdgeで430万人感染、“認定済み”拡張機能がマルウェア化」 気付けた現場は多分こんな感じ
「CTFはAIによって終わりました」 現役ハッカーが見た「人間の敗北」
「日本のセキュリティ信仰は構造的にズレてる」 コスパよく、すぐ救われる“左側”の防衛術Copyright © ITmedia, Inc. All Rights Reserved.