森 祥平（もり・しょうへい）／Shohei Mori
東京都生まれ。電気通信大学情報工学科を卒業後、株式会社インテック（現TIS）に入社。Javaを用いた大規模ECサイトの開発に従事。その後、外資系企業にキャリアを移し、半導体企業では組み込みソフトウェア開発、マルチメディア企業ではデスクトップアプリ販売、Googleではモバイルアプリの監査を担当。
2023年よりContrast Security Japan合同会社にてソリューションアーキテクトとして、Webアプリケーションの脆弱性検出ツールIAST（Interactive Application Security Testing）をはじめとする各種ソリューションの普及に努める。2025年より行動的生体AI認証ソリューションを取り扱うBioCatch社において、ソリューションエンジニアとして技術支援を行っている。
冬場は岩原及びニセコスキー場でスキー・スノーボードインストラクターを兼務。

ビジネス・ブレークスルー大学大学院 MBA首席修了
豪州BOND University MBA（履修済み全コア科目首席）修了

•  本書で紹介しているサンプルアプリケーション（本書では、やられアプリ、DSCLabとも表記）やソースコードは、著者が管理するGitHubリポジトリ「DSCLab（Django5 Secure-Coding Laboratory）」にて公開しています。本文中に登場するviews.py などのソースコードや、各章で利用するサンプルファイルは、以下のURLからダウンロードしてご利用ください。

   

  https://github.com/anoyoroshi/dsclab

   

  サンプルファイルの利用方法については、第2章「Pythonサンプル（やられ）アプリのセットアップ」および付録（Docker 環境 での利用やコマンド早見表）を参照してください。環境によっては動作や表示が異なる場合がありますので、適宜読み替えてご利 用ください。

誤記のためにご迷惑をおかけし、誠に申し訳ございません。

• 124ページ 「エスケープ処理とユーザ体験（UX）の両立」本文
  • [誤]
    エスケープ処理はセキュリティ対策に不可欠ですが、ユーザ体験にも配慮が必要です。過剰なエスケープ処理は、表示の崩れや意図しない文字列の表示を招き、ユーザ体験を損なう可能性があります。例えば、パスワード入力時、入力された文字が「●」でマスクされるのは、エスケープ処理の一例です。この処理により、周囲の人にパスワードを見られることなく、安心して入力できます。また、カスタマーサポートへの問い合わせでパスワードを聞かれないのも、エスケープ処理の概念が反映されています。パスワードリセットを促すのは、サポート担当者でさえパスワードを知ることができない仕組みになっているからです。
    これは、万が一不正ログインが発生した場合でも、システム側が「不正アクセスは内部関係者によるものではない」と証明するため、そして迅速に問題を切り分けるために必要な措置です。データベースに保存されたパスワードは暗号化され、担当者でも復号化できないようになっています。
  • [正]
    エスケープ処理はセキュリティ対策に不可欠ですが、ユーザ体験にも配慮が必要です。過剰なエスケープ処理は、表示の崩れや意図しない文字列の表示を招き、ユーザ体験を損なう可能性があります。なお、パスワード入力時に文字が「●」で隠されるのは、エスケープではなく「マスク表示」と呼ばれる別の仕組みです。これにより覗き見を防ぎ、安心して入力できるユーザ体験を提供しています。また、カスタマーサポートへの問い合わせでパスワードを聞かれないのも、適切なパスワード管理の原則が反映されています。パスワードリセットを促すのは、サポート担当者でさえパスワードを知ることができない仕組みになっているからです。
    これは、担当者がパスワードを知り得ない状態にして、内部関係者による不正利用の余地を減らすための措置です。データベースに保存されたパスワードはハッシュ化（8-3-2「ワンポイント」参照）され、元のパスワードを取り出せないようになっています。
  • 備考：

     ※1　パスワード入力時の「●」による伏せ字を「エスケープ処理の一例」としていた説明を、エスケープ処理とは異なる「マスク表示」の説明に訂正しました。

    ※2　カスタマーサポートがパスワードを聞かない理由を、「エスケープ処理の概念」から「適切なパスワード管理の原則」に訂正しました。

    ※3　「不正アクセスは内部関係者によるものではない」と証明できるという説明を削除し、「内部関係者による不正利用の余地を減らすための措置」という説明に改めました。

    ※4　保存時の処理を「暗号化」から「ハッシュ化」に訂正し、「担当者でも復号化できない」を「元のパスワードを取り出せない」に変更しました。あわせて、関連する説明として「8-3-2『ワンポイント』参照」を追加しました。

