より高度なCSRF対策 – URL/URI個別にバリデーションする方法でハッシュ（HMAC）を使えばデータベースを使わずに有効期限付きのURLを作れる、と紹介しました。今回は有効期限付きURL（URI）の作り方を紹介します。
カテゴリー: Programming
-
より高度なCSRF対策 – URL/URI個別にバリデーションする方法
ハッシュ関数は色々な場面で利用できます。このエントリではハッシュ関数の使い方、特にリクエストにサインする方法として、データベースを使わずURI個別のCSRFトークンを生成しバリデーションする方法を紹介します。
-
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の保護が無効になるような設定になっていた、としています。
-
完全な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関数の仕様の違いにより、思ってもいない結果になります。
-
PHPへのメールヘッダーインジェクション
メールヘッダーインジェクションによる攻撃は一昔前に流行った攻撃です。最近ではあまり聞きませんが、PHPのmail/mb_send_mail関数はメールヘッダーインジェクションに対して十分に安全でしょうか？
実は十分に安全と言える対策は最近になって追加しました。１つは随分前に、もう１つは最近修正しています。それらの修正を紹介します。
-
正規表現でのメールアドレスチェックは見直すべき – ReDoS
前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。
結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー）
追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。
-
StackExchangeが攻撃されたReDoSの効果
StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。
PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。
参考：正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか？
-
アプリケーション仕様？セキュリティ仕様？
アプリケーション仕様なのでセキュリティ仕様ではない、という議論があるようですがこれは正しくありません。
セキュリティ仕様とは「リスクを変化させるモノ全て」です。リスクの変化を低下させるモノなのか、増加させるモノなのかも関係ありません。変化するモノは全てセキュリティ対策です。これはITセキュリティ対策とは上位互換の関係にあるリスク対策の基本概念です。