StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。
PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。
参考：正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか？
セキュアコーディングに関して大きな誤解がある資料があったのでこのブログを書いています。
一つ前のブログは二つ以上の議論を理解しながら読まなければならないので解りづらい、とご意見を頂いたので”「セキュアコーディング方法論再構築の試み」を再構築してみる”として書き直してみました。
追記：解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。
セキュリティの専門家と呼ばれる人であってもセキュアコーディング／セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。
参考1：セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング／セキュアプログラミングの歴史は理解しておた方が良いかも知れません。
参考2：そもそも、原理的／論理的に入力対策を無視／軽視したセキュリティ対策は誤りです。
参考3：前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利無しのデータであることを知っている必要があります。
Fedora 24にアップグレードしたところ、予想通りVMware Workstation 11が動かなくなりました。以下のようにして動作させることができました。
F26の場合はこちら：Fedora 26でVMware Workstationを利用する方法
追記：平成29年度の講座の情報は
をご覧ください。
本年度も岡山大学のビジネスマインド養成講座の講師を勤めさせていただきます。情報セキュリティがよく解らない、必要性がよく解らない、対策の選択がよく解らない、の原因は基本的・根本的な部分の誤解や知識不足が原因であることがほとんどです。
私の担当講座では情報セキュリティ標準に基づいてこれらの誤解や知識不足を解消します。情報セキュリティに「完全」はありませんし、闇雲に対策するモノでもありません。講義をお聞きいただければ、少なくとも自身が行っている対策にそれなりの自信を持てるようになります。
アプリケーション仕様なのでセキュリティ仕様ではない、という議論があるようですがこれは正しくありません。
セキュリティ仕様とは「リスクを変化させるモノ全て」です。リスクの変化を低下させるモノなのか、増加させるモノなのかも関係ありません。変化するモノは全てセキュリティ対策です。これはITセキュリティ対策とは上位互換の関係にあるリスク対策の基本概念です。
OWASPに対して大変失礼な誤解をしている意見を見かけたのでブログに書いておきます。
https://www.slideshare.net/ockeghem/owasp-japan20120327
OWASPは「入力バリデーション」とても重要な「セキュリティ対策」として考えていますが、OWASP的にはセキュリティ対策ではない、少なくとも重要なセキュリティ対策ではない、というとんでもない誤解はOWASPに対して大変失礼な誤解と言えます。
PHPには他の言語と同様に様々な制限があります。まとまった資料が見つからなかったのでまとめておきます。PHPの制限と言っても実行時間の制限のようにマニュアルに記載されているINI設定などは記載していません。
デフォルト文字エンコーディング設定の仕様変更はPHP 5.6リリースの際に私が行った変更ですが、ブログで紹介していなかったような気がするので紹介します。PHP 5.5以下のmbstring正規表現デフォルト文字エンコーディングは”EUC-JP”でした。
一応、RFCには
と書いているのですが、これだけではmb_eregなどのデフォルト文字エンコーディングが変わっている事に気が付かない方も多い（気が付かない方が多い？）と思います。
一文字でも意味がある文字があるとインジェクション攻撃が可能な場合が多いです。正規表現も例外ではありません。
簡単基礎的な事ですが、ITセキュリティの目的がどのように決るのか？理解しておくことが重要だと思うのでブログにします。
「黒い」セキュリティとはブラックリスト型セキュリティのことです。
ブラックリスト型セキュリティとは「ブラックリスト型対策でセキュリティを維持しよう」とする概念です。セキュリティ対策では、ブラックリスト型対策はできる限り使わず、可能な限りホワイトリスト型対策を使う、が基本です。しかし、ブラックリスト型の「黒いセキュリティ」対策が理想的な対策である、と考えている人が少くないようです。
「黒いセキュリティ」に頼ったITセキュリティは基本的に捨て去るべきです。
ITセキュリティ標準ではセキュリティ対策（リスク対応）はリスクの増減に着目して対策を行います。（最初のリスクアセスメントが正しく実行されていれば、リスクの増減を見るだけで管理／対策できる）概念的な部分は理解しづらいようなので、なぜセキュリティ対策をリスクの増減として考えるのか解説します。
ここで紹介していることはリスク管理の基本的な概念です。リスク対策はITセキュリティ対策に対して上位互換、つまりより広い範囲のリスク/セキュリティ対策です。
ITセキュリティは国際標準化（ISO27000）もされ、ISMS認証取得済みの組織も5000程もあり広く認知されている概念のハズですがそうでもありません。簡単にセキュリティ基礎知識を持っているか、いないか、判別でれば、エンジニアの採用や既存スタッフの知識レベルの確認などに役立つと思います。
以下はITセキュリティの基礎知識を持っているか、いないか？簡単に判別できる質問です。一言で答えてください。
セキュアコーディング／セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。（※ 対策の目的が何か？などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません）
どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング／セキュアプログラミングのガイドラインなどがどうなっているのか？紹介します。
このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング／セキュアプログラミングとは何か？は過去のブログをご覧ください。