AntiXSS Encoder 4.1 Beta をランタイム エンコーダー (system.web/httpRuntime で設定) として使用するだけで阻止される XSS 脆弱性の例を探しています。次のような AntiXss 関数への明示的な呼び出しを必要としないものを好むでしょう
@AntiXss.JavaScriptEncode(ViewBag.UserName)
ASP.NET ブラックリストを通過するものの、AntiXSS ホワイトリストを通過しない何かを考えています。代替文字セットまたはエンコーディングと関係があるのでしょうか?
UTF-7 の脆弱性をテストしましたが、最新のブラウザーに影響を与えると思われる脆弱性は見当たりません。
ありません。まあ、それは完全に真実ではありません.それらは最新のブラウザで実行されるものではありません.
SDL がそれを要求する理由は、セーフ リストを使用する方が本質的により安全だからです。そのため、誰かが問題のある文字を突然発見した場合、既にエンコードされている可能性があります (構成したセーフ リストによって異なります)。
うーん...私はフォローしていません-独自のエンコーダーを指定する.net 4s機能を使用してそれを呼び出すことについて話している場合を除き、antixssには明示的な呼び出しが必要ですか? その場合、現時点で私が認識していることは何も知られていません。AntiXss はホワイトリストを使用せずに動作するため、一部の文字を除くすべてがエンコードされるため、問題はありません。
fyi - ローカルで utf-7 を正常に動作させることができます:
<HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/スクリプト+AD4-