PHPスクリプトの分析ツール
PHPスクリプトを分析するツールをまとめたページの紹介です。
PHPのheader関数とheaders_remove関数の注意点
PHPのheader関数とheader_remove関数の注意点です。あまり使わないと思いますが、Set-Cookieヘッダーや他のヘッダーで注意しないと問題になります。普段はsetcookie関数でクッキーを設定していてたまたまheader関数でクッキーを設定した、という場合にheader関数とsetcookie関数の仕様の違いにより、思ってもいない結果になります。
ソフトウェア開発環境のセキュリティ対策
ソフトウェアの開発環境は通常の環境と違う対策が必要です。その理由は開発環境には
- 他人が書いた未検証のモノ
- 自分が書いた実験用のモノ
- 他人または自分が書いた作りかけのモノ
- 制御された環境での利用を前提としたモノ
- 意図的に利用している新しいモノ（リリース前のソフトウェアなど）
- 意図的に利用している古いモノ（古いシステムサポートためなど）
※モノにはコード／ライブラリ／ツール／アプリ／システム などがあります。
などがある為です。開発環境はその他の環境に比べ「とにかく危険なモノがいっぱい」です。
更に最近ではソーシャルコーディングが当たり前になり、他人が書いた未検証のコードがどんどん実行される状態も当たり前です。それも1つ2つのライブラリではなく、依存性から何百、場合によっては何千というライブラリなどが自動的にダウンロードされ実行されています。
これがどういう状況かというと「PCがやっと使えるくらいのユーザーが、インターネットからプログラムをダウンロードしまくって実行している状況」とあまり変わりません。
WordPress + HTTPS + リバースプロキシ = このページにアクセスする権限がありません。
リバースプロキシ環境で結構ハマったのでブログにします。結論から書くと、WordPressのドキュメントに
Note: FORCE_SSL_ADMIN should be set before wp-settings.php is required.
wp-settings.phpを読み込む前にFORCE_SSL_ADMINは定義しなければならない、と書いてありますがSSL関係の設定は全てこれの前に書かないと動作しません。
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に対して大変失礼な誤解をしている意見を見かけたのでブログに書いておきます。
https://www.slideshare.net/ockeghem/owasp-japan20120327
OWASPは「入力バリデーション」とても重要な「セキュリティ対策」として考えていますが、OWASP的にはセキュリティ対策ではない、少なくとも重要なセキュリティ対策ではない、というとんでもない誤解はOWASPに対して大変失礼な誤解と言えます。
正規表現インジェクション
一文字でも意味がある文字があるとインジェクション攻撃が可能な場合が多いです。正規表現も例外ではありません。
セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない？！
セキュアコーディング／セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。（※ 対策の目的が何か？などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません）
どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング／セキュアプログラミングのガイドラインなどがどうなっているのか？紹介します。
このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング／セキュアプログラミングとは何か？は過去のブログをご覧ください。
セキュアなアプリケーションのアーキテクチャ – sandbox化
セキュアなアプリケーションのアーキテクチャの基本は既に書きました。基本は既に書いた通りですが、多少異るアプローチもあります。今回はそれを解説します。タイトルに含まれているsandbox化がキーワードです。