Webサイトに対する時間ベースのデータベース総当たり攻撃の実現可能性
最近、データベースで比較された文字列（パスワードやトークンからのハッシュなど）を総当たりするときに、文字列の先頭が異なる場合、クエリが数ナノ秒早く失敗するという事実を利用した攻撃があることを最近知りました末尾が異なり、前の文字が正しいです。攻撃者がクエリ時間への正確な隔離されたアクセスを取得することに成功した場合、正しい文字列を見つけるために必要な試行は、標準の総当たり攻撃と比較して大幅に減少します。
他の人が頻繁に訪問し、バックグラウンドプロセスを実行している場合、リモートWebサーバーでクエリ時間を分離することもできますか？
これが実際に脅威である場合、Webサーバーを保護するためのベストプラクティスソリューションは何ですか？私が考えたこと：
- 文字シーケンスを難読化するために入力文字列をハッシュします。
- 関連するクエリに、ある種の最小応答時間を追加します。 DOS攻撃ベクトルを開く可能性があり、マルチスレッドのサポートが不十分なため、典型的なPHP/MySQLシナリオでは実行できない可能性があるため、おそらく悪い考えです。
攻撃の実行可能性は、必要な信号に到達するために除去する必要があるノイズの量によって異なります。 Webサイトに対して多くのテストを実行できる場合は、この種の攻撃を実行可能にするのに十分なノイズを除去するのに十分な信号レベルを上げることができるはずです。しかし、詳細は、悪用したいシステムの実際の設定に大きく依存します。
この種の攻撃と戦うには、動作が入力に依存しないように意図的に構築された操作を使用します。このようなアルゴリズムは、単純な文字列比較だけでなく、ハッシュや暗号化にとっても、実用的な暗号化の重要な部分です。また、タイミングだけがサイドチャネルではありませんが、電力消費や、放射線のようなより奇妙なサイドチャネルを確認する必要もあります。
また、文字列比較に対するタイミング攻撃を調べるだけでなく、 Webアプリケーションが他のデータをリークする可能性があり、ユーザー名が存在するかどうかによって動作が異なるなど、ブルートフォースが容易になります。また、使用するハッシュ関数がタイミング攻撃自体に耐性がない場合は、比較前に単純にハッシュしても役に立たない場合があることにも注意してください。
ログインの試行回数に深刻なレート制限を行う場合は、最善の方法だと思います。これはブルートフォースをはるかに困難にするだけでなく、周囲のノイズが多すぎてレート制限のために信号を増幅できないため、タイミング攻撃を実行不可能にする可能性があります。
これは確かに非常に興味深いアイデアですが、実際には悪用することはほとんど不可能だと思います。ここではファイバー接続を使用しており、ISPへの直接の応答時間も至る所にあります。
探している差が数ナノ秒である場合、信頼できるパターンを実際に検出することを期待し始めるには、文字通りローカルマシンにアクセスする必要があります。また、攻撃者がローカルネットワーク環境にアクセスできる場合、心配する必要のあるはるかに大きな問題があります。
Nic Barkerがすでに述べたように、ネットワーク上でこの脆弱性を悪用することは非常に困難または不可能です。
認証メカニズムのロックアウトしきい値を定義することがベストプラクティスであることを述べておきます。次に例を示します。クライアント認証が7回失敗すると、このクライアントの以降の認証は少なくとも5分間ブロックされます。ロックアウトが不可能な場合は、CAPTCHA（ヒューマンインターフェイス用）または暗号化チャレンジを認証プロセスに追加できます。