ユーザーが自分自身でXSSを実行できないようにするには、どのくらいハードを試すべきですか？
ユーザーがWebアプリにデータを保存できるとしましょう。ここで私が話しているのは、ユーザーが表示できるデータの種類についてのみであり、Webアプリケーションの他のユーザーが表示することを意図したものではありません。 （または、他のユーザーがこのデータを表示する場合は、より安全な方法で処理されます。）
このデータにXSSの脆弱性を許可することはどれほどひどいことでしょうか？
もちろん、純粋主義者の答えは明らかに「脆弱性は許されない」でしょう。しかし正直に言って-なぜですか？
許可されているのは、ユーザーがXSSING THEMSELVESすることです。ここでの害は何ですか？他のユーザーは保護されています。そして、誰かが自分に対して攻撃を仕掛ける理由はわかりません（それが無害なものである場合を除いて、その場合-再び-害はありません）。
私の直感は、上記の推論は眉毛を引き上げるだろうということです... OK、それから私は何を見逃していますか？
これは実際には「Self XSS」という実際の概念であり、 https://facebook.com を開いて開発者ツールを開くと、警告が表示されます 
明らかにFacebookは特定のタイプのターゲットであり、この問題があなたに重要かどうかは、サイトの正確な性質に依存しますが、ソーシャルエンジニアリング技術を使用して、あるユーザーのアイデアを他のユーザーに取得させることはできません。自分自身を攻撃します。
あなたは正しいのですが、攻撃の観点からはそれほど問題ではないかもしれません。ユーザビリティの観点から、ユーザーは '予期しない動作'に遭遇する可能性があります。しばらく前、私は明らかにSQLインジェクションの問題があったソフトウェアを使用する必要がありました（請負業者はそれを修正できなかった/修正できませんでした）。これは、予期しないユーザーが名前「O'Brien」など一見無害なものを入力することを意味し、SQLインジェクションをトリガーし、コンピューターの知識がない人にとっては予期しない動作であり、トラブルシューティングが非常に困難でした。おそらくXSSの可能性は低いですが、ユーザーが（）の代わりに<>を使用する場合は、次の点を考慮してください。データが消えたように見える場合があります。概念実証は以下のとおりです。
<html>
<head><title>HI</title></head>
<body>
<h1>WEBSITE</h1>
Hey my name is <travis>.
</body>
</html>
このWebサイトがレンダリングされると、単語「travis」はレンダリングされないことに注意してください。
悪意のあるコードを挿入する唯一の方法が文字通りWebページに入力することである場合、攻撃ベクトルは「self xss」となります。これは別の回答で言及されており、実際には防ぐことができないソーシャルエンジニアリング攻撃です。
しかし、悪意のあるコードが他の方法でページに読み込まれる可能性がある場合は、より大きな問題があります。たとえば、Webサイトが反映されたXSSまたはCSRFに対して脆弱である場合、攻撃者はそれらを使用してユーザーに悪意のあるコードをロードさせることができます。
反映されたXSSの例：dataパラメーターがサニタイズせずにページに印刷された場合、攻撃者は被害者に次のURLを参照させ、悪意のあるコードを読み込ませることができます。
https://www.example.com/search?data=<script src="..."></script>
CSRFの例：送信されたデータがサニタイズせずにページに印刷され、CSRFに対する保護もない場合、攻撃者は被害者に悪意のあるデータを投稿させることができます。
<form method="post" action="submit">
<input type="text" name="title">
<input type="text" name="note">
<input type="submit" value="submit">
<!-- NO TOKEN TO PREVENT CSRF HERE!!! -->
</form>
ご覧のとおり、問題は「データを見ることができる人」だけでなく、「データを入力できる人」にもあります。しかし、上記の例があなたの状況に当てはまらないと確信している場合でも、なぜXSSを避け、常にデータのサニタイズを試みる必要があるのでしょうか。消毒は、状況によっては本当に役に立たないと思われる場合でも、習慣になるはずです。サニタイズが習慣ではない場合、遅かれ早かれ、最終的にXSSにつながる何かをサニタイズすることを忘れてしまいます。
ペイロードがそれを作成したアカウントに関連付けられている場合でも、XSSは依然として不良です。もちろん、「通常の」XSSほど悪くはありませんが、それでも害はありません。
攻撃の例を次に示します。最初に、被害者に私としてログインさせる必要があります。これに対する保護がない場合、これはソーシャルエンジニアリングまたはログインCSRFを介して実行できます。次に、被害者に自分としてログインしている影響を受けるページにアクセスしてもらいます。次に、スクリプトはサイトにキーロガーを追加します。そのため、被害者がログアウトして自分でログインしようとすると、パスワードが送信されます。
このような攻撃が失敗する理由はたくさんありますが、うまくいくかもしれません。どこにいても、すべてのXSSホールを接続する必要があります。
これまでの回答にリストされていない可能性のある別のユースケースがあると思います偶発的セルフXSS。一部のユーザーは、サイトで発生する問題に遭遇し、コピーして貼り付けるドロップインソリューションを探し始めます。注意深く作成された「ソリューション」は問題を引き起こす可能性があります。
攻撃の範囲は、ユーザーが誤って自傷することですが、他のユーザーに害を及ぼすことはほとんどありません。これは、インターネットで見つけたbashコマンドをコピーして貼り付けることが危険である方法と似ています。悪意のあるサイトはLinuxのヘルプを提供しているかもしれませんが、ユーザーデータを何らかの方法で漏らす可能性のあるコマンドを巧妙に含んでいます。
表面上「自己XSS」攻撃を許可すると、二次的な影響が生じる可能性があります。
例として、バグレポートによると、テキストフィールドが小なり記号の後にすべてのテキストを削除するの問題が最近発生しました。ブラウザは、小なり記号をHTMLタグの開始として解釈していました。
私が見たもう1つの問題は、そのような「self-XSS」フィールドが任意の有効な入力を許可しないことです。たとえば、ユーザーが学んだことを保存したい場合がある「ノート」フィールドを考えてみましょう。
One can make bold text by surrounding it with these tags: <b>Hello, bold world!</b>
アプリケーションが「self-XSS」攻撃を許可している場合、ユーザーはそのようなメモを追加することが困難になります。
他の回答で言及されていないものは、セルフXSSから発生する可能性のある潜在的な二次セキュリティ問題です。
アプリに、古いパスワードの変更やサードパーティによるアカウントへのアクセスの許可など、ユーザーにパスワードの再入力を要求する非常に強力で危険な機能があるとします。攻撃者は、Cookieジャッキング、アイドルセッション（ユーザーが机から離れている）、クロスサイトリクエストフォージェリ（CSRF）などの攻撃を介して、一時的にアカウントにアクセスする可能性があります。これらのいずれの場合でも、攻撃者はユーザーのパスワードを知らないため、これらの強力なアクションを直接実行することはできません。ただし、自己XSSの脆弱性を利用して、非常に説得力のあるソーシャルエンジニアリング攻撃を実行してユーザーの資格情報を取得したり、XSSペイロードを設定して（ユーザーがログインするたびに）ユーザーのアカウントに永続的にアクセスできるようにすることができます。
CSRFの場合、比較的無害なアクションは、CSRFを使用して格納された自己XSSを引き起こし、攻撃者がユーザーのCookieまたはブラウザセッションにアクセスできるようにすることで、強力な攻撃に変換される可能性があります。開発者に脆弱性を示すときに、私は実際にこの攻撃チェーン手法を数回使用しました。
純粋なセキュリティの観点から、ここにいくつかの素晴らしい答えがあります。セルフXSSの角度は、それに関連する一番上の角度が明示的に接続を確立していなくても、完全に正しいです。
本質的に、もし人々がだまされてセルフXSSコードを開発コンソールに落とすことができるなら、なぜ彼らがあなたのUIのいくつかの入力要素に落とされないように期待するのでしょうか？
他のいくつかの回答は、これがどのようにして広範な問題を引き起こす可能性があるかを結び付けています（imo、必然的に、誰かが自己XSSに騙された場合）、アカウントの侵害につながります。
私はそれらがおそらく一番の直接的な理由だと思います。しかし、私はまだ別の角度からこれに対処したいと思います：
開発プラクティス：Self-XSSを許可することの影響
ユーザーがWebアプリにデータを保存できるとしましょう。ここで私が話しているのは、ユーザーが表示できるデータの種類についてのみであり、Webアプリの他のユーザーが表示することを意図したものではありません。
ここでの仮定の問題は、ユーザーが提供したデータのすべての出力でXSSをデフォルトプラクティスとして妨げないことを想定していることです：理想的には、データの取得と出力に使用されるクラスまたは関数のデフォルトの出力メカニズムとして、偏差があります異なる出力フィルタリング方法を選択するには、特定のパラメーターが必要です。
デフォルトの出力方法がXSSを妨げるような方法でアプリケーションをコーディングしていない場合（および属性と要素などの異なる出力ターゲットは、許可されているものと許可されていないもののために異なる方法を必要とするため、「デフォルト」）、および（うまくいけばホワイトリストに載せられ、「精製された」）何かをネイティブのHTML /その他として通過させるために、出力をターゲットにするためにより多くの努力が必要です（少なくはありません）.
ユーザーデータがWebに戻って反映されて、XSSがjust "ユーザーが表示できるデータ"の外では許可されないという事故が発生しないことをどれだけ確信していますか？
間違いが起こるからです。コードを書くとき、人々はステップを忘れます。重要なポイントやトピックが見落とされるトレーニングでは、障害が発生します。一部の人々は「RTFM」をしません：開発者ですら。アプリケーションのアーキテクチャ/フレームワークは、コードを書くときに最も抵抗の少ないパスが常に最も安全な結果であることを確認することに関するすべてである必要があり、最も安全でない結果ではありません。
ユーザー入力に基づいてXSSが発生する可能性を許可するには、積極的なアクションが必要です。これは、発生する可能性のある各場所に関連する開発者による明示的な選択であり、単に保存されたユーザーデータをプルして反映することの基本的なデフォルトの結果ではありません。コードがこのように記述されていない場合、デフォルトでXSSを防ぎ、この出力の浄化を無効にするためになんらかのオーバーライドパラメーターが必要な場合は、プロセスを再評価する必要があることを示しています。
この文脈ではself-XSSを許可の技術的な結果に焦点を当てていますが、影響も考慮する必要がありますそのようなことのビジネスとして：セルフXSSは予期しない動作（ユーザーエクスペリエンスに影響を与える）を引き起こす可能性があります。
さらに、XSSの脆弱性を簡単に回避できることを考えると、心配する必要はありません？考えられる結果について考えてみてください：サポートチケットを開いた、バグを報告した、ユーザーの不満など