問題タブ [antixsslibrary]

• SQL インジェクションの検出に役立つライブラリの使用を検討しています。

  • sprocs とパラメーター化されたステートメントを使用していますが、この投稿のために、ユーザー入力を検出/検証する一部のライブラリのみを使用しています。

一番いいのは？実装が最も簡単ですか？更新/管理が最も簡単ですか? どちらかを優先するのはなぜですか？

余談ですが：

Owaspを使い始めたばかりです。C#で。検証中にデフォルトのルールが増えることを期待していました。isValid 関数を使用する場合、デフォルトのルールは 5 つだけです。

CREDIT_CARD -- クレジット カード検証ルールのルール名キー。DATE -- 日付検証ルールのルール名キー。DOUBLE -- 二重検証ルールのルール名キー。INTEGER -- 整数検証ルールのルール名キー。PRINTABLE -- 印刷可能な検証ルールのルール名キー。

文字列 SQL インジェクション検出のデフォルト ルールが増えることを期待していました。

ありがとう

を使用してデータを単純にエンコードできるのにHttpUtility.HtmlEncode、なぜ を使用する必要があるのAntiXss.HtmlEncodeでしょうか。

ホワイトリスト方式がブラックリスト方式より優れているのはなぜですか?

また、Anti XSS ライブラリでは、どこでホワイトリストを指定すればよいですか?

XSS 攻撃を防ぐ目的で、HTML を受け入れてデータベースに保存し、後で取得してレンダリングするテキスト ボックスがあるページを更新しています。

私の理解では、AntiXSS.GetSafeHtmlFragment()メソッドを使用して HTML をサニタイズできるということです。HTML をデータベースに保存する前にこれを行う限り、問題はありませんか? Web ページに HTML を出力する場合、何かする必要はありますか?

また、ホワイトリストは一種のブラックボックスのようです。要件に基づいてこれを更新する方法はありますか?

ASP.NET MVC アプリケーションでクロス サイト スクリプティングを防止する最適な方法を見つけようとしています。Microsoft の AntiXSS ライブラリを使用して、基本的に次の 2 つのレベルで保護することを計画しました。ライブラリ自体は非常に単純ですが、検証をどこに配置するかを決めるのに苦労しています。厳密に型指定された HTML ヘルパーを使用し、モデル/ビューモデルを直接バインドしています。各アクション メソッドで個別に AntiXSS を適用することは避けたいと考えています。また、モデル/ビューモデルのプロパティの 1 つで HTML を渡す場合の要件である、投稿アクションで validateinput をオフにしたくないことは間違いありません。

ビューをレンダリングする前 (デコード) およびアクション フィルターに入る前 (エンコード) に AntiXSS を適用できるように、ASP.NET MVC に AntiXSS を挿入できる場所はありますか?

前もって感謝します

データベースに保存され、Web ページにレンダリングされる HTML をユーザーが追加できるエディターがあります。Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragmentこれは信頼できない入力であるため、HTML をサニタイズするために使用する予定です。

• データベースに保存する前、または信頼できない入力を Web ページにレンダリングする前に、消毒する必要がありますか?
• DLL だけでなく、AntiXSS ソース コードをプロジェクトに含めることに利点はありますか? （ホワイトリストをカスタマイズできますか？）
• GetSafeHtmlFragment の実際の実装を確認するには、どのクラス ファイルを調べる必要がありますか

信頼できないソースからの JavaScript 文字列が onclick タグ内に埋め込まれていますが、この文字列をエンコードする正しい方法がわかりません。HTML を単純化すると、次のようになります。

エンコードする方法がいくつか含まれているMicrosoft AntiXss ライブラリを使用します。テキストは HTML/XML 属性に埋め込まれているため、AntiXss.XmlAttributeEncodeメソッドを使用した XML 属性のエンコードが適切と思われます。ただし、これは JavaScript の一部でもあります。したがって、 AntiXss.JavascriptEncodeメソッドを使用した JavaScript エンコーディングも適切と思われます。

テキストが正しく表示されるようにしながら、セキュリティリークを公開しないようにするには、どれを選択する必要がありますか?

---

更新: 私が現在使用している回避策はXmlAttributeEncode、このテキストを使用して、これをタグのカスタム属性内に配置することです。その後、JavaScript を使用してこのタグから読み取ります。基本的には次のようになります。

これは完全に機能し、問題を解決しますが、XML 属性内で JavaScript を正しくエンコードする方法についてはまだ非常に興味があります。

プロジェクトで既存のRadEditorの代わりにWMDを使用することを検討しています。データの保存と取得の方法に関するいくつかの投稿を読んでいますが、先に進む前に、概念が正しいことを確認したいと思います。

私の研究が正しければ、これが私がすべきことです。

1. エディターデータを2回保存する必要があります（1回はHTMLとして、もう1回はMarkdownとして）
2. HTMLを保存する前に、ホワイトリストを実行する必要があります。
3. 途中（表示する前）にAntiXSSを介してHTMLを実行する必要があります
4. マークダウンデータは、編集のためにマークダウンを再設定するためにのみ使用する必要があります。

これが正しいかどうかを誰かが確認または拒否できますか？また、主題に関する有用な入力を追加できますか？

参考資料
コードの再フォーマット：Htmlのサニタイズ
StackOverflow：aspネットでwmdを使用して
マークダウンを保存する方法StackOverflow：データベースに保存する前またはantixssライブラリをレンダリングする前にhtmlをサニタイズする
StackOverflow：htmlエンティティをデータベースに保存するか、取得時に変換する

.net 4 では、<%= %> のような新しい <%: %> スクリプト エンクロージャがありますが、html エンコードを行います。人々は、この新しい構文の使用を奨励しています。

私の質問は、<%: %> の方が Microsoft Anti XSS ライブラリを使用する場合と同様に XSS から保護されますか?

Microsoft のセキュリティ担当者は、HTML Encode は十分に保護されないため、絶対に使用しないでください、常に Anti XSS ライブラリ (または別のライブラリ) を使用する必要があると私に言いました。<%: %> でもそれは本当ですか? または、人々が言っ​​ているように、アプリを XSS から保護することを知って、自信を持って <%: %> を使用できますか?

htmlアジリティパックを使用するだけでxssを防ぐことができるように思えます（解析してから内部テキストを取得します）。hapを使用した後にantixssを使用することは繰り返されますか？

ありがとう、ロッド。

私の会社では、コードをリリースする前に、ASP.NETコードでFortify360スキャンに合格する必要があります。HTML出力をサニタイズするためにどこでもAntiXSSを使用しています。また、入力を検証します。残念ながら、彼らは最近、Fortifyが使用していた「テンプレート」を変更し、現在、すべてのAntiXSS呼び出しに「不十分な検証」のフラグを立てています。これらの呼び出しは、AntiXSS.HTMLEncode（sEmailAddress）のようなことを行っています。

Fortifyを満足させるものを正確に知っている人はいますか？フラグが立てられているものの多くは、値がデータベースから取得され、ユーザーからはまったく取得されない場合に出力されるため、HTMLEncodeが十分に安全でない場合、何が何であるかわかりません。