• 318ページ CSRF攻撃の条件：見出し＋導入文
  • [誤]
    ■CSRF攻撃の条件
    攻撃者がCSRFの罠を仕掛けるには、いくつかの条件を満たす必要があります。
  • [正]
    ■本書のサンプルにおけるCSRF攻撃の条件
    攻撃者が本書のサンプルアプリに対してCSRFの罠を仕掛けるには、いくつかの条件を満たす必要があります。
• 318ページ CSRF攻撃の条件：箇条書き1〜3の直後に追記
  • [誤]
    サンプルアプリでは以下の点が条件を満たしているため、罠を仕掛けることができました。
  • [正]
    ※これらは本書のサンプルを成立させるための条件であり、一般的なCSRFはユーザー名の指定がなくても成立します。また、GETメソッドを悪用した攻撃もあります。
    
    サンプルアプリでは以下の点が条件を満たしているため、罠を仕掛けることができました。
  • 備考：

     注意書きを追加しています

• 318ページ CSRF攻撃の条件：図表7-1-12を紹介する段落
  • [誤]
    CSRF攻撃の仕組みを視覚的に理解するために、図表7-1-12を見てみましょう。この図表は、最
    初に示した図表7-1-1に、CSRF攻撃における3つの重要な条件を追記したものです。
  • [正]
    図表7-1-12は、図表7-1-1に、本書サンプルのCSRF攻撃の条件を追記したものです。
• 319ページ 図表7-1-12の表題
  • [誤]
    図表7-1-12 CSRF攻撃における3つの重要な条件
  • [正]
    図表7-1-12 本書サンプルのCSRF攻撃の条件
• 351ページ 「CORS設定項目のsettings.pyにおける設定例」冒頭2行
  • [誤]
    # 全てのオリジンからのアクセスを許可 (開発環境のみ)
    CORS_ALLOW_ALL_ORIGINS = True
  • [正]
    # 全てのオリジンからのアクセスを許可（開発環境のみTrue、デフォルトはFalse）
    # CORS_ALLOW_ALL_ORIGINS = True
• 352ページ 「デメリット」内の補足
  • [誤]
    ・ CORSの設定ミスによって、XSS、CSRF、認証バイパスなどの攻撃のリスクが高まる可
    能性があります（後ほど説明します）。
  • [正]
    ・許可するオリジンや認証情報の設定を誤ると、意図しないWebサイトから機密情報を読み取られるおそれがあります。
• 352ページ CORSで防げる脆弱性：見出し＋リード文
  • [誤]
    ■CORSで防げる脆弱性
    CORSは、クロスオリジンリソース共有を安全に行うための仕組みであり、様々な脆弱性を利用した攻撃からWebアプリケーションを保護します。以下のような攻撃を防ぐことができます。
  • [正]
    ■CORSの役割とセキュリティ対策
    CORSは、ブラウザの同一オリジンポリシーによる制限をサーバの指示で緩和する仕組みです。XSSやCSRF、インジェクションなどを一般的に防ぐ仕組みではないため、各攻撃には原因に応じた個別の対策が必要です。
• 352ページ 箇条書き1〜3の全体
  • [誤]
    1.XSS（第5章参照）、CSRF（セクション7-1参照）
    ● 信頼できないオリジンからのスクリプトの実行を制限することができます。
    
    2.インジェクション系の攻撃（4-1-2参照）
    ● 信頼できないオリジンからのデータ送信を制限することができます。
    
    3.認証バイパス
    ● 攻撃者が認証を回避して、Webアプリケーションに不正にアクセスする攻撃。
    
    ● CORSは認証バイパス攻撃を直接防ぐものではありませんが、攻撃を抑制できる場合があります（例：ブルートフォースアタック（総当たり攻撃）のように、攻撃者が別オリジンから何度もログイン試行を行う場合、CORSで許可されたオリジン以外からのアクセスを制限することで、攻撃を困難にすることができます）。
    
    ● これはあくまで副次的な効果であり、CORSの主目的は認証バイパス攻撃の防止ではありません。認証バイパス攻撃を防ぐためには、強力なパスワードの使用、多要素認証の導入など、ビジネスロジックと呼ばれる認証システムそのものを強化する対策が必要です（第8章コラム内の「脆弱性とセキュリティ要件」参照）。
  • [正]
    1.XSS（第5章参照）、CSRF（セクション7-1参照）
    ● CORSでは防げないため、XSSにはエスケープ処理、CSRFにはトークン検証などを行います。
    
    2.インジェクション系の攻撃（4-1-2参照）
    ● ブラウザ外からの直接のリクエストはCORSで制限できないため、個別に対策を行います。
    
    3.認証バイパス
    ● 攻撃者が認証を回避して、Webアプリケーションに不正にアクセスする攻撃。
    
    ● CORSは認証バイパス攻撃を直接防ぐものではなく、ブラウザ以外からの直接のリクエストも制限できません。そのため、ブルートフォースアタック（総当たり攻撃）にはログイン試行回数の制限などで対応します。
    
    ● 認証バイパス攻撃を防ぐためには、強力なパスワードの使用や多要素認証の導入など、認証の仕組みそのものを強化する対策が必要です。あわせて、権限設定など、アプリ固有のセキュリティ要件（ビジネスロジック）も適切に実装します（第8章コラム内の「脆弱性とセキュリティ要件」参照）。
  • 備考：

     ※1　XSS・CSRFとインジェクション系の攻撃について、CORSが防ぐという説明を、それぞれ個別の対策が必要であるという説明に改めました。

    ※2　CORSでブルートフォースアタックを困難にできるという説明を、ログイン試行回数の制限などで対応するという説明に変更しました。

    ※3　「これはあくまで副次的な効果」という説明を削除し、認証の仕組みの強化と、アプリ固有のセキュリティ要件の実装についての説明に改めました。

