数年ぶりにLinuxをインストールしているメインPCにしているPCのマザーボードを交換、同時にCPU、メモリ、ディスクも新しい物にしました。近々このマザーボードは別のマザーボードに交換すると思います。SSDも交換するかも知れません。Linuxユーザーの為に情報を共有したいと思います。
Linuxは大抵の環境で動作しますが、まだまだいろいろある、という話です。
詳細な調査を行ったのではありません。取り敢えず自分が使う環境を整備する為に試した時のメモ程度だと理解してください。コメント歓迎します。
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
以前にJavaScript文字列のエスケープ関数を紹介しました。試しにPhalconのZephirで書いてみました。
Railsで多用されているActiveRecordのインジェクションパターンを簡単に紹介します。出典はrails-sqli.orgなのでより詳しい解説はこちらで確認してください。特に気をつける必要があると思われる物のみをピックアップしました。
Hearbleed脆弱性はSSL接続を処理するサーバーのメモリ内容を盗める脆弱性です。メモリ内には様々な機密情報が含まれています。Webサーバープロセスのメモリ内に保存されている内容は全て盗まれる可能性があります。セッションIDやユーザーのパスワードが盗める場合もあります。Heartbleed脆弱性は任意アドレスのメモリ内容をリモートから自由に読み出す脆弱性なので、サーバーのメモリ内に保存された秘密情報は、SSL秘密鍵に限らず、メモリ内容から盗めます。
影響範囲はシステム構成により異なるので、どのような条件で盗まれるのかまとめました。
ここ数年だけでもSSLに対する攻撃方法やバグが何度も見つかっています。SSLで通信を暗号化していてもパスワード認証時のトラフィックを解読されてしまえば、パスワードが漏洩していまいます。パスワードが判ってしまえば、攻撃者は何度でも被害者のアカウントを利用できます。
脆弱性でなくても、SSLも無効化したMITM（中間者攻撃）も可能です。SSLだから安心、とは考えられません。これを何とかできないか、考えてみます。
参考：
Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。
この仕様の違いはデータのバリデーションに大きく影響します。
参考： PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。
OpenSSLにメモリを自由に参照できるhearbleedと呼ばれるバグ（CVE-2014-0160）がありました。概要はTechCruchで解説されています。昨日は対応に追われたエンジニアも多いのではないでしょうか？OpenSSLを利用したシステムの場合、影響がある可能性があります。詳しくは
http://heartbleed.com/（英語サイト）
で解説されています。
Railsアプリケーションを作る機会も多くなったと思います。今までPHPのみを使ってきた方の為に、開発者がよく落ちてしまうRails/Rubyの落とし穴を少しだけ紹介します。RailsからWebアプリをはじめる方にも役立つと思います。
今回は情報技術者にも役立つ経済学の用語を紹介します。多くのWebアプリケーション開発者、もしかすると他の技術者も知らない合成の誤謬です。「合成の誤謬」（ごうせいのごびゅう）とはもともとは経済学用語で、以下のように定義されています。
《 fallacy of composition 》個人や個々の企業がミクロの視点で合理的な行動をとった結果、社会全体では意図しない結果が生じること。例えば、企業が経営を健全化するために人件費を削減すると、個人消費が減少し、景気の低迷を長引かせる結果となることなど。
注：誤謬（ごびゅう）とは「誤り」「間違い」を意味する言葉です。解りやすく書くなら「合成の誤り」です。あまり一般的な用語ではないと思いますが、経済学用語なのでそのまま使っています。
前のエントリでオーストラリア政府のTOP 35のセキュリティ対策を紹介しました。NSA（国家安全保障局）のセキュリティ策も紹介します。米国の情報機関と言えばCIAが有名ですが、NSAも情報機関として大きな組織です。米国政府の情報セキュリティを担保する機関がNSAです。映画などでもよく出てくる情報機関なのでご存知の方も多いと思います。
SANS TOP 25以外のセキュリティ対策ガイドラインとしてオーストラリア政府のセキュリティ対策ガイドラインを紹介します。
「攻撃者が”嫌う”セキュリティ対策＝効果的なセキュリティ対策」です。これに異論は無いと思います。
攻撃者が最も困るセキュリティ対策とは何でしょうか？それは境界防御です。なぜ境界防御が攻撃者が最も困るセキュリティ対策なのでしょうか？それはCWEやCVEを見ればわかります。CWEやCVEに登録されている脆弱性の多くが、境界防御で守れるからです。
今回は一部の技術者が勘違いしているセキュリティ概念の話です。技術者とはWebアプリケーションのソフトウェア技術者を指していますが、他の分野の技術者にも同じ勘違いが多いかも知れません。常識であるべき知識が常識でないのが現状のようです。全ての技術者が知っておくべきセキュリティの基礎知識です。
残念ながらセキュリティ対策の定義どころか、プログラムの構造・動作原理も正しく理解されていないと言える状態です。
ソフトウェア開発には膨大な知識が必要です。目的（ソフトウェアを作ること）以外の知識を取り入れる機会や余裕が無かった方も多いと思います。セキュリティ基礎知識を知らなかった方、安心してください！基本は簡単です。一度知ってしまえば忘れるような難しい事ではありません。勘違いしていた方、問題ありません。正しい知識を身に付ければ良いだけです。誰にでも勘違いはあります。
思い違いをしやすい部分を、かい摘んで解説します。
追記：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
ここでのセキュリティはITセキュリティを意味しています。
参考：
こちらも合わせてご覧ください。
とくに IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき は開発者であれば、目を通しておく方が良いです。IPAが10年以上も原理的に誤ったソフトウェアセキュリティ対策を啓蒙していました。今もその影響が大きいです。
HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。
まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。
参考：