ここ数年だけでもSSLに対する攻撃方法やバグが何度も見つかっています。SSLで通信を暗号化していてもパスワード認証時のトラフィックを解読されてしまえば、パスワードが漏洩していまいます。パスワードが判ってしまえば、攻撃者は何度でも被害者のアカウントを利用できます。
脆弱性でなくても、SSLも無効化したMITM（中間者攻撃）も可能です。SSLだから安心、とは考えられません。これを何とかできないか、考えてみます。
参考：
カテゴリー: Computer
-
なぜRubyと違い、PHPの正規表現で^$の利用は致命的な問題ではないのか？
Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。
この仕様の違いはデータのバリデーションに大きく影響します。
参考： PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。
-
Heartbleed攻撃と対策
OpenSSLにメモリを自由に参照できるhearbleedと呼ばれるバグ（CVE-2014-0160）がありました。概要はTechCruchで解説されています。昨日は対応に追われたエンジニアも多いのではないでしょうか？OpenSSLを利用したシステムの場合、影響がある可能性があります。詳しくは
http://heartbleed.com/（英語サイト）
で解説されています。
-
PHPer向け、Ruby/Railsの落とし穴
Railsアプリケーションを作る機会も多くなったと思います。今までPHPのみを使ってきた方の為に、開発者がよく落ちてしまうRails/Rubyの落とし穴を少しだけ紹介します。RailsからWebアプリをはじめる方にも役立つと思います。
-
知らないと勘違いする「合成の誤謬」の罠
今回は情報技術者にも役立つ経済学の用語を紹介します。多くのWebアプリケーション開発者、もしかすると他の技術者も知らない合成の誤謬です。「合成の誤謬」（ごうせいのごびゅう）とはもともとは経済学用語で、以下のように定義されています。
《 fallacy of composition 》個人や個々の企業がミクロの視点で合理的な行動をとった結果、社会全体では意図しない結果が生じること。例えば、企業が経営を健全化するために人件費を削減すると、個人消費が減少し、景気の低迷を長引かせる結果となることなど。
注：誤謬（ごびゅう）とは「誤り」「間違い」を意味する言葉です。解りやすく書くなら「合成の誤り」です。あまり一般的な用語ではないと思いますが、経済学用語なのでそのまま使っています。
-
TOP 10のセキュリティ対策 – NSA アメリカ合衆国編
前のエントリでオーストラリア政府のTOP 35のセキュリティ対策を紹介しました。NSA（国家安全保障局）のセキュリティ策も紹介します。米国の情報機関と言えばCIAが有名ですが、NSAも情報機関として大きな組織です。米国政府の情報セキュリティを担保する機関がNSAです。映画などでもよく出てくる情報機関なのでご存知の方も多いと思います。
-
TOP 35のセキュリティ対策 – オーストラリア編
SANS TOP 25以外のセキュリティ対策ガイドラインとしてオーストラリア政府のセキュリティ対策ガイドラインを紹介します。
-
標準と基本概念から学ぶ正しいセキュリティの基礎知識
今回は一部の技術者が勘違いしているセキュリティ概念の話です。技術者とはWebアプリケーションのソフトウェア技術者を指していますが、他の分野の技術者にも同じ勘違いが多いかも知れません。常識であるべき知識が常識でないのが現状のようです。全ての技術者が知っておくべきセキュリティの基礎知識です。
残念ながらセキュリティ対策の定義どころか、プログラムの構造・動作原理も正しく理解されていないと言える状態です。
https://blog.ohgaki.net/secure-coding-structure-principle
https://blog.ohgaki.net/zero-trust-and-fail-fast
ソフトウェア開発には膨大な知識が必要です。目的（ソフトウェアを作ること）以外の知識を取り入れる機会や余裕が無かった方も多いと思います。セキュリティ基礎知識を知らなかった方、安心してください！基本は簡単です。一度知ってしまえば忘れるような難しい事ではありません。勘違いしていた方、問題ありません。正しい知識を身に付ければ良いだけです。誰にでも勘違いはあります。
思い違いをしやすい部分を、かい摘んで解説します。
追記：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
ここでのセキュリティはITセキュリティを意味しています。
参考：
- 「出力対策だけのセキュリティ設計」が誤りである理由
- 実は標準の方が簡単で明解 – セキュリティ対策の評価方法
- エンジニア必須の概念 – 契約による設計と信頼境界線
- IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき
こちらも合わせてご覧ください。
とくに IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき は開発者であれば、目を通しておく方が良いです。IPAが10年以上も原理的に誤ったソフトウェアセキュリティ対策を啓蒙していました。今もその影響が大きいです。
-
間違いだらけのHTTPセッション管理とその対策
HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。
まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。
参考：
-
PHP本体でタイミング攻撃を防御できるようになります
PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。
タイミングセーフな文字列比較関数はhash_equalsとして実装されました。
(さらに…)
http://php.net/manual/es/function.hash-equals.php -
PHPのOpenSSL関数を利用して暗号化する例
色々やることがあってブログを更新できていませんでした。久々のブログはPHPのOpenSSL関数を使ってAES-256-CBCを使って暗号化する例です。今時のハードウェアとソフトウェアならハードウェアAESが利用できるので普通はAES-256-CBCで構わないでしょう。
(さらに…) -
サニタイズは絶対的な悪か？
いつも堅苦しく「こうするほうが良い」とばかり書いているので、たまには「あまり良くない」と言われているセキュリティ対策も、有用かつ必要である例を紹介します。サニタイズの話です。
サニタイズ（Sanitize）とは消毒、汚れた物を綺麗にする事を意味します。汚れた物、つまり悪い物を除去・変換して綺麗にする処理がサニタイズ処理と言われています。悪い物を定義し排除する典型的なブラックリスト型の処理です。ブラックリスト型の処理を行うと「悪い物」の指定に「漏れ」が発生しやすく、間違いの元なのでセキュリティ処理では基本的に使わないことが推奨されています。
「サニタイズはするな！」これはほとんどの状況でサニタイズしない方が安全になる可能性が高くなるので正しいと言えます。しかし、これは全ての状況で正しいでしょうか？
-
タグ検索するならPostgreSQLで決まり！
PostgreSQL Advent Calender 2013、13日目のエントリです。
表題の通り「タグ検索するならPostgreSQLで決まり！」です。
追記：JSONの場合はPostgreSQLのJSONB型を利用してタグ検索を行うを参照