web-dev-qa-db-ja.com

XSS攻撃に対して、.Net 4.5リクエストの検証をバイパスする方法は?

.Netには request validation と呼ばれる機能があり、悪意のある入力を検出して要求をブロックします。

その性質上、リクエストの検証は正確な科学ではありません。 OWASP 明らかに推奨 セキュリティの境界としてではなく、多層防御として要求の検証のみに依存する。

.netセキュリティトレーニングコースを更新しています。リクエストの検証に依存してはいけない理由の例を含めたいと思います。確かに、私は訓練生に「それをしないでください」と言うことができました-しかし、例は非常に強力です。

.Net 4.5でのリクエストの検証が強化されており、それをバイパスする以前の方法が機能しないことがわかりました。 XSSの場合、.Net 4.5リクエストの検証をバイパスする既知の方法はありますか?私が見つけた最新のリンクは this でした。

7
paj28

レビュー中のアプリケーションのアーキテクチャと機能に応じて、リクエストの検証がバイパスされる可能性のある場所がいくつかあります。これが、Microsoftがこれに依存することを推奨しない理由である可能性があります。

  • 別のチャネル(APIなど)を介してアプリケーションに入るデータは、リクエストの検証の影響を受けないため、追加のコントロールなしでそのデータをレンダリングすると、XSSの問題が発生する可能性があります。
  • リクエストの検証は、データがHTMLコンテキストに配置される場所、JavaScriptコンテキストに配置される場所など、実際には役立ちます。たとえば、適切な保護は提供されません。
  • リクエストの検証は、クライアントから送信されたすべてのデータをカバーするわけではありません。たとえば、アプリケーションがユーザーHTTPヘッダー(ユーザーエージェントなど)からのデータを処理する場合、サイトをXSSに対して脆弱にすることができます。
  • データは、ファイルのアップロードなどの領域を介してアプリケーションに入力できますが、この場合もリクエストの検証が常にトリガーされるわけではありません。

更新リクエストの検証をバイパスする可能性があるもう1つの問題は、ブロックされた文字の代わりに特定のUnicode文字を使用することです。場合によっては、MS SQLサーバーがデータをデータベースに保存するときにこれらの文字をASCIIに変換します。これにより、HTMLを使用してもASP.NetアプリケーションがXSSに対して脆弱になる可能性があります。ベクトル。たとえば

<スクリプト> alert(1)</ script>

保存して返すと、xssになる可能性があります。

10
Rory McCune

XSSのページコンテキストが入力属性のタグである場合。

<input type="text" name="address" value="<xsshere>"/>

その後、次のペイロードが機能します。

" onfocus="alert(1)" autofocus="
4
paj28

ASP.net MVCのデフォルトのバインディングプロバイダーとコントローラーへの投稿JSONを使用している場合、投稿されたJSONは、「危険な」コンテンツが存在する場合でも、リクエストの検証をトリガーしません。

これは、標準的な方法でポストし、検証をトリガーする単純なASP.netフォームで比較的簡単に示すことができます。ポストされた同じデータを取得して、フィドラー(たとえば)を介してJSONと同じアクションにポストしても、同じ検証は行われません。

ここに記載されているサンプル:

https://weblogs.asp.net/imranbaloch/security-issue-in-asp-net-mvc3-jsonvalueproviderfactory

また、OWASPサイトでリクエストの検証についてコメントしました:

https://www.owasp.org/index.php/ASP.NET_Request_Validation#Extending_Request_Validation

既知の文書化されたバイパス(JSONリクエストなど)があり、将来のリリースでは対応されなくなり、リクエストの検証機能はASP.NET vNextで提供されなくなります。

2
Paddy