私の会社では、コードをリリースする前に、ASP.NETコードでFortify360スキャンに合格する必要があります。HTML出力をサニタイズするためにどこでもAntiXSSを使用しています。また、入力を検証します。残念ながら、彼らは最近、Fortifyが使用していた「テンプレート」を変更し、現在、すべてのAntiXSS呼び出しに「不十分な検証」のフラグを立てています。これらの呼び出しは、AntiXSS.HTMLEncode（sEmailAddress）のようなことを行っています。
Fortifyを満足させるものを正確に知っている人はいますか？フラグが立てられているものの多くは、値がデータベースから取得され、ユーザーからはまったく取得されない場合に出力されるため、HTMLEncodeが十分に安全でない場合、何が何であるかわかりません。
私はFortifyのセキュリティ研究グループのメンバーです。この問題が原因で混乱が生じていることをお詫び申し上げます。私たちは、この種の問題を提示するという非常に良い仕事をしていません。問題の一部はカテゴリ名だと思います。検証メカニズムに問題があると言っているのではなく、この状況に適切な検証であるかどうかを判断できないだけです。
言い換えれば、特定のコンテキストに適した検証が何であるかはわかりません。このため、MicrosoftのAntiXSSライブラリにあるものであっても、HTMLエンコーディング関数をそのままXSSに対して検証するものとして認識していません。
正しい解決策は、HtmlEncodeを使用してHTMLページの本文にユーザー名を出力する場合、元のコードで問題ありません。エンコードされたユーザー名がURLで使用されている場合、XSSに対して脆弱である可能性があります。Fortifyでは、独自のコードで同様の問題が見つかった場合、検証がコンテキストと一致する場合は、「問題ではない」とマークします。
これらの問題を取り巻く問題は、ルールをより正確で理解しやすいものにするために微調整を続けていることを認識しています。3か月ごとに新しいルールをリリースし、今後のリリースでいくつかの変更を加える予定です。第4四半期には、問題を不適切な検証（ブラックリストのエンコードやその他の弱い検証スキーム用）とコンテキスト依存の検証（発生している問題の種類）に分割する予定です。さらにサポートが必要な場合はお知らせください。
（HTMLエンコーディングがすべての問題を解決しない理由のOWASP説明へのリンク： http ：//www.owasp.org/index.php/XSS_（Cross_Site_Scripting）_Prevention_Cheat_Sheet＃Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F ）
fd_dev、静的分析のフープに合うようにコードを絞ることに集中するべきではないことを付け加えておきます。資格があり、結果が当てはまらないと確信している場合は、Fortify GUIツールを使用してコメントを記録し、問題を抑制します。
よくわからない場合は、スクリーンショットを少し撮り、Fortifyテクニカルサポートに電子メールで送信してください。彼らは、Fortifyのセキュリティ結果を解釈する方法についてアドバイスする資格があります。
吹き矢はスポットです。コードの目的とその背後にある理由/メカニズムを理解せずに静的分析の結果を追跡した場合に発生する可能性のある最悪のケースについては、http：//www.schneier.com/blog/archives/2008/05/random_number_b.htmlを参照してください。見つける。（一言で言えば、コードを良くする代わりに悪くすることができます）-：
解決策が見つかりました。信じられないかもしれませんが、これにより Fortify360 はコードを受け入れます。
string sSafeVal = Regex.Replace(sValue, @"[\x00-\x1F\x7F]+", "");
Response.Write AntiXSS.HTMLEncode(sSafeVal);
したがって、AntiXSS.HTMLEncode だけでは失敗する場合は、印刷できない文字を置き換えることで機能します。とにかく HTMLEncode がそれを行うという事実を気にしないでください。それらは単に Regex.Replace をトリガーするだけで、どのパターンでも機能すると思います。