web-dev-qa-db-ja.com

潜在的なASP.NET Webアプリのセッション修正の脆弱性の悪用

Session Fixationの動作を示すASP.NETアプリケーションをペンテストしています。アプリケーションはcookieベースのセッションを使用しています。基本的に：

  1. ページにアクセスしても、セッションCookieは作成されません
  2. ログイン後、ASP.NET_SessionId Cookieが作成されます
  3. ログアウト時と繰り返しログイン時のCookie値は同じままです（Cookie値の再生成はありません）

セッション固定攻撃を実行できました手動：

  1. ページに着陸しました
  2. 私は手動でASP.NET_SessionId Cookieを作成しました（攻撃者向け）
  3. 新しいブラウザセッションを開いて、まったく同じCookieを設定しました（被害者向け）
  4. この新しいブラウザセッションで被害者としてログインしました
  5. 攻撃者のブラウザセッションで、被害者としてWebサイトを閲覧できるようになりました

現在、このSession Fixationの脆弱性を実際の状況で利用することに問題があります。何らかの方法でASP.NET_SessionId Cookieを作成または変更する必要があります。私が知ることができることから、私が使用できるWebサイトにはXSSの脆弱性はありません。

私は2つの最も注目すべき攻撃のバリエーションで遊んでいましたが、運がありませんでした（被害者がWebページにCookieを設定するリンクをクリックした場合）：

  • JavaScript

https://www.example.com/<script>document.cookie='ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/'</script>

  • HTMLインジェクション

https://www.example.com/<meta http-equiv=Set-Cookie content="ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/">

何を試しても、デフォルトのエラーページか、作成/変更されたCookieのないランディングページにアクセスしました。

これら2つの攻撃ベクトルで何か不足していますか？

man-in-the-middleまたはman-inを使用する以外に、被害者のASP.NET_SessionId Cookieを作成または変更できる他の方法はありますか？ -the-browser（マルウェアベース）攻撃？

cookiessession-managementsession-fixation
3
fing

Session FixationのOWASPページ から直接攻撃例をコピーしたようです。

明確にするために-これらは、Session Fixation（XSS、HTMLインジェクションなど）以外の別の脆弱性があるシステムに固有の例であることが意図されています-これらは、実際の状況で動作する可能性が高い攻撃ではありません。

この攻撃を実行したい場合、2つのステップがあります。

  1. 別のユーザーの認証Cookieを設定できる脆弱性を見つけます。最善の方法は、おそらくXSSまたはHTMLインジェクションです。このタイプの脆弱性を見つけるには、実行可能なすべてのHTTPリクエストをカタログ化するサイトのセキュリティ評価を実行する必要があります。次に fuzz すべての入力をHTTPレベルで自動化された方法で実行し、脆弱性が存在する兆候を探します。考えられる脆弱性については、実際にそこに何かあるかどうかを調べて手動でテストします。

  2. 前の段階で脆弱性を見つけた場合は、、次にセッション修正攻撃を試みることができます。

お役に立てれば。

2
Abe Miessler

そうです、セッション固定攻撃の前提条件は、攻撃者が被害者のマシンにセッション識別子（Cookie）を配置できることです。 Cookieは発行元のドメインに関連付けられているため、通常の状況では発生しません。つまり、攻撃者は標的サイトから来たように見えるCookieを挿入する方法が必要です。

実際には、これはXSSなどのターゲットアプリケーションの別の脆弱性を悪用することを意味します。これは、サンプルURLが実行しようとしていることですが、ターゲットページがその攻撃に対して脆弱でない場合、機能しません。セッションの固定は、攻撃を阻止するために他の悪用可能な弱点を必要とするという点で、二次的な脆弱性の一部です。実際には、XSSの脆弱性が存在しないことを証明するよりも、セッション固定攻撃を防ぐために必要な変更を加える方が簡単です。

[〜＃〜] owasp [〜＃〜] は常に良いリファレンスです。

0
bmm6o