PHPへのメールヘッダーインジェクション
メールヘッダーインジェクションによる攻撃は一昔前に流行った攻撃です。最近ではあまり聞きませんが、PHPのmail/mb_send_mail関数はメールヘッダーインジェクションに対して十分に安全でしょうか？
実は十分に安全と言える対策は最近になって追加しました。１つは随分前に、もう１つは最近修正しています。それらの修正を紹介します。
正規表現でのメールアドレスチェックは見直すべき – ReDoS
前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。
結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー）
追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。
StackExchangeが攻撃されたReDoSの効果
StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。
PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。
参考：正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか？
「セキュアコーディング方法論再構築の試み」を再構築してみる
セキュアコーディングに関して大きな誤解がある資料があったのでこのブログを書いています。
一つ前のブログは二つ以上の議論を理解しながら読まなければならないので解りづらい、とご意見を頂いたので”「セキュアコーディング方法論再構築の試み」を再構築してみる”として書き直してみました。
セキュアコーディングを理解できていない例
追記：解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。
セキュリティの専門家と呼ばれる人であってもセキュアコーディング／セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。
参考1：セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング／セキュアプログラミングの歴史は理解しておた方が良いかも知れません。
参考2：そもそも、原理的／論理的に入力対策を無視／軽視したセキュリティ対策は誤りです。
参考3：前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利無しのデータであることを知っている必要があります。
平成28年度ビジネスマインド養成講座のお知らせ
追記：平成29年度の講座の情報は
をご覧ください。
本年度も岡山大学のビジネスマインド養成講座の講師を勤めさせていただきます。情報セキュリティがよく解らない、必要性がよく解らない、対策の選択がよく解らない、の原因は基本的・根本的な部分の誤解や知識不足が原因であることがほとんどです。
私の担当講座では情報セキュリティ標準に基づいてこれらの誤解や知識不足を解消します。情報セキュリティに「完全」はありませんし、闇雲に対策するモノでもありません。講義をお聞きいただければ、少なくとも自身が行っている対策にそれなりの自信を持てるようになります。
アプリケーション仕様？セキュリティ仕様？
アプリケーション仕様なのでセキュリティ仕様ではない、という議論があるようですがこれは正しくありません。
セキュリティ仕様とは「リスクを変化させるモノ全て」です。リスクの変化を低下させるモノなのか、増加させるモノなのかも関係ありません。変化するモノは全てセキュリティ対策です。これはITセキュリティ対策とは上位互換の関係にあるリスク対策の基本概念です。
OWASPに対して失礼な誤解 – 入力バリデーションは重要なセキュリティ対策
OWASPに対して大変失礼な誤解をしている意見を見かけたのでブログに書いておきます。
OWASPは「入力バリデーション」とても重要な「セキュリティ対策」として考えていますが、OWASP的にはセキュリティ対策ではない、少なくとも重要なセキュリティ対策ではない、というとんでもない誤解はOWASPに対して大変失礼な誤解と言えます。
正規表現インジェクション
一文字でも意味がある文字があるとインジェクション攻撃が可能な場合が多いです。正規表現も例外ではありません。
ITセキュリティの目的
簡単基礎的な事ですが、ITセキュリティの目的がどのように決るのか？理解しておくことが重要だと思うのでブログにします。
「黒い」セキュリティだのみは捨て去る
「黒い」セキュリティとはブラックリスト型セキュリティのことです。
ブラックリスト型セキュリティとは「ブラックリスト型対策でセキュリティを維持しよう」とする概念です。セキュリティ対策では、ブラックリスト型対策はできる限り使わず、可能な限りホワイトリスト型対策を使う、が基本です。しかし、ブラックリスト型の「黒いセキュリティ」対策が理想的な対策である、と考えている人が少くないようです。
「黒いセキュリティ」に頼ったITセキュリティは基本的に捨て去るべきです。
なぜセキュリティ対策はリスクの増減として考えるのか？
ITセキュリティ標準ではセキュリティ対策（リスク対応）はリスクの増減に着目して対策を行います。（最初のリスクアセスメントが正しく実行されていれば、リスクの増減を見るだけで管理／対策できる）概念的な部分は理解しづらいようなので、なぜセキュリティ対策をリスクの増減として考えるのか解説します。
ここで紹介していることはリスク管理の基本的な概念です。リスク対策はITセキュリティ対策に対して上位互換、つまりより広い範囲のリスク/セキュリティ対策です。
たった2つの質問で判る、ITセキュリティ基礎知識の有無
ITセキュリティは国際標準化（ISO27000）もされ、ISMS認証取得済みの組織も5000程もあり広く認知されている概念のハズですがそうでもありません。簡単にセキュリティ基礎知識を持っているか、いないか、判別でれば、エンジニアの採用や既存スタッフの知識レベルの確認などに役立つと思います。
以下はITセキュリティの基礎知識を持っているか、いないか？簡単に判別できる質問です。一言で答えてください。
- ITセキュリティ対策の目的とは？
- ITセキュリティ対策の定義とは？
セキュアなアプリケーションのアーキテクチャ – sandbox化
セキュアなアプリケーションのアーキテクチャの基本は既に書きました。基本は既に書いた通りですが、多少異るアプローチもあります。今回はそれを解説します。タイトルに含まれているsandbox化がキーワードです。
セキュリティを考慮していないWebアプリを安全に使う方法
世の中には仕様としてセキュリティを考慮していないWebアプリも多くあります。特に開発環境では多いのではないでしょうか？こういったアプリも安全に使う為には少しだけ工夫が必要です。本来、セキュリティを考慮しておいた方が良いWebアプリであっても、セキュリティが考慮されていない場合でもこの方法は利用できます。