私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。
徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「アプリのバリデーションはセキュリティ対策ではない」としている方がWAFを売りやすいからです。
徳丸さんにもこのブログを書いたことを連絡し、もし誤解している部分があるのであれば反映したいと思います。これから紹介するように論理矛盾が明らかになった直後、今後議論をされないことを表明されましたが、この長いブログでも手法や論理的矛盾の誤りを指摘し尽くしていないので議論いたします。徳丸さん、反論を書かれるようであればご連絡ください。
追記：”原理／原則などに根拠がない”ことが判ったので議論することは無いのですが、IPAが誤りを正した後の2017年に間違ったセキュアコーディングを啓蒙されていました。これは指摘せざるを得ないのでブログに書きました。
科学的に出鱈目なセキュリティ対策で得をするのは、サイバー犯罪者とセキュリティ業者だけす。
TL;DR;
論理的思考で導ける必要条件と十分条件を理解している方にはここで解説している内容は読まずとも理解されていると思います。
これまでの議論の的
最近では「入力バリデーション」が議論の的でしたが、以前には以下のような点が議論になりました。随分長い前置きですが、それだけ議論が長かったということです。
- 文字エンコーディングのバリデーションはアプリ（入力バリデーション）で行う（私）
- 文字エンコーディングのバリデーションは言語などのインフラ（フレームワークなど）が行う（徳丸さん）
参考：入力値には3種類しか在りません。不正な値をプログラムで処理する意味は全くなくただ有害なだけです。2017年版OWASP TOP 10から入力バリデーションを行い、攻撃を検出／記録／対応しないアプリケーションは脆弱なアプリケーションになりました。
アプリにはフレームワークも含まれるので一部では一致しています。しかし、言語で文字エンコーディングを妥当性を保証するのは無理があります。PHP6は徳丸さんの主張されるような仕様を目指し失敗しています。Rubyも2.1になってからscrubメソッドが追加されました。文字エンコーディングバリデーションはアプリケーションの責任で行います。アプリ以外の場所では論理的に非効率かつ不完全だからです。
最近は「アプリ仕様としてバリデーションは当たり前に行う」と軌道修正されています。フレームワークを使っていても対応していない場合、フレームワークを利用しないアプリケーション／ソフトウェアの場合、フレームワークを作る場合、これらの場合はどうなるのだろう？という疑問は残ります。フレームワークにバリデーション補助機能があっても、その機能を使うのはアプリです。「アプリで対応する」と書けばどのような場合にでも明解です。
※ 多層防御の概念も当然必要です。ライブラリや関連コンポーネント（DBなど）での文字エンコーディングバリデーションは必要です。
- 「ホワイトリストはブラックリストに優先する」（私）
- 「ホワイトリストはブラックリストより優先するものではない」（徳丸さん）
参考： 開発者でなくても解るセキュリティ対策 – 入力バリデーション編
基本的にセキュリティ規格／ベストプラクティスでは「ホワイトリスト優先」です。ブラックリストは結果的に失敗し易い手法／思考方式です。ブラックリストで大きく失敗した例は枚挙にいとまがありません。このブログは論争の中でホワイトリストとブラックリストの違いが分らないとされたブログへの返信です。現在は「当たり前のアプリケーション仕様としてバリデーションを実装する」と考えを修正されています。そしてその方法は正にホワイトリスト方式（後半の入力定義参照）です。このことから「ホワイト／ブラックリスト論争」は「ホワイトリスト優先」で完結していると考えられます。
しかし、徳丸さんはホワイトリスト方式の入力バリデーションを推奨する私に非常に批判的でした。徳丸さんのブログ「ホワイトリスト方式の優位は神話」にあるように「神話」とまで比喩してホワイトリスト方式を優先／推奨することが間違いであるように記述されています。これは後のホワイトリスト型入力バリデーションを強く推奨する私への強い批判として、後の議論の的となります。
- 「SQLエスケープは基本的なセキュリティ対策」（私）
- 「SQLエスケープは必要ない」（徳丸さん）
参考：完全なSQLインジェクション対策にはエスケープ、APIとバリデーションが欠かせません。
比較的最近（確か昨年）、ツイッターの議論でSQLも必要と認められました。論理的／仕様的に識別子エスケープは必須（参考：実は標準の方が簡単で明解 – セキュリティ対策の評価方法の追記参照。論理的なセキュリティでは「残存リスク」であるSQL識別子エスケープへの対策は必須。）であるにも関わらず、必要ない、とすることが理解できませんでした。現在は徳丸さんもエスケープが必要とされています。
- 「入力バリデーションは一番のセキュリティ対策」（私）
- 「入力バリデーションはセキュリティ対策ではない」（徳丸さん）
参考： 第一のソフトウェアセキュリティ原則さえ普及しない最大の理由とは？
徳丸さんはセキュリティ対策として含めなければならない点を含めていなかった場合、当たり前に実装する物だというパターン（ここでの批判は今まで意味がよく分かりませんでした）でセキュリティ対策としてこなかったことを修正するのではなく、回避しています。
最初に書いた通り、WAFを販売しつつ、アプリの入力バリデーションはセキュリティ対策ではない、とする論理は長年謎でした。徳丸さんの影響かどうかは分かりませんが、比較的最近でも他の方とTwitterで議論になりブログを書いています。現在、徳丸さんはセキュリティ対策としてではなく、「（安全性向上の為に）当たり前に実装するアプリケーション仕様（それがセキュリティ仕様なのですが。。）として実装する」ようにとされています。これは従来から私が主張していた、頼るセキュリティ対策としてではない多層防御（これも論理的セキュリティの基本概念）と本質的には変わりません。「入力バリデーション」がセキュリティ対策であるか否か？のみが今では論点になっています。
- 「セキュリティ対策とはISO 27000の定義」（私）
- 「？？？」（徳丸さん）
これまで何度も徳丸さんのセキュリティ対策の定義は？と聞いてはいたのですが明解な回答は得られずにいました。定義を提示しない議論は、議論の進め方としても、セキュリティ専門家としても常々問題では？と感じていました。
セキュリティ規格やベストプラクティスでは私が主張する考えになっています。なぜ、このような根本的／基本的なセキュリティ対策認識で錯誤が生じ、何年も議論になったのか、原因は「まさか！」と思えるものでした。
徳丸浩流のセキュリティ対策とは
以下はツイッターでの議論です。多少長くなりますが、徳丸さんのセキュリティ対策とは次のような物です。
まずWAFを推奨／販売しつつ、本質的な部分は同じ（どちらもアプリの外側からの異常な入力を排除する対策）である入力バリデーションはなぜセキュリティ対策でないのか？聞きました。
徳丸さんとは長年議論してきましたが、徳丸さんの「セキュリティ対策」の定義を知らなかったので今回も聞いてみました。
意味が同じであるのに、用語が二つあり”区別”している？論理的錯誤がある可能性が高くなりました。
そもそも「セキュリティ対策」という言葉はあまりよくないと思います。「セキュリティ施策」とでも言ったほうが良いと思います。セキュリティ向上のための施策ですね。定義というほどのものではなく、セキュリティの施策です。
ここで私が徳丸さんの主張を論理的に理解できなくなりました。またいつもと同じ論理的には理解不可能な議論になるのか？と思いましたが今回は違いました。
そもそも「セキュリティ対策」という言葉はあまりよくないと思います。「セキュリティ施策」とでも言ったほうが良いと思います。セキュリティ向上のための施策ですね。定義というほどのものではなく、セキュリティの施策です。
意味の違いはありません。同じ意味で使っています。
「セキュリティ施策」＝「セキュリティ対策」と定義したう上で「セキュリティ対策とは？」の問いにこれらは「セキュリティ向上のための施策」と定義され、まだ不明確なままです。WAFも入力バリデーションも両方ともセキュリティを向上させるからです。またいつもと同じだと諦めるしかないか、と懸念しはじめました。
違うだろうと思いつつ「セキュリティを向上させる物（と自分が考える物）がセキュリティ対策」の定義ではないか？と思い質問しました。
そして、以下の回答を得ました。
ISO 27000では「セキュリティ対策（Security Measure）」という用語は直接定義していません。最も近いものはリスク対応策（Risk Treatment）でリスクを変化させる対策、緩和策、削減策、排除策、防止策などが含まれています。規格全体でセキュリティ対策（セキュリティマネジメント）の定義と言えます。
標準では「セキュリティ対策」を用語として定義していないからといって、自分の思い通りに使って良いものではありません。セキュリティ専門家であるなら尚更です。私はISO 27000 リスク対応策を「セキュリティ対策」の定義として使っています。この定義の場合、ある特定のセキュリティ対策がセキュリティ対策であったり、なくなったりすることはありません。セキュリティ対策か否かは結果（リスク変化）で判断し、セキュリティ対策自体の評価は効果（費用対効果）で判断します。このため個人の主観が入る余地が少なくまります。
セキュリティ対策を「リスク削減策／排除策」とし、リスクを”直接”低減／排除させる対策”だけ”がセキュリティ対策である、と誤解している方も多いです。しかし、セキュリティ専門家である徳丸さんが同じ勘違いをしているとは限りません。それを明確にする質問です。
そして、以下の回答を得ました。
対策の「主目的」が「セキュリティ対策」であるかどうかの基準？！
ITセキュリティリテラシに欠けるITシステムの一般利用者がこのように対策を理解するなら、まだ解ります。ITセキュリティ専門家なら問題です。
これはセキュリティ専門家として致命的な誤りです。セキュリティ対策の評価は、その「コスト」と「結果／効果」で判断すべきものです。これは基礎的なセキュリティ知識の一つです。セキュリティ的には対策の目的はあまり意味がありません。目的は正しくても、効果が低い対策、コストが高過ぎる対策などは利用できるセキュリティ対策として機能しません。
標準的なITセキュリティの基礎知識を理解してれば、対策の「目的」がセキュリティ対策であるかどうかの基準、となることはあり得ないです。セキュリティ対策であるかを「目的」で決るなら「主観」で対策かどうか変る事になります。しかも、「目的」で決るのではなく「”主”目的」であるかが区別要素のようです。客観性に欠ける決め方です。
まだ、まさか「主目的」が「セキュリティ対策か否か」を決める基準とはにわかには信じられませんでした。確認のための質問をしました。
セキュリティ専門家として重大な誤りをおかしているとは限りません。徳丸さん自身で強調されていましたが、ただの書き間違いか、想定していない他の意図があるのか確認しました。しかし、直後の回答は以下のメッセージでした。
議論が噛み合わないのは当然です。徳丸さんの主張の背景は「論理」ではなく「主観」でした。議論には定義や論理が必要です。定義／論理がなけば議論になりません。定義も基準もなく主観で議論すれば、議論にならないのは当然の結末です。私はこう思う、思わないと水掛け論になるだけで結論はありません。
徳丸さんは主目的がセキュリティ対策か否かの基準になる、との発言を否定されませんでした。ここで今迄の長い議論が終わらなかった根本的理由がやっと判明しました。同時にセキュリティ対策の定義は何ですか？と聞いても回答がない理由も判りました。
セキュリティ対策としてどんなに効果があっても、”徳丸さんの目的”としてセキュリティ対策でなければ、なんでもセキュリティ対策ではなくなる（またはその反対）、つまりSANSで一番のセキュリティ対策、OWASPで一番のセキュリティ対策もセキュリティ対策ではない、と徳丸さん流のセキュリティでは定義されると判りました。
ここで私のいう「任意実施施策」とは「セキュリティ対策として管理／実施する施策ではないセキュリティマネジメント対象外の施策になる」という意味です。
やっと徳丸さんのセキュリティ概念が理解できはじめました。
まだ、入力バリデーション、SQLセキュリティ、ホワイトリストセキュリティ、その他の件についてお聞きしたかったので非常に残念です。
これでツイッター上での議論はこれで終わりです。徳丸さんとの議論も終わりでしょう。やっと私と徳丸さんの「セキュリティ対策が異なるのか？」理解できたのでメンション無しで次のコメントを書きました。
今回の議論で
- WAFをセキュリティ対策として販売／推奨し、アプリのファイアーウォールといえる入力バリデーションをセキュリティ対策ではない
と主張する理由がはっきりしました。「徳丸さんがセキュリティ対策の主目的でない」と主観で判断すれば、セキュリティ対策であってセキュリティ対策でなくなる（またはその反対）だったからです。
昨年のPHPカンファレンスで行われた徳丸さんとの対談セッションで
- アプリプログラマはアプリ入力仕様を知っている。WAFでホワイトリストバリデーションは無理がある。アプリですべき（私）
- 私も賛成です（徳丸さん）
となった時、私はとても驚いたのですがこれで完全に理解できました。会場に居た方も少なからず驚いた様子でしたが、「徳丸さんがセキュリティ対策の主目的でない」と主観で判断すれば、アプリでの入力バリデーションはセキュリティ対策ではなかったのです。科学的であるかどうかを別にすれば、徳丸さんの主観から見ると筋の通った話になる、ということだったのです。
古い話になりますが、SQLにおけるエスケープの必要性の議論です。当時SQLite2しかないときに（SQLite2はエスケープのみ）
- SQLite2はエスケープしかないが？（私）
- SQLite2を使っているユーザーは少ない（徳丸さん）
※ 因みにSQLiteは現在世界で最も多く利用されているRDBMSです。今はプリペアードクエリもサポートしていますが、徳丸さん流のセキュリティでプリペアードクエリで大丈夫と思っていたら危険もあります。
この時も、かなり驚いたのですが自分の「目的」とするセキュリティ対策に合わない物を必要ない、セキュリティ対策ではない、と切り捨てていたことも理解できました。随分前の懇親会でのことなので徳丸さんは覚えていないかも知れませんが、私の本を見ながらの時です。酷く乱暴な議論だと驚いた私は良く覚えています。
他の論点も同じように説明できます。長くなるので省略します。もう十分説明できたと思います。
これまでの議論のまとめ
結論としては、これまでの議論は
- 標準に基く科学的／論理的なセキュリティ vs それ以外のセキュリティ
だったということです。主観によって結果や評価が変化する手法は科学的／論理的手法ではありません。WAFをセキュリティ対策とし、入力バリデーションをセキュリティ対策ではない、との主観的判断に論理的要素はありませんでした。
ホワイト／ブラックリスト論争も元をたどると「ブラックリスト型セキュリティのWAFは（直接問題を軽減する）セキュリティ対策」「（直接問題を軽減しないホワイトリスト型）入力バリデーションはセキュリティ対策できない」との考え方があったのだと推測できます。このため「ホワイトリスト型の入力バリデーションによるセキュリティ」を推奨していた私の考えは受け入れられなかったのだと思われます。
「入力バリデーションはできない」と勘違いした方を何人も見ましたが、WAFをセキュリティ対策と考えている徳丸さんが「入力バリデーションできない」と考えていたはずはありません。ブラックリスト型ですがWAFも入力バリデーションの一種です。正しくは「（ホワイトリスト型の）入力バリデーションできない」と考えていたのを「入力バリデーションできない」を強調しすぎたため少なくない方が混乱し、「入力バリデーションはできないものだ」と勘違いしたのでしょう。主観で区別した「セキュリティ対策」により「セキュリティ対策とは何が何だか解らない」状態であったのだと思われます。
SQLエスケープがセキュリティ対策として必要であるか、どうか？この議論も
- 標準に基く科学的／論理的なセキュリティ vs それ以外のセキュリティ
の違いが原因でしょう。標準セキュリティでは「リスクの変化」という「結果」に基づいてセキュリティ対策を評価／実施します。SQLセキュリティ対策を十分に行うにはパラメータのセキュリティ処理のみでなく基本的なリスク全てに対応、つまり残存リスクへの対応が必要になります。少し前のブログでこう書いています。
本来はもう少し踏み込んで「残存リスク」の評価とその対応までします。例えば、SQLインジェクションなら
- プリペアードクエリ
- 対応リスク：SQLパラメータ（リテラル）のセキュリティ処理
- 残存リスク：SQL語句の埋め込み（対応策：バリデーション）、SQL識別子（対応策：識別子エスケープ）
プリペアードクエリの残存リスクにSQL語句／SQL識別子埋め込みがあることは明白です。実際、SQL語句／SQL識別子によるインジェクション脆弱性は多く存在します。結果に基く論理的／科学的なセキュリティであれば、これらのセキュリティ対策も漏れ無く列挙します。「特定のアプリではSQL識別子はパラメータにならない」からといって「セキュリティ対策でなくなる」ということもありません。
そもそも標準的なセキュリティと徳丸さんの主張は相容れないモノでした。私がいくらISOでは、SANSやOWASPのベストプラクティスでは、と説明しても主観でセキュリティ対策が切り替わる方に受け入れられないのは当然のことでした。
結局、議論が起きた根本的な原因は
- 標準に基く科学的／論理的なセキュリティ vs それ以外のセキュリティ
でした。つまり私はもともと議論にならない議論をしてきた、ということです。科学的／論理的な標準やベストプラクティスに書いてある内容は誰でも読め、理解でき、実践もできる、と甘く考えていた私も反省しなければならないです。
何度かブログにも書いてきましたが、ITシステムの安全性にとって、特定の対策がセキュリティ対策かどうか？であることは全く重要ではありません。
- そのセキュリティ対策が効果的であるか？
これが重要な議論です。「これはセキュリティ対策」「これはセキュリティ対策ではない」は不毛で意味のない議論です。「これは効果的なセキュリティ対策」「これは効果的ではないセキュリティ対策」が有益な議論です。今後は有意義な議論をしましょう！
まとめ
以前、セキュリティ対策で議論になった時は、まず「セキュリティ対策の定義」から確認しましょう、とこのブログにも書きました。
論理的な基準や考えに基づかない「主観に基く独自のセキュリティ観」に振り回されると時間を無駄にします。
- セキュリティ対策の話をする場合、まず「セキュリティ対策の定義」から
独自の考えによるセキュリティ観ではリスクも伴います。特にISO 27000やSANS TOP 25など確立したセキュリティ対策を真っ向否定していたなら、開発会社は瑕疵担保責任を超える損害賠償のリスクを負うことになります。セキュリティ専門家は「自分が考えるセキュリティ」を押し付けるのではなく、標準規格に基きクライアントが必要とし、クライアントに適合するセキュリティ対策を推奨するモノではないでしょうか？私はそうしています。
これなら解るかも、とニュートン力学と相対性理論 – エンジニアに見られるセキュリティ対策理解の壁というブログも書きましたが、それ（狭いセキュリティ対策定義）以前の問題でした。
徳丸さんは主観でISO 27000やSANS TOP 25、OWASPのベストプラクティスなどのセキュリティ対策を否定されてきました。主観による「目的」でセキュリティ対策か否か区別しています。その主観に論理的整合性、科学的根拠もありません。これでは混乱するだけです。
- 「セキュリティ対策とは何が何だか解らない」
はこれが原因です。標準的セキュリティのように
- リスクを変化させるモノがセキュリティ対策
と定義すると「効果的である／でない」と客観的・定量的に評価でき、正しく評価すれば「セキュリティ対策」が主観により変化することはありません。
今後はツイッターでリクエストしたとおり、少なくとも国際規格や権威あるベストプラクティスを独自の主観で否定されないよう願います。日本のソフトウェアセキュリティが少しでも向上するために！
徳丸流セキュリティを啓蒙するのは自由ですが、それがとくに基準のない個人の主観であることを今後は明示されるべきです。他者が標準規格などに準拠してるにも関わらず標準準拠の考えたが独自のセキュリティ観であるかの様に解説し、主観によるセキュリティ判断が標準であるかのように解説することは、日本のソフトウェア業界にとって極めて有害です。
徳丸さん、ここは違うという部分がありましたら、ご指摘ください。ご自身の発言なので無いとは思いますが誤解などがありましたら修正します。
ところで、WAFを推奨／販売（「WAFの導入はHASHコンサルティング Sturts1 / Struts2 の脆弱性にも対応」とブログトップに掲載）しながら、アプリでの入力バリデーションはできないと主張してきたこと、アプリでの入力バリデーションはセキュリティ対策ではないと主張するのは倫理的なのでしょうか？問題があるように感じます。直ぐに正された方が良いと思います。
今回学んだことは「科学的／論理的に正しいことさえ言っていれば理解される」ということはなく、「聞いた人が正しい、と思えることを言っていれば、例えそれが科学的／論理的には出鱈目であっても理解される」ことです。根本的な部分で異る相手の考え方を理解した上で、どう議論するのか？非常に未熟であったと反省しなければなりません。
もしかすると自分が思ってもみなかった知見が得られるかも？と思い議論を続けてきました。このようなブログを書くことは不本意で残念です。これまで何人もの方が非科学的／非論理的なセキュリティ対策を主張する場面に合いました。今後も今まで同様に勘違いさせられた方がでてくるかも知れません。その際の参照先としても少なくとも一度はまとめて記述しなければなりませんでした。このブログを読んで不愉快になった方が居たとすれば、それは本意ではありません。ご容赦ください。
標準と基本概念からセキュリティを学びたい、実践したいという方は声をかけてみてください。可能な限り対応させて頂きます。
最後に、私は議論が好きなので討論を挑まれると議論してしまいますが、より良いモノを採用することに抵抗はありません。現在の標準セキュリティより科学的、論理的、体系的なセキュリティがあるのであれば是非紹介してください。良いものは直ぐに採用し、共有すべきだと考えています。
徳丸さんへの質問
徳丸さん、いくつか腑に落ちないことがあり、明確にしたいと考えています。
最初にお会いした時、私の本（Webアプリセキュリティ対策入門）を片手に「ホワイトリストは簡単に定義できない」よって私が書くように「入力確認」は「できない」との趣旨の主張をされていました。（ホワイトリストによる入力バリデーションはできない／セキュリティ対策として効果は高くない、と主張されていた）これが「ホワイト／ブラックリスト論争」の始まりでした。現在まで本を片手に内容を否定されたのは徳丸さんだけです。私は自分の本の内容を面と向かって強く否定されたので良く覚えています。
当時、徳丸さんは譲って「ホワイトリストはブラックリストと変わらない」でした。ホワイトリスト方式の優位は神話とブログまで書かれています。これは現在もでしょうか？「ホワイトリストは定義が難しい・できない、ブラックリストと変ならい・より優越するセキュリティ対策である」でなければ、「ホワイト／ブラックリスト論争」は必要ありませんでした。私が形式チェックや長さチェックなど標準を背景にホワイトリスト／入力確認の優位性、未知の脆弱性に対する対応可能性などを説明する必要もありませんでした。現在のWeb環境であればこの主張はまだ少しは理解できますが（しかし当然NG）、当時のWeb環境ではあまりに危険すぎてブラックリストは論外でした。
私の主張が”徳丸さんが理想とする”WAFを中心としたWebセキュリティ構築を目指すには困る主張だったことが議論の発端だったのでは？
当時から現在主張されているように「アプリでのホワイトリストによる入力バリデーションが当たり前」なら、なぜ「ホワイト／ブラックリスト論争」があったのか論理的に説明できません。入力バリデーションではホワイトリストが基本だからです。当時の私の考えは「入力時に確実にチェックを行う」と本に書いてあります。なぜ「ホワイト／ブラックリスト論争」があったのでしょうか？現在のブログで当たり前とされている「アプリ仕様として入力バリデーション」は私の主張してきた「セキュリティ対策としての入力バリデーション」と同じでは？
ホワイト／ブラックリスト論争があったのは紛れも無い事実です。徳丸さんには、現在と同じく当時も「自分が直接的に脆弱性を解消／軽減すると思える対策以外はセキュリティ対策ではない」という考えがあり、私がWebアプリセキュリティ対策入門に書いた「入力時に確実に確認を行う」は「セキュリティ対策ではなく」、「ブラックリストより劣る」、「効果的な入力バリデーションは不可能」（簡単に言うと私の主張するホワイトリスト方式入力バリデーションはできない、セキュリティ対策的に意味がない）などの考えがあった証しでしょう。私の思い違いということなら、なぜ論争があったのか筋道を立て論理的に説明をお願いします。
- 現在と同じく「ホワイトリスト方式入力バリデーションはできる」としていたなら、なぜ「ホワイト／ブラックリスト論争」があったのでしょうか？
- 現在主張されている「アプリ仕様として当たり前の入力バリデーション」は、私が主張してきた「セキュリティ対策としてのホワイトリスト型入力バリデーション」と何が違うのでしょうか？
- 過去と現在の主張の違いは、過去の主張が間違っていたという証拠ではないでしょうか？
- 主観により基本は同じ入力バリデーションである「WAFはセキュリティ対策」、「アプリの入力バリデーションはセキュリティ対策ではない」と決め、セキュリティ専門家が「WAFを推奨／販売」するのは倫理的なのでしょうか？
- 無駄な議論を作っていた、論理的／体系的セキュリティを主張していたのは私でしょうか？徳丸さんでしょうか？
最近では「入力バリデーションはできる」と論調が変化してきた点は歓迎しています。しかし「入力バリデーション自体ができない」と勘違いしてツイッターやFacebookなどで私に議論してきた方たちには迷惑してきました。中には出版予定の出版社に出鱈目な抗議を行う迷惑行為までした人もいました。徳丸さんの主張が直接影響したのかどうかはわかりませんが、この方たちは「入力バリデーションはできない」と明らかに間違った主張をしていました。中にはキーボードがqwertyとは限らないからできない、EBSDICエンコーディングもある、と理解に苦しむ主張をする方までいた始末です。これらの方々の主張は徳丸さんの考えに大きく影響されていたのではないでしょうか？（ここは推測になるので徳丸さんの回答は必要ありません。誤解してしまった当人の方々、コメント歓迎します）
Leave a Comment