入力バリデーションはセキュリティ対策の基本

徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。

http://tumblr.tokumaru.org/post/55587596019

私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。

結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。

ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

参考:プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション(=セキュリティ対策)がない対策はあり得ない。

データのセキュリティ対策が無いセキュリティ対策?!

“入力バリデーションはセキュリティ対策の基本” の続きを読む

セッションアダプション脆弱性がないセッション管理が必要な理由

徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。

まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。

セッションアダプションに脆弱なセッション管理機構で困る代表的なケースは以下の通りでしょう。

  1. ログイン時にsession_regenerate_idを呼んでない
  2. 自動ログインなど通常のセッション用以外でsession_regenerate_idを呼んでいない
  3. session_regenerate_idを呼んでいても、途中で保存している
  4. session_regenerate_idを呼んでいても、途中で実行パスが変えられる

“セッションアダプション脆弱性がないセッション管理が必要な理由” の続きを読む

PHPのセッションアダプション脆弱性は修正して当然の脆弱性

PHPのセッションアダプション脆弱性がどのように影響するのか、広く誤解されているようです。セキュリティ専門家でも正しく理解していないので、一部のPHP開発者が正しく理解しなかったのは仕方ないのかも知れません。

Webセキュリティの第一人者の一人である徳丸氏は「PHPのセッションアダプション脆弱性は脅威ではない」と書いていますが、いろいろ間違いです。私は2005年頃から現在まで様々な機会に問題であると何度も繰り返し説明しており、しばらくすれば間違いに自分で気付くのでは?と思っていたので特に反論していませんでした。しかし、まだ気づかれていないようなので、幾つかある攻撃パターンのうち解りやすい例を1つだけ紹介しておきます。

“PHPのセッションアダプション脆弱性は修正して当然の脆弱性” の続きを読む

セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?

一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。

その間違いとは

  • 意図の取り違い – 誤読
  • 言語の仕様と実装の理解不足
  • HTTPやPHP仕様の理解不足
  • セキュリティ対策をすべき場所の理解不足

です。(※0)

“セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?” の続きを読む

何故かあたり前にならない文字エンコーディングバリデーション

私が4年前(2005年)に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは?とヒヤヒヤしたので良く覚えています。

不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。

参考:エンジニア向けにもう少し解りやすいブログを最近書いています。

エンジニアなら分かる文字エンコーディングバリデーションの必要性

“何故かあたり前にならない文字エンコーディングバリデーション” の続きを読む