アプリケーションが特殊文字を処理しないアプリケーションをテストしていますが、ASP.NETでの要求の検証がそれを取得して例外をスローします。
これらのリンクが示すように、これを以前にバイパスするいくつかの異なる方法がありました:
http://www.procheckup.com/media/39734/bypassing-dot-net-validaterequest.pdf
http://blog.diniscruz.com/2014/06/bypassing-aspnet-request-validation.html
https://www.whitehatsec.com/blog/by-the-website-vuln-numbers-net-xss-request-validation-bypass/
私が見逃した新しいものはありますか? q
パラメータに渡された値は、エンコードせずに<h1></h1>
タグ内に出力されます。
説明:ASP.NETは、HTMLマークアップまたはスクリプトが含まれている可能性があるため、潜在的に危険なデータを要求で検出しました。データは、クロスサイトスクリプティング攻撃など、アプリケーションのセキュリティを危険にさらす試みを表している可能性があります。このタイプの入力がアプリケーションで適切な場合は、コードをWebページに含めて、明示的に許可することができます。詳細については、 http://go.Microsoft.com/fwlink/?LinkID=212874 を参照してください。
例外の詳細:System.Web.HttpRequestValidationException:潜在的に危険なRequest.QueryString値がクライアント(q = "<img")から検出されました。
バージョン:
バージョン情報:Microsoft .NET Frameworkバージョン:4.0.30319; ASP.NETバージョン:4.6.1087.0
標準の文字セットが使用されている限り、一般的なブラウザのHTMLコンテキストでこれを悪用する公的に利用可能な既知の方法はありません。出典:多くの研究と経験。
すぐに反映されるだけではないかもしれませんが、アプリケーションに大きく依存します。非ASCII文字、アクセント、印刷不可能な文字などの「奇妙な」入力をテストして、出力前にそれらのいずれかが削除されるか(データベースなどによって)正規化されているかどうかを確認することをお勧めします。
その場合、途中でフィルターを通過するが、途中で有効なHTMLに変換される非HTML文字列を作成できる可能性があります。ソースを見ると、フィルターがかなり単純であることがわかります。フィルターは基本的にnullバイトを削除し、<
の後にa-z
、A-Z
、!
、 /
または?
:
https://referencesource.Microsoft.com/#system.web/CrossSiteScriptingValidation.cs,3c599cea73c5293b
たとえば、次のような入力を持つ保存されたXSSのバイパスが成功しました。
<img src=x onerror=alert(document.domain) />
<img src=x onerror=alert(document.domain) />
<ımg src=x onerror=alert(document.domain) />