ハッシュ関数は色々な場面で利用できます。このエントリではハッシュ関数の使い方、特にリクエストにサインする方法として、データベースを使わずURI個別のCSRFトークンを生成しバリデーションする方法を紹介します。
-
PHPのmt_rand()/rand()問題
PHPのmt_rand()とrand()には状態の初期化／再初期化に問題があります。話しを簡単にするためにrand()をmt_rand()のエイリアスにする提案
https://wiki.php.net/rfc/rng_fixes
が適用された状態を前提にMT rand問題として解説します。しかし、基本的には古いPHPでrand()を使う場合も同じ（かそれ以上）の問題があります。
そもそもMT randは暗号理論的に安全な乱数生成器ではありません。安全な乱数の取得に使ってはなりませんが、MT rand以前の乱数に比べ予測が困難、ということで不適切な箇所で利用しているケースが散見されます。
結論から言うと、MT randで生成された乱数値は安全ではなく非常に危険1、です。
-
Uncaught Error: Call to undefined function get_user_attribute()
Uncaught Error: Call to undefined function get_user_attribute()
で困っている方向けの情報です。以下の様なエラーでWordpressのJetPackの管理ページなどが使えなくなります。
[Mon Dec 05 10:05:51.204342 2016] [php7:error] [pid 1928] [client XX.XX.XX.XX:58566] PHP Fatal error: Uncaught Error: Call to undefined function get_user_attribute() in /path/to/wp/wp-content/plugins/jetpack/modules/after-the-deadline.php:34
-
ISO 27000の入力データ妥当性確認
セキュリティ標準では入力データの妥当性確認（入力バリデーション）が要求されています。具体的な方法はBS 7799（英国のJIS規格のような物、2000年に国際標準化）が作られた時（90年代後半）から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。（日本では普及していないような。。）
セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。
かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて（？）ブログにします。
-
ホワイトリストの作り方
ホワイトリストの考え方／作り方は難しくありません。しかし、間違えていることが少なくないようです。
GoogleがCSP（Content Security Policy – ホワイトリスト型のJavaScriptインジェクション対策）の利用状況を調べたところ以下のような結果が得られました。
we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.
なんと、約95%のCSP利用サイトがCSPの保護が無効になるような設定になっていた、としています。
-
投稿に追記 – ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション
RSSで購読されている方が結構いる（ありがとうございます！）のでエントリに追記したことをお知らせします。
https://blog.ohgaki.net/input-validation-disables-most-injection-attacks#i-15
このエントリの最後に「残存リスク」の項目を追加しました。
思っているより多くの残存リスクがあり、これらも考慮しなければならないことが解ると思います。
-
完全なSQLインジェクション対策
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
- プリペアードクエリ／プレイスホルダを使ったSQLインジェクション対策でOK
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
https://blog.ohgaki.net/output-only-security-is-anti-practice
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：
-
ソーシャルメディアフィンガープリントとその対策
ソーシャルメディアフィンガープリントがまた話題になっているようです。ソーシャルメディアフィンガープリントとは何か？およびその対策です。
ソーシャルメディアに限らず、ログインをサポートしているサイトであれば、全て対象です。
-
PHPスクリプトの分析ツール
PHPスクリプトを分析するツールをまとめたページの紹介です。
-
根本的なセキュリティ対策とは何か？
セキュリティ対策において対策が「根本的」な対策であるかどうか？はあまり重要ではないです。セキュリティ対策において重要なのは対策が「効果的」であるかどうか、が重要だからです。
この基本を押さえた上で、ソフトウェアの「根本的な対策」とは何かを考えてみます。
-
PHPのheader関数とheaders_remove関数の注意点
PHPのheader関数とheader_remove関数の注意点です。あまり使わないと思いますが、Set-Cookieヘッダーや他のヘッダーで注意しないと問題になります。普段はsetcookie関数でクッキーを設定していてたまたまheader関数でクッキーを設定した、という場合にheader関数とsetcookie関数の仕様の違いにより、思ってもいない結果になります。
-
WordPressをできるだけ安全に使うプラグイン
このブログで利用しているセキュリティ関係のプラグインを紹介します。こういう情報はあまり公開しない方が良いのですが、本気の攻撃者の場合はプラグインファイルの存在を総当たりで検出すれば判ってしまいます。
-
ブログのHTTPS化によりコメントなどがリセットされました
このブログのURLをhttpからhttpsに変更しました。これにより、幾つかの情報1が参照できなくなるので記載しておきます。
- Facebookのコメント
- FacebookのLikeやブックマークなど共有
ブログをWordPressに移行してから設定されたURLは自動的にhttpsにリダイレクトされます。
このブログでは移行前に「仕方ないので諦める」ことにしたのですが、サイトのhttps化を検討されている方はこれらの情報が直接参照できなくなる点に注意が必要です。
ブログをhttps化する際にFAQ的な箇所でハマってしまいました。詳しくは WordPress + HTTPS + リバースプロキシ = このページにアクセスする権限がありません を参照してください。
- 大量のコメントスパムに対応しきれないので、このブログではFacebook APIを利用したコメントシステムに変更しています。WordPress純正のコメントの場合、HTTPS化しても参照できなくなることはありません。 ↩