web-dev-qa-db-ja.com

ペンテストの結果：疑わしいCSRF攻撃

最近、ウェブアプリケーションの1つがテストされました。 CSRFの脆弱性を除いて、すべてが順調に進んでおり、これは私が選択する骨のある発見です。

背景：ASP.NET MVCを使用しており、特に、組み込みの CSRF保護 機能を使用しています。それが機能する方法は、厳密に OWASPが推奨する に準拠しています。いわゆる「シンクロナイザトークン」を1つをHTTP Cookieに、もう1つを__RequestVerificationTokenという名前の非表示入力に含めます。

<form action="/Home/Test" method="post">
  <input name="__RequestVerificationToken" type="hidden" 
    value="6fGBtLZmVBZ59oUad1Fr33BuPxANKY9q3Srr5y[...]" />    
  <input type="submit" value="Submit" />
</form>

また、Acunetixスキャンも定期的に行っており、スキャンではCSRFで保護されていないフォームは検出されませんでした。

さて、ペンテスターが主張しているのは、次のコードでCSRF保護に「違反」できたということです。

<html>
  <body>
    <form action="https://our.site/support/discussions/new" method="POST">
      <input type="hidden" name="subject" value="Subject" />
      <input type="hidden" name="content" value="Content" />

      <input type="hidden" name="__RequestVerificationToken" 
        value="_e-upIZFx7i0YyzrVd[...]" />

      <input type="submit" value="Submit Request" />
    </form>
  </body>
</html>

__RequestVerificationTokenフィールドを含めることは、私が最も気になることです。私にとって、自発的にiPhoneをいじるように彼に与えたので、攻撃者が私の銀行口座から数兆ドルを送金したと主張するのと同じであり、私の銀行がSMSで送信したワンタイムパスワード。

この攻撃が機能する可能性がある唯一の方法は、HTTPSを使用しておらず、XSSに対して脆弱であり、非HTTPのみのCookieを使用しており、同一生成元ポリシーを怠っていた場合だと思います。これらの脆弱性はいずれも、侵入者またはAcunetixのいずれからも報告されていないため、いずれも真実ではありません。

だから問題は：私は間違っているのですか？これは合法的なCSRFの脆弱性ですか？

penetration-testcsrf
27
Anton Gogolev

これはCSRFの脆弱性ではないようです。

攻撃者がCSRFトークンを知る必要がある場合、それは攻撃ではありません。そしてCSRfへのあなたのアプローチは正しいようです。

CSRFトークンをリークする問題は実際にCSRF攻撃を引き起こす可能性がありますが、問題は誤ったCSRF保護ではなく、それらの問題（XSS、暗号化、URL内のCSRFトークンなど）です。

それでも、私はテスターに​​説明を求めます。それがどこかにハードコードされているか、特殊文字がアプリケーションになんらかの問題を引き起こしているため、攻撃は常にその特定のトークンで機能します。または、別のユーザーのトークンを使用することも可能です。または、トークンチェックがまったく機能せず、任意のトークンを受け入れる場合もあります。レポートには詳細が含まれているはずなので、テスターに​​確認してもらいます。

46
tim

通常、攻撃者はこのトークンの値を知らないため、__RequestVerificationTokenが概念実証に含まれているのは確かに奇妙です。

ただし、__RequestVerificationTokenがセッションに正しくバインドされていないと、ページがCSRFに対して脆弱になる可能性があります。プルーフオブコンセプトの値_e-upIZFx7i0YyzrVd[...]がすべての人に役立つ場合、CSRFに対して脆弱です。ペンテスターがログインしたユーザーに対してのみ機能する場合、CSRFに対して脆弱ではありません。

デフォルトの.NET CRSF保護を使用しているので、これは正しく実装され、ペンテスターがミスを犯したと思います。

12
Sjoerd

__RequestVerificationTokenがサーバー側で検証されておらず、すべてのリクエストで機能し、ユーザーが異なる場合は、アプリケーションがCSRFに対して脆弱です。

2
Michal Koczwara