私は地元のホスティング会社のチケットシステムを開発しています。要件の1つは、ユーザーが実際のhtmlを含むチケットを送信できることです。これは有効な入力になります。
<html>
<head>
<script>alert('hello!');</script>
</head>
</html>
この入力は、オンライン送信またはシステムに送信される電子メールを介してシステムに入力できます。
さらに、ビジネス要件の1つは、チケットを表示するユーザーがhtmlバージョンをhtmlとして表示できることです。したがって、何らかの方法でブラウザーにレンダリングすることはビジネス要件です。
今、私はこのシステムを保護する方法が絶対にないことを理解しています。私はそれを保護できる場所でそれを保護するために多くのことをしましたが、この特定のセキュリティホールは現在のビジネス要件を考えると修正できません。
ユーザーがスクリプトタグが埋め込まれたhtmlページ、web.configファイル、XMLファイル、odfファイルを記述している可能性があるため、これらのことをホワイトリストに登録することさえできません。の例。
私は、非常に「オープン」な要件を持つソフトウェアを作成することに慣れておらず、これにどのようにアプローチするのが最善かわかりません。私の現在の考えは、リスク防止ではなくリスク管理です。このシナリオで悪意のある入力を効果的に制限する方法は他にありません。しかし、誰かが私が現在の要件である種の予防をどのように行うことができるかについて何か提案があれば、私はすべての耳です。誰かがそれを持ち出すと確信しているので、私が契約している会社の所有者と率直な会話をしたことも言わせてください、そして要件はすぐに変わることはありません:)
このシナリオを扱った人たちから意見を聞き、その経験に基づいてどのようなアドバイスをすることができるかを知りたいと思います。私は理論にはあまり興味がありませんが、実践に興味があります。私の目標の一部は、所有者の前にしっかりとした提案をし、セキュリティと利便性のトレードオフ全体を妥協するために何ができるかを確認することです。
また、このシステムは最終的に顧客に販売されることを忘れないでください。つまり、私が単純に推測できない多くの仮定があります。現在、システムはそれらにかなり固有に構築されていますが、時間が経つにつれて、私たちが行っている仮定の多くは最終的に削除または一般化されます。
私が最初に考えたのは、受信メールのある種のリスク評価です。メールがしきい値を超えた場合、特定の制限が自動的に適用されます。ブラウザでHTMLバージョンを表示できない、ブラウザではなくテキストエディタで開く、などのようなものです。私の懸念は、これはユーザーにとって苦痛かもしれないということです。私が実施した回避策（「電子メールの承認」）は、実際に何も考えずに使用されるため、これは無意味になります。
また、「信頼できるゾーン」についても検討しました。つまり、新しいメールアドレスからのチケットには、そのアドレスからのチケットの数がXになるまで制限があり、Webインターフェイスを介して作成されたチケット/メールには常に制限が適用されます。そういうこと。多くの点で、これは他のソリューションと同じ問題に悩まされています。
別の解決策はそれをそのままにすることです。これは明らかに最も簡単な解決策であり、有効な解決策かもしれませんが、受け入れる前に非常に強力な議論が必要になります。
私はHTMLパーサーを取り出して、特定のことについて自分で電子メールを調べることを上回っていませんが、所有者が完全に受け入れられないことを明らかにした誤検知を取得せずにこのシステムを保護する自動化された方法はないと思います。私が理解していることですが、サポートにメールを送りたいのは誰からの連絡がないのですか？
過去にこの問題に取り組んだ人々からのアドバイスや洞察をいただければ幸いです。私が使用している特定のテクノロジはASP.Net4.5/IISです。