• 352ページ ページ末尾の段落
  • [誤]
    CORSはこれらの脆弱性を利用した攻撃からWebアプリケーションを保護するために、重要な役割を果たしますが、SOPと同じくCORSは万能ではなく、全ての攻撃を防ぐことはできません。XSSやCSRFなどの脆弱性を完全に防ぐためには、CORS以外にも入力値の検証、出力のエスケープ、
  • [正]
    CORSは、異なるオリジン間でリソースを安全に共有するために重要な役割を果たしますが、XSSやCSRFなどへの対策ではありません。これらの脆弱性を防ぐためには、CORSとは別に、入力値の検証、出力のエスケープ、CSRFトークンの検証、
  • 備考：

    ※CORSの役割と脆弱性への対策を区別する説明に改め、対策の例に「CSRFトークンの検証」を追加しました。

• 353ページ 「SOP/CORSの設定ミスにおけるセキュリティリスク」の見出しと本文段落
  • [誤]
    ■SOP/CORSの設定ミスにおけるセキュリティリスク
    SOP/CORSの設定は、制限をよくよく考慮せずにWebアプリケーションを設計・実装すると予期せぬ動作やセキュリティリスクが発生する可能性があります。SOPの場合は、動作するはずのアクセスが制限されてしまったり、逆にCORSの場合はよくあるミスとして、Access-Control-Allow-Originヘッダにワイルドカード（*）を指定してしまうケースがあります。これは全てのオリジンからのアクセスを許可することを意味し、XSSなどの攻撃のリスクが高まります。CORSの設定を行う際は、以下の点に注意する必要があります。
  • [正]
    ■CORSの設定ミスにおけるセキュリティリスク
    CORSの設定は、制限をよくよく考慮せずにWebアプリケーションを設計・実装すると予期せぬ動作やセキュリティリスクが発生する可能性があります。よくあるミスとして、Access-Control-Allow-Originヘッダにワイルドカード（*）を指定してしまうケースがあります。これは全てのオリジンからのアクセスを許可することを意味します。ただし、Cookieなどの認証情報を伴うリクエストでは、「*」が指定されていてもブラウザは応答の読み取りを許可しません。「*」で問題になるのは、イントラネット内のサーバなど、ネットワーク上の位置だけで保護されている非公開情報が、利用者のブラウザ経由で意図しないWebサイトに読み取られる場合です。CORSの設定を行う際は、以下の点に注意する必要があります。
  • 備考：

     ※1　見出しと本文冒頭の「SOP/CORS」を「CORS」に変更し、「SOPの場合は、動作するはずのアクセスが制限されてしまったり、逆に」という部分を削除しました。CORSの設定ミスについての説明に整理しています。

    ※2　ワイルドカード（*）の指定によって「XSSなどの攻撃のリスクが高まります」としていた説明を削除し、意図しないWebサイトに非公開情報を読み取られる場合の説明に改めました。

    ※3　Cookieなどの認証情報を伴うリクエストでは、ワイルドカード（*）が指定されていても、ブラウザは応答の読み取りを許可しないことを追記しました。

    ※4　情報が読み取られる場合の具体例として、イントラネット内のサーバなど、ネットワーク上の位置だけで保護されている非公開情報が、利用者のブラウザ経由で読み取られるケースを追加しました。

• 401ページ 「ストレッチング（stretching）とは？」2項目目の参照見出し
  • [誤]
    7-4-2「CORSで防げる脆弱性」
  • [正]
    7-4-2「CORSの役割とセキュリティ対策」
• 420ページ 「認証」の箇条書き内の参照見出し
  • [誤]
    7-4-2「CORSで防げる脆弱性」
  • [正]
    7-4-2「CORSの役割とセキュリティ対策」

書籍の内容に関するお問い合わせはこちら。お答えできるのは本書に記載の内容に関することに限ります。

お問い合わせフォーム