ブログ スタイルのコメントに ASP.NET Web フォームを使用しています。
編集 1: これは、私が最初に考えたよりもはるかに複雑に見えます。src をどのようにフィルタリングしますか?
私はまだ実際の html タグを使用することを好みますが、そのように複雑になりすぎる場合は、カスタム ルートを使用する可能性があります。私はまだ XML を使ったことがないので、それについてもっと学ぶ必要がありますか?
許可するのが IMG だけである場合は、単純な角かっこの構文を使用して許可することをお勧めします。これにより、パーサーが不要になり、パーサーを使用した他の危険なエッジ ケースの負荷も軽減されます。次のように言います。
Look at this! [http://a.b.c/m.jpg]
どちらに変換されますか
Look at this! <img src="http://a.b.c/m.jpg" />
SRC 部分にも悪意のあるものが渡されないように、SRC アドレスをフィルタリングする必要があります。多分のように
Look at this! [javascript:alert('pwned!')]
XML パーサーを使用して入力を検証し、許可しないすべての要素と属性を削除またはエンコードします。この場合、. 以外のすべてのタグを削除またはエンコードします。<img>
tag, and all attributes from that except
and titlesrc
, alt
非 HTML 形式を使用することになった場合 (これにより、文字通りすべての HTML をエスケープできるため、物事が簡単になります)、markdownなどの標準的な構文を使用します。マークダウン画像の構文は次のとおりです。![alt text](/path/to/image.jpg)
Textileなど、他にもあります。画像の構文は次のとおりです。!imageurl!
@chakrit は、括弧で囲まれた URL などのカスタム構文を使用することを提案しました - これが最善の解決策である可能性があります。あなたは絶対に解析などをいじりたくない.
コメント全体を適切にエンコードすることを確認して
ください.
カスタム構文の例... ;-) )
前述のように、ファイル拡張子を jpg/gif/etc に制限します。これは回避できますが、プロトコル (http:// など) も制限します。
XSS 以外に考慮すべきもう 1 つの問題は、CSRF ( http://www.owasp.org/index.php/Cross-Site_Request_Forgery ) です。このセキュリティの問題に慣れていない場合、攻撃者は基本的に、たとえば送金やパスワードの変更などのために、ブラウザに有効な認証済みリクエストをアプリケーションに送信させることができます。これがあなたのサイトでホストされている場合、彼は匿名で脆弱なアプリケーション (あなたのアプリケーションを含む) を攻撃できます。(他のアプリケーションが脆弱であっても、それらが攻撃されるのはあなたのせいではありませんが、エクスプロイト ホストまたは攻撃のソースになりたくないことに注意してください...)。たとえば、自分のサイトに関する限り、攻撃者がサイトのユーザー パスワードを変更するのははるかに簡単です。