IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない

(Last Updated On: 2019年2月1日)

IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。

重大な誤りとは以下です。

• CWE-20 – 出鱈目なデータを排除する検証（入力バリデーション）について一切記載がない

コンピューターサイエンス／システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング／セキュアプログラミングの導入を要求しています。

ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題などが発生した場合、契約で定めた上限以上の損害賠償を課されるリスクが高くなります。法的な意味からも現在のIPAの「安全なWebサイトの作り方」は危険であると言えます。

※ 開発者が「入力バリデーションはしている」と思っている場合でも、穴だらけで脆弱／非効率で問題あり、である場合がほとんどです。MVCモデルのモデルでバリデーションしている！といった場合、ほぼ100％不十分なバリデーションしかしていません。そんなドイツ人開発者と議論した事もあります。

CVEとCWE-20

実際にどのようなCWE-20脆弱性が報告されている実例で見ると解りやすいかも知れません。

CVE DetailsではCWE-20かつCVSS 8.0以上といった検索も可能です。CWE-20無視は危険すぎる、と一目瞭然です。

「安全なウェブサイトの作り方」はCWEに対応するセキュリティガイドであるかのように記述されていますが、この危険なCWE-20脆弱性を完全に無視するソフトウェアセキュリティの常識ではあり得ないガイドになっています。

「入力バリデーションによるセキュリティ対策」が必須であることは容易に解ります。

• ソフトウェアセキュリティ問題の大半はプログラムの誤作動（特にインジェクション問題）
• 誤作動の大半は”妥当でない入力データ”（＝”不正な入力データ”）によって発生（特にインジェクション問題）
• ”妥当でない入力データ”に対してどのような処理を行ってもセキュリティ問題の原因となる（出鱈目なデータを出力時点で無害化しても、データ自体は出鱈目であり問題の原因となる。出力以前にプログラムロジック処理の何処かで望まぬ動作、例えばバッファーオーバーフローによる任意コード実行など、の原因になる可能性がある）

これらの事から

• 大半のセキュリティ問題は”妥当な入力データ”であること検証し、”不正な入力データ”を受け入れなければ防止／緩和できる
• ライブラリなどの未知の脆弱性も防止／緩和できる
• 入力バリデーションにセキュリティ対策が必須である

と解ります。日々見付かる未知であった致命的問題に自動的に対応できる場合が少なくないのが入力バリデーションによるセキュリティ対策です。

よくある勘違い 〜 出力時のインジェクション対策だけがセキュリティ対策ではない 〜

IPAの「安全なウェブサイトの作り方」は、ソフトウェアセキュリティ対策全てをカバーするものではない、と前置きしています。ソフトウェアセキュリティ対策を簡潔に網羅することは不可能なので仕方がありません。

しかし、全てをカバーしていないとした上で”出力時”のインジェクション対策”だけ”を解説しています。これは著しい瑕疵がある解説です。SQLインジェクション対策を例に問題点を紹介します。

SQLインジェクション対策の「根本的対策」として次の3つを挙げています。

• SQL文の組み立ては全てプレースホルダで組み立てる
• SQL文の組み立てを文字列連結により行う場合は、エスケープ処理等を行うデータベースエンジンのAPIを用いて、SQL文のリテラルを正しく構成する。
• ウェブアプリケーションに渡されるSQL文を直接指定しない

この3つの項目名だけ見れば何とか合格点になりそうですが、3つ目の「ウェブアプリケーションに渡されるSQL文を直接指定しない」の解説が不十分です。

これは、いわば「論外」の実装ですが、hidden パラメータ等に SQL 文をそのまま指定するという事例 の届出がありましたので、避けるべき実装として紹介します。
ウェブアプリケーションに渡されるパラメータに SQL 文を直接指定する実装は、そのパラメータ値の 改変により、データベースの不正利用につながる可能性があります。

本来はここでCWE-20（入力バリデーション）の重要性を解説すべきです。

例えば、$this_col, $this_table, $this_orderがユーザー入力であった場合、

SELECT $this_col FROM $this_table ORDER BY $this_order

といったクエリを実行したい場合、ユーザー入力となっている変数はすべて”識別子”（テーブル名やカラム名）なので

• プレイスホルダは使えない （パラメーターのみ対応）
• エスケープも使えない （識別子エスケープではインジェクション対策にならない）

となります。

$sql = ‘SELECT ‘. escape_identifier($this_col) . ‘ FROM ‘. escape_identifier($this_table) .’ ORDER BY ‘. escape_identifier($this_order);

と”識別子”をエスケープしても攻撃者はデータベース上のテーブルとカラムに自由自在にアクセスできます。データベースアクセス抽象化ライブラリなどでない限り、テーブル名やカラム名を変数で自由自在に設定できるソフトウェアは少数だと思われます。しかし、 ORDER BY でカラム名指定は頻繁に利用されます。抽出カラム名指定も少くないでしょう。

※ 「これにはSQL命令が含まれないから、不正なDBアクセスを許してもSQLインジェクションではない」といった言葉遊びには多くの開発者は興味がないでしょう。不正なデータベースアクセス全般をSQLインジェクションとすべきで、その方が開発者にも理解り易く対策もし易いです。CERTのセキュアコーディング原則7では「他のシステムへの出力を無害化する」としています。SQL対策ならこのブログで紹介しているような対策が必要です。

2つ目も問題があります。

• SQL文の組み立てを文字列連結により行う場合は、エスケープ処理等を行うデータベースエンジンのAPIを用いて、SQL文のリテラルを正しく構成する。

「リテラルを正しく構成する」としていますが、SQLクエリを生成する際にユーザー入力が入り込む余地は、リテラルだけではありません。

• リテラル – SQLクエリのバラメータ
• 識別子 – SQL構造を識別する名前（プログラミング言語でいう変数名）
• SQL語句 – SQL文を構成する命令（ORDER BYの”DESC”や”ASC”）

リテラルだけ正しく構成してもSQLインジェクションは防げません。これらの対策を「根本的対策」とし「これで十分である」としている点です。

根本的対策はCERTのセキュアコーディング原則の1番目（入力バリデーション）と7番目（出力の無害化）の両方です。 ※ IPA版では順番を変えていますが、オリジナルの順序にしています。順番を変えるといったローカライズは不必要では？

入力データがアプリケーションにとって妥当であるか徹底的にバリデーションした上で、出力時点で無害化を実施しないと安全なWebサイトにはなりません。これは私が勝手に主張している意見ではなく、世界の著名なセキュリティ専門機関／セキュリティ専門家が主張している意見です。（ただしIPAを除く、でしたが）

インジェクション対策には入力バリデーションが欠かせない

CWEを管理するMITRE／CWEプロジェクト自身の脆弱性対策まとめガイドの中で最も重要なセキュリティ対策だとし、CWE-20 未検証入力を残すことは自殺行為であるとしています。

もし開発者が入力データが期待している物でないか確認していないなら、問題を起こしてくれ、と頼む事と同じである。

CWE/SANS Top 25 Monster Mitigations M1

※ Mitigation（緩和策）はセキュリティ対策ではない、とするおかしな議論も耳にしたことがありますが、ISO 27000の定義から緩和策はセキュリティ対策です。詳しくは「情報セキュリティとは？」の項を参照。何がセキュリティ対策で、何がセキュリティ対策ではない、といった議論は無駄でしかありません。出力対策だけでは完全なセキュリティ対策には絶対にならず、プリペアードクエリも緩和策、でしかありません。科学的／エンジニアリング的にまとめられたISO定義を使うべきでしょう。

入力対策（入力バリデーション）がないインジェクション対策はあり得ません。この説明がないだけで「安全な◯◯の作り方」としては失格です。 医師国家試験の一つでも間違えると不合格となる禁忌肢問題と同じです。

以前のISO 27000は”入力バリデーションだけ”は詳しく仕様を解説し、現在のISO 27000は”セキュアプログラミング技術は体系的にまとめられ普及した”として、”セキュアプログラミング技術の導入”を要求しています。CWEはISOの指す体系的にまとめられたセキュアプログラミング（セキュアコーディング）技術の一つです。

コンピューターサイエンスの基礎の基礎

コンピューターサイエンスの基礎として形式的検証を何らかの形で習うと思います。形式的検証には論理的検証（数学的検証）と総当たり的な検証があります。どちらも「入力データは妥当であること」を前提に検証します。

論理的検証では「妥当でない入力データ」はそもそも考慮する対象でさえありません。 コンピューターは妥当でない入力データでは絶対に正しく動作しないからです。

総当たり的検証でも「妥当でない入力データ」はそもそも考慮する対象でさえありません。不正なデータまで計算すると簡単に発生する組み合わせ爆発がより簡単に発生します。コンピューターは妥当でない入力データでは絶対に正しく動作しないので、検証対象のプログラムロジック処理部分では不正なデータを考慮せずに済むようバリデーションしておくのが定石です。

コンピューターサイエンス（≒システムエンジニアリング）では、入力データの妥当性をできるだけ早い段階で保証しておくのが安全なプログラム（＝正しく動作するプログラム）を作る大前提となっています。

だからこその、CWE/SANS Top 25 Monster Mitigations （怪物的セキュリティ対策）の一番目 M1: Establish and maintain control over all of your inputs. が入力の制御（＝徹底した入力バリデーション）です。

コンピューターサイエンス／システムエンジニアリングの基礎を理解しないで「安全なウェブサイトの作り方」を書いた疑いがあります。

情報セキュリティとは？

IPAの「安全なウェブサイトの作り方」は「情報セキュリティ」の定義も、しっかり理解した上で作られていない可能性もあります。

情報セキュリティの定義がいい加減だとその対策の定義もいい加減（曖昧）になります。定義から異なるとコミュニケーションが出来ません。このような状態を避ける為に、ISOといった国際標準規格が各国合意の基に作られています。

皆さんご存知の通り、情報セキュリティの国際標準規格はISO 27000シリーズです。そのタイトルは「Information security management systems」（情報セキュリティマネジメントシステム）となっています。ISO 27000では用語を定義しています。一般に”セキュリティ対策”と言われる用語は「リスク対応」として定義されています。

2.69 リスク対応（risk treatment）

リスク（2.68）を修正するプロセス（2.61）
JIS Q 0073の3.8.1参照

注記1 リスク対応には、次の事項を含む事がある
ー リスクを生じさせる活動を、開始又は継続しないと決定することによって、リスクを回避すること。
ー ある機会を追求するために、リスクをとる又は増加させること。
ー リスク源を除去すること。
ー 起こりやすさを変えること。
ー 一つ異常の他者とリスクを共有すること（契約及びリスクファイナンシングを含む。）。
ー 情報に基づいた選択によって、リスクを保有すること。

注記2 好ましくない結果に対処するリスク対応は、”リスク軽減”、”リスク排除”、”リスク予防”及び”リスク低減”と呼ばれることがある。

注記3 リスク対応が、新たなリスクを生み出したり、又は既存のリスクを修正したりすることがある。

JIS Q 27000 : 2014 2.69 リスク対応（risk treatment）

※ JIS Q 27000はJIS規格化されたISO 27000の日本語版

要するに国際情報セキュリティ標準では、他の定義と合わせて

• リスクを変化させるモノすべてをリスクとして管理すること

を情報セキュリティ対策としています。情報セキュリティは以下のように定義されています。

2.33 情報セキュリティ （information security)

情報の機密性（2.12）、完全性（2.40）、及び可用性（2.9）を維持すること。

注記： さらに、真正性（2.8）、責任追跡性、否認防止（2.54）、信頼性（2.62） などの特性を維持することを含めることもある。

入力データの妥当性検証なしで、外部出力の無害化だけで、機密性も完全性も可用性も真正性も責任追跡性／否認防止も、信頼性も維持できません。

IPAの「安全なウェブサイトの作り方」では安全なWebサイトは作れない

全てのWebサイト開発者が「徹底した入力データバリデーションを当たり前に行っている」状態であるなら、CWE-20の解説を省略しても構わないでしょう。しかし、現実は正反対です。

CWE/SANS Top 25 Monster Mitigations M1: Establish and maintain control over all of your inputs. では

全ての入力に対して標準的な入力バリデーションを使わなければならない。

・ 長さ
・ 入力種別（訳注： 期待される形式）
・ 少すぎる又は多すぎる入力
・ 関連するフィールドとの整合性
・ ビジネスルール

とし、以下の項目をバリデーションしなさいと明示しています。

パラメーターまたは引数、クッキー、ネットワークから読み込み全てのデータ、環境変数、DNSの逆引き、クエリ結果、リクエストヘッダー、URLやその一部、Eメール、ファイル、データベース、アプリケーションにデータを提供するあらゆる外部システム。 これらの入力はAPI呼び出しによって間接的に取得されることがあることを忘れてはならない。

このアドバイスを実施していれば、Struts2の脆弱性により東京都の納税サイトから何十万件ものクレジットカード情報が盗まれることはありませんでした。こういった事例は数えきれません。

安全なソフトウェアアーキテクチャーは論理的帰結として導き出せます。

具体例を再掲＆追加説明

IPAの「安全なWebサイトの作り方」に記載されている対策だけでは、”無効な入力”による厄介な組み合わせ爆発が防げないだけでなく、容易に攻撃できるWebアプリが出来上がります。例えば、実用的アプリでは特定のカラムを抽出／ソートするSQLクエリは一般的です。プリペアードクエリ／エスケープではSQLインジェクションは防げません。対策には厳格な入力バリデーションが必須です。

脆弱なPHPコード例

pg_query_params(
‘SELECT ‘. pg_escape_identifier($_GET[‘col’]) .
‘ FROM ‘. pg_escape_identifier($_GET[‘table’]) .
‘ WHERE type = $1 ORDER BY ‘.
pg_escape_identifier($_GET[‘sort_col’]),
[$_GET[‘type’]]);

$_GET[‘col’], $_GET[‘sort_col’], $_GET[‘table’]は”識別子”ですが、「安全なWebサイトの作り方」には”識別子”のエスケープが記載されていません。（わざわざDBのAPIを利用した”リテラル”（＝クエリパラメーター）のエスケープに限定した記載はある。PHPのPostgreSQL APIには私が追加した識別子エスケープがかなり前から在りますが、他の多くのシステムには識別子エスケープAPIが無かったり、そもそもMySQL、SQLite、OracleやMS SQL Serverの様に、DBのアクセスAPIに識別子エスケープAPIが無かったりする。）

”識別子”エスケープ（pg_escape_identifier）が無い場合、自由自在にどんなSQLクエリでもインジェクションできます。

”識別子”エスケープをしても、”識別子”の内容（カラム名／テーブル名）に不正な識別子名をインジェクションされると、データが盗み放題になります。（だったらバリデーションのみで識別子エスケープは要らないのでは？と思った方も居るかも知れません。識別子エスケープは必要です。DBアクセス抽象化ライブラリを作る場合、DBが受け入れ可能な識別子”すべて”（SQL予約語、日本語文字列、スペースを含む文字列など）を処理できるように作ります。この為には識別子エスケープは必須です。また、最も多い識別子インジェクションパターンのODER BY $colに対して、識別子エスケープは有効です。）

プリペアードクエリ（一般的なプレイスホルダも）は”識別子”に対して無力です。よくあるSQL語句によるインジェクション（ORDER BYのASC/DESCへのインジェクション）にも無力です。

全体を通して「プリペアードクエリを使えば安全！」といった記述ですが、安全ではありません。

同様の致命的な問題は他のインジェクション攻撃でも起こります。入力バリデーション（CWE-20）の記載がないインジェクション対策の解説は、まともなセキュリティガイドとしてはあり得ません。

更に付け加えると、”出力先”に対する解説が脆弱すぎます。同じ出力先（ブラウザ／DBなど）でもコンテクストによって異なる出力対策が必要です。これについて記述が無いです。初心者が容易に脆弱なソフトウェアを作ってしまいます。こういったケースに対応するため、個別の出力対策ではなく、CWE/SANS Top 25 Monster Mitigations M2のように一般的な出力対策の記述が必要です。これも在りません。CWEベースのガイドラインで、CWE/SANS Top 25は2011年に記述されているにも関わらず、にです。

その上に、マトモなソフトウェアセキュリティ専門家が見たら噴飯物であるWAFの導入を勧める解説まであります。

「安全なウェブサイトの作り方」類似のソフトウェアセキュリティガイドにOWASP TOP 10があります。2017年版のOWASP TOP 10にはA10: Insufficient logging & monitoring がありますが、これを導入する直前のRC版では「脆弱性と対策の記述がWAFを強く薦め、必須かのような記述がWAFの広告のようにもとれる」ことが問題になり、RC版まで担当していたプロジェクトマネージャーが交代、リリースを遅らせWAFが必須かのような記述を無くした記述でリリースされました。

OWASPでは「WAFが必須のように思わせる／匂わせる解説」だっただけでも責任者が交代する一方、IPAの「安全なウェブアプリの作り方」では「直接WAFが必要」とする記述になっています。OWASP/CERT/MITRE/ISOなどのセキュリティ専門家から、「どこのセキュリティ業者の広告なのか？」と言われても仕方ないでしょう。

リリースを延期したOWASP TOP 10:2017策定の際には「いっそ2004年版のUnvalidated Input（未検証入力）を復活させた方が良いのでは？」とコメントしました。「入力バリデーションだけして安全だ、と勘違いするユーザーが居て危険だから…」と返信がありました。CWE/SANS TOP 25も個別の脆弱性対策とセキュアコーディングの基本要素は別に記述しています。こういう記述方法の方が誤解が少ないのは確かです。OWASP TOP 10 A1:2017のインジェクション対策にはホワイトリスト型の入力バリデーションも対策として記述されてるので、内容的にも問題ありません。

現代のプログラミングでは、同じ／同類の処理であっても一箇所にまとめる事（共通コード化）はプログラミング原則ではありませんが、昔は原則として考えられていました。これの影響が大きいのか「入力バリデーションによる”セキュリティ処理”をしたら、出力のセキュリティ処理は無用／重複」と省略してしまう開発者は存在します。共通コード化は現代のプログラミングでは原則とは考えられていません。共通コード化を原則としたらオブジェクト指向プログラミング（カプセル化）は成立しません。

CWE本家のMITREでは7PKも導入しており、7PKではSSL等の「セキュリティ機能」が魔法のような対策にはならない、と解説しています。SSL”だけ”では十分なセキュリティ対策にならないし、普通の設定（ブラックリスト型）のWAFも同じです。IEEE Explorerの7PK（CWE-700）の解説の言葉を借りるなら「WAF（セキュリティ機能）は、ソフトウェアセキュリティではない」（Security feature is not software security）です。理解り易く言うと「WAFはソフトウェア開発者が作っているアプリケーション／ソフトウェアのセキュリティではない」です。（WAFは「ライブラリのセキュリティ機能」に置き換え可能です。ライブラリのセキュリティ機能はソフトウェア開発者が作っているアプリケーション／ソフトウェアのセキュリティではありません、基本的には。詳しい解説は長くなるので省略しますが、これが参考になります。）

WAFを利用し、セキュアコーディング原則#1の「入力をバリデーションする」を省略するには、WAFによる入力バリデーションを検証し、安全であると保証（アプリに対して妥当な入力と保証）できなければ、アプリによる入力バリデーションを省略できません。Webアプリ開発者がWAFで安全であると保証（アプリに対して妥当な入力と保証）していることを検証するくらいなら、Webアプリ開発者が直接アプリ内で検証した方が効率が良いのは言うまでもありません。Webアプリ開発者向けのセキュアコーディングガイドでWAF導入を勧めるのは支離滅裂です。一般的なWebアプリ開発者（プログラマ）の業務として、WAFの導入とメンテナンス、は含まれてもいませんし、WAF経由でも”外部入力は外部入力のまま”です。

もし医師国家試験のようなソフトウェアセキュリティ専門家試験があったとしたなら、アプリによるCWE-20（入力バリデーション）を知らない／無視するような回答をしたなら一発不合格となる”禁忌肢問題”になるはずです、ISO 27000やNIST SP800-171に従うと。

※ 禁忌肢問題： 他が全て正解でも、この一問を間違えると致命的な間違いとなり不合格となる問題。

まとめ

IPAの「安全なウェブサイトの作り方」はCWEを参照し、セキュアプログラミング技術の導入ガイドとなるような体裁になっていますが、内容が安全なアプリケーションソフトウェアの作り方としては落第です。

”落第”とするのはキツい言い方かも知れませんが、ISMS（ISO 27000）対応、NIST SP800-171対応、セキュアプログラミング／セキュアコーディングを要求されたアプリケーションで入力バリデーションがない、未検証入力があるようでは失格と言われても仕方ありません。内容が安全なソフトウェアの作り方としては落第、は甘んじて受け入れざるを得ないのではないでしょうか、IPAは。

※ 因みに、IPA「セキュアプログラミング講座」（恐らく2017年改訂）でも、セキュアプログラミングの第1原則は「入力をバリデーションする」です。これの改訂も遅過ぎですが、改訂から一年以上経って「安全なウェブサイトの作り方」を改訂していない、これも重大な瑕疵ではないでしょうか？因みに、 CWE/SANS Top 25は2011年、CERT Top 10 Secure Coding Practicesは何時からから不明ですがコメントは2009年から存在します。ISO 27000はその前身のISO 17799（2000年）から入力バリデーションの方法を具体的に紹介しています。来年は2019年です。ほぼ20年間はどこに行ったのでしょうか？

「安全なウェブサイトの作り方」はCWEを多数引用し解説しているので尚更性質が悪いと言えるでしょう。MITRE/CWEが”やらないと自殺行為”とする入力バリデーションの解説が一切ないのはあり得ないセキュリティガイドと言われても仕方ありません。

インジェクション対策の基礎の基礎は、入力対策と出力対策の両方を実施して十分な対策になります。（入力対策にはロジックバリデーションも含まれます）

CWE-20を無視して喜ぶのは、Webサイトを攻撃する犯罪者やWebサイトの脆弱性を外部から見つけ出して商売にしているセキュリティ業者だけです。IPAが犯罪者や業者の片棒を担ぐようなセキュリティガイドを長年公開し続けているのは大問題ではないでしょうか？

※ アプリケーションで入力バリデーションするよう啓蒙せずに、WAFによる保護（弱く／非効率な入力保護）、を紹介しているのは何故でしょうか？IPAは入力検証の価値を理解っていながら、セキュリティ業者の都合を忖度している、と思われても仕方ありません。

IPAはISO 27000などの国際情報セキュリティを推進する立場です。ISO 27000の定義と合致しない情報セキュリティでは意味がないどころか、職務放棄とされても仕方ないでしょう。

参考： IPAは出鱈目だった「セキュアプログラミング講座」をやっと最近、最低限の体裁程度の修正を行いました。「安全なウェブサイトの作り方」も早急に修正し、間違いだった点を理解り易く啓蒙すべきでしょう。

簡単にまとめると

• コンピュータープログラムは妥当なデータ（≒ 検証済みデータ）でしか正しく動作しない（動作原理）
• セキュリティ問題となる動作のほとんどが未検証データ（≒ 不正なデータ）と無害化漏れによる誤作動
• 遅すぎる無害化は問題の原因にしかならない （不正なデータに対して何らかの処理がされるのは有害でしかない。注：動作原理より）
• セキュリティ機能はソフトウェアセキュリティではない（WAFはソフトウェアセキュリティではない）

これらを理解していれば「安全なウェブサイトの作り方」は、CWE-20（入力バリデーション）の解説なく、ソフトウェアセキュリティガイドはあり得ない危険なガイドとなっている、と解ります。

最後に、IPAがダメだ！、とばかり思っているのではありません。実際、ここで引用したCWE/SANS Top 25の策定にはIPAも関わっています。CWE/SANS Top 25の怪物的なセキュリティ対策の一番目は入力バリデーション（CWE-20）です。入力バリデーションだけは具体的に解説し、セキュアプログラミング／セキュアコーディング技術を導入すべし、としているISO 27000にも関わっていす。縦割りの組織、がいけないのでしょうか？！

※ 蛇足です。「安全なウェブサイトの作り方」のタイトルが「ウェブアプリ」ではなく、「ウェブサイト」である点が”逃げ道”として付けられているのかも、と感じるのは考え過ぎでしょうか？ 内容的には”Webアプリ開発者”が対象ですが、「ウェブサイト」とすることにより”Webアプリ開発者”ではなく”Webサイト管理者”も対象になり得ます。Webサイト管理者の立場なら、WAFを導入する、は普通のセキュリティ対策です。WAFを導入できるなら、私も導入に大賛成です。しかし、これは”Webアプリ開発者”が対象のハズの内容です。”Webアプリのセキュリティ対策”として”サイト管理者”が追加するWAFに”開発者”が頼るような内容にする”言い訳”となるタイトルとしたなら大問題です。個人的にも論理的にもWAFを導入できるなら導入すべき、とは思っています。とは言っても、Webアプリ開発者は”WAFに頼るべきではありません”。アプリでの完全な入力バリデーション（ホワイトリストによる厳格な入力バリデーション）を実装すべきです。どうしてもWAF導入を強く進めたいなら、別途に「Webサイト”管理者”向け」のガイドを作るべきです。何れにせよ、IPAはできる限り早くWAFベンダーのホワイトペーパーのような「安全なウェブサイトの作り方」は「ソフトウェアセキュリティガイドとして間違であった」と広く啓蒙し、”Webアプリ開発者”が”安全なWebアプリ”を開発できるようにすべきだと思います。「安全なWebアプリの作り方」と「安全なWebサイトの作り方」は別物（ソフトウェアセキュリティとシステムセキュリティは異なる物）です。曖昧に成り得るのでタイトルも直した方が良いでしょう。

※ 蛇足2です。 こうやって「当たり前のこと」を長々と説明しなければならないのは、一番にすべき基礎／基本の「キ」であるCWE-20（入力バリデーション）を無視していることが原因です。最初のボタンを掛け違えると、後になって連鎖的に問題が生まれます。一番にすべき「当たり前のこと」（＝必須の前提条件＝CWE-20）を無視するので、こんなに長々とした駄文を書かなければならない状態になります。必須の基礎／基本を疎かにしては何時まで経ってもセキュアになりません。IPAの方は「PCを使えない大臣」を笑っている場合ではないと思います。以下のような「セキュリティ専門家」による支離滅裂なセキュアコーディング概念の啓蒙も早急に何とかして下さい。

付録： IPAと入力バリデーション

少なくともIPA的には2000年頃から、少なくとも入力バリデーションぐらいは最低限のセキュリティ対策として確実に実施するようにとすべきである、とIPA自身が認識していたはずです。今は2019年ですが！

IPAは20年も前から「安全なWebアプリの作り方」の基礎の基礎を知っていたはずなのに、どうしてこうなったのでしょう？！

IPAと入力バリデーションの簡単な歴史です。最近の物から順に紹介します。

CWE-20とIPAの新セキュアプログラミング講座

旧セキュアプログラミング講座は支離滅裂な内容でした。（2017年頃に最低限の体裁を整えるよう修正済み） 新セキュアプログラミング講座はまともな内容になりました。新セキュアプログラミング講座のCERT Top 10 Secure Coding Practicesを採用し第一原則は

• 入力をバリデーションする （CWE-20と同等）

に修正されました。

現在のIPAの「セキュアプログラミング講座」で、IPA自身が第一の原則として入力バリデーションを実施せよ、としています。

入力バリデーション（CWE-20）を無視する「安全なウェブアプリの作り方」が安全であるハズがありません、2017年からIPA的にも。

IPAとCWE/SANS Top 25 Monster Mitigation M1（入力バリデーション）

新「セキュアプログラミング講座」よりももっと古いセキュリティガイドラインにIPAは関わっています。

2011年に公開されたCWE/SANS Top 25で「怪物的なセキュリティ対策／恐ろしく効果的なセキュリティ対策」としているのがMonster Mitigation M1（CWE-20で入力バリデーション）です。

実はこのCWE/SANS Top 25の編集者にはIPAの名前も在ります。その中で「怪物的なセキュリティ対策／恐ろしく効果的なセキュリティ対策」であるとしているのがCWE-20（入力バリデーション）です。

入力バリデーション（CWE-20）を無視する「安全なウェブアプリの作り方」が安全であるハズがありません、2011年からIPA的にも。

IPAとISO 27000/17799

CWE/SANS Top 25よりももっと古いセキュリティ標準の策定にもIPAが関わっています。ISO 27000/17799です。ISO 27000/17799ではセキュアコーディングの基礎の基礎である入力バリデーション”だけ”は実施するよう具体的に記述しています。その内容は、足りない部分もありますが、CWE-20と互換性がある内容です。

ISO 27000の前身であるISO 17799は2000年に公開されています。現在のISO 27000は「セキュアプログラミング技術の導入」を要求しています。入力バリデーション（CWE-20）はその第一の原則です。

入力バリデーション（CWE-20）を無視する「安全なウェブアプリの作り方」が安全であるハズがありません、2000年からIPA的にも。

※ 2000年頃にはまだIPAとして存在していませんでしたが、その前身は存在しておりIPAとして組織化されたはずです。間違っていたら教えてください。