ASP.NET で新たに発見されたセキュリティ脆弱性についてネットで読みました。詳細はこちらをご覧ください。
問題は、ユーザー セッション中にこれらのアプリケーションが情報を保存するために生成する Cookie の整合性を保護するために、ASP.NET が AES 暗号化アルゴリズムを実装する方法にあります。
少し曖昧ですが、もっと恐ろしい部分があります。
攻撃の最初の段階では数千のリクエストが必要ですが、攻撃が成功し、攻撃者が秘密鍵を入手すれば、攻撃は完全にステルスになります。必要な暗号化の知識はごく基本的なものです。
全体として、私はセキュリティ/暗号化の分野に十分精通していないため、これが本当に深刻な問題であるかどうかはわかりません。
では、すべてのASP.NET開発者はこのテクニックを恐れるべきでしょうか？数秒であらゆるASP.NETウェブサイトを所有できますまたは何？
この問題は平均的な ASP.NET 開発者にどのような影響を与えるのでしょうか? 私たちにはまったく影響がないのでしょうか? 現実世界では、この脆弱性はどのような結果をもたらすのでしょうか? そして最後に、この脆弱性を防ぐ回避策はあるのでしょうか?
ご回答ありがとうございます！
編集：私が受け取った回答を要約します
つまり、これは基本的に「パディングオラクル」タイプの攻撃です。@スリこの種の攻撃が何を意味するかについて素晴らしい説明を提供しました。この問題に関する衝撃的なビデオがこちらです！
この脆弱性の深刻さについて: はい、確かに深刻です。これにより、攻撃者はアプリケーションのマシン キーを知ることができます。したがって、彼はいくつかのとても不要なもの。
- 攻撃者はアプリのマシンキーを入手することで、認証 Cookie を復号化できます。
- それよりもさらに悪いことに、彼は認証クッキーを生成する任意のユーザー名で。したがって、サイト上では誰の姿でも表示できます。アプリケーションは、あなたと、あなたの名前で認証 Cookie を生成したハッカーを区別できません。
- また、復号化（および生成）も可能になります。セッションクッキーただし、これは前のものほど危険ではありません。
- それほど深刻ではありません。ページの暗号化された ViewState を復号化できます。(ViewState を使用して機密データを保存する場合は、とにかくこれを行うべきではありません。)
- まったく予想外: マシンキーを知っている攻撃者はダウンロードできますウェブアプリケーションから任意のファイルをダウンロードできます。通常はダウンロードできないファイルも含みます。(Web.config のなど）
私が学んだ良い習慣をいくつか紹介しますしない問題を解決するだけでなく、Web アプリケーションの全体的なセキュリティの向上にも役立ちます。
- 保護された構成で機密データを暗号化できます
- HTTPのみのクッキーを使用する
- DoS攻撃を防ぐ
さて、この問題に焦点を当ててみましょう。
- スコット・ガスリーは自身のブログにそれについてのエントリを掲載した。
- ScottGu の脆弱性に関する FAQ ブログ投稿
- ScottGu による脆弱性に関する最新情報
- マイクロソフトはこれに関するセキュリティ勧告を出している
- 脆弱性を理解する
- 脆弱性に関する追加情報
ソリューション
- customErrorsを有効にして、単一のエラーページを作成し、すべてのエラーリダイレクトされます。はい、404でも（ScottGu は、この攻撃では 404 と 500 を区別することが不可欠だと言っています。）また、ランダムに遅延させるコードを
Application_Errorまたは にError.aspx追加します。（乱数を生成し、Thread.Sleep を使用してその時間だけスリープします。）これにより、攻撃者はサーバー上で何が起こったのかを正確に判断できなくなります。 - 3DESに戻すことを勧める人もいました。理論的には、AESを使わないと、AES実装のセキュリティ上の弱点に遭遇することはありません。しかし、実際には、まったくお勧めできません。
その他の考え
私の質問に答えてくれた皆さんに感謝します。この問題だけでなく、Web セキュリティ全般について多くのことを学びました。@Mikael の回答を承認済みとしてマークしましたが、他の回答も非常に役立ちました。
ベストアンサー1
自分を守るために何をすべきでしょうか?
[2010-09-29更新]
スコット・グダウンロード用のリンクがあります
[2010-09-25更新]
修正を待っている間に、昨日ScottGu更新を投稿カスタム URLScan ルールを使用してサイトを保護するための追加手順を追加する方法について説明します。
基本的に、リリース/プロダクションモードでは常に必要となる、攻撃者が内部の .Net エラーにさらされないように、カスタム エラー ページを提供するようにしてください。
さらに、攻撃者が応答のタイミング攻撃に関する追加情報。
web.config内
<configuration>
<location allowOverride="false">
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</location>
</configuration>
これにより、エラーはすべて、200 ステータス コードで返されるカスタム ページにリダイレクトされます。これにより、攻撃者はエラー コードやエラー情報を調べて、さらなる攻撃に必要な情報を得ることができなくなります。
を設定することも安全ですcustomErrors mode="RemoteOnly"。これにより、「実際の」クライアントがリダイレクトされます。ローカルホストから参照する場合のみ、内部 .Net エラーが表示されます。
重要なのは、すべてのエラーが同じエラー ページを返すように構成されていることを確認することです。そのためには、セクションdefaultRedirectに属性を明示的に設定し<customErrors>、ステータスごとのコードが設定されていないことを確認する必要があります。
何が危機に瀕しているのでしょうか?
攻撃者が上記のエクスプロイトを利用できれば、Webアプリケーション内から内部ファイルをダウンロードできます。通常、web.configがターゲットとなり、データベース接続文字列にログイン情報などの機密情報や、誰にも知られたくない自動SQL Expressデータベースへのリンクが含まれる場合があります。ただし、ベストプラクティスに従う場合は、保護された構成web.config 内のすべての機密データを暗号化します。
参考文献へのリンク
この脆弱性に関するマイクロソフトの公式コメントは以下をご覧ください。http://www.microsoft.com/technet/security/advisory/2416728.mspxこの問題の実装の詳細については、具体的には「回避策」の部分を参照してください。
また、スコット・グーのブログ、脚本Web サーバー上の脆弱な ASP.Net アプリを見つけます。
「パディングオラクル攻撃の理解」の説明については、@sriの回答。
記事へのコメント:
RizzoとDuongがASP.NETアプリに対して実装した攻撃では、Webサイトの暗号実装に、暗号文が送信されたときにテキストを復号化するだけでなく、暗号文のパディングが有効かどうかについてのメッセージを送信者に伝える。
パディングが無効な場合、送信者が受け取るエラー メッセージには、サイトの復号化プロセスの動作に関する情報が示されます。
攻撃が成功するには、次の条件が満たされている必要があります。
- アプリケーションは、パディングが無効であるというエラー メッセージを表示する必要があります。
- 誰かが暗号化されたCookieまたはビューステートを改ざんした可能性があります
したがって、アプリ内で人間が読めるエラーメッセージを返す場合、"何かが間違っていました。もう一度やり直してください"そうすれば、かなり安全であるはずです。記事のコメントを少し読むと、貴重な情報も得られます。
- 暗号化されたクッキーにセッションIDを保存する
- 実際のデータをセッション状態に保存する（DBに保持される）
- ユーザー情報が間違っている場合にエラーを返す前にランダム待機を追加して、時間を計れないようにします。
こうすることで、ハイジャックされた Cookie は、おそらくもう存在しないか無効になっているセッションを取得するためにのみ使用できるようになります。
Ekoparty カンファレンスで実際に何が発表されるかは興味深いところですが、現時点ではこの脆弱性についてはあまり心配していません。