もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう

スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前（ファイル名を使う直前）に行うべきだ、という考え方です。 スタ

[katzchang]

ソフトな表現だ>あてにしない

[tmatsuu]

正規化、検証、エスケープをきちんと分離するのが大事だと思う。正規化と検証は逆になるかもしれないが、いわゆるエスケープはできるだけギリギリのところで。

[mumincacao]

いつもの O さんかな？ と検索してみたら案の定それっぽいものが・・・ 多重防壁とか大事なのはわかるけど違う目的のものをごっちゃにするとわかりにくくなるだけだと思うのです（ーω【みかん

[itochan]

入力値検証とだけいえば、最小限、仕様に対してvalidかどうかしか意味しないので、セキュリティは全く関係ない。　＞すると、従来メールアドレスの検証だけでSQLインジェクション対策していた場合、

[anrkny]

もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう

[blueday]

「入力値検証は脆弱性対処とは独立して行うべき」

[atsushi1972]

もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strc

[bouzuya]

ASP.NET がデフォルトでユーザーから入力される「<」に反応してエラー出すのは間違ってる、ということで良いのかな。

[Jxck]

分けるのは同意。そして各データソースへの入力で発生する脆弱性がアプリ仕様と分離できてるから、最近はフレームワークの支援が結構効いてると思う。

[hiroponz]

入力値検証にセキュリティ対策を依存するのは危険。セキュリティ対策は分けて考えるべき。

[longroof]

この記事をアテにして今夜は飲むんだ

[linuxdiary]

プログラマが低レベル関数を意識せずにコーディングできればいいんだけど。フレームワークなどでうまいこと仕組み化できないものか。

[rryu]

セッションアダプション、CSRSなんかは入力値検証による対応になるわけで、アプリケーション要件による入力値検証とセキュリティ要件による入力値検証は分けて考えようという感じではないかと。

[derby]

タイトルは誤解されそう。それぞれ考えよう、の方がいい。

[oldriver]

同意

[miki3k]

ローカルだったけど、DB設計する時に怒られた覚えがある。

[lesamoureuses]

DBにエスケープされたデータが入ってる話思い出す "例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前（ファイル名を使う直前）に行うべきだ、という考え方です"

[ockeghem]

とりあえず軽く書いた