現在、XSS予防についての調査を行っていますが、DOMベースの攻撃については少し混乱しています。私がこのテーマについて読んだ論文のほとんどは、値がサーバー側のコードではなくJavaScriptによってページにレンダリングされた場合に、DOMを変更するURLパラメータを通じてJavaScriptを注入する例を示しています。最新のブラウザでは、DOMベースのXSS攻撃はまだ可能ですか？
しかし、現代のブラウザはすべて、JavaScriptによってレンダリングされるとURLパラメータで指定されたすべての特殊文字をエンコードしているようです。
DOMベースのXSS攻撃は、IE6などの古いブラウザでない限り実行できませんか？
これは絶対に可能です。ユーザーからの出力をフィルタ処理しないと、その出力はスクリプトを含む何でもかまいません。ブラウザには、あなたが管理している正当なスクリプトかどうかを知る方法がありません。
現代のブラウザの問題ではなく、ブラウザが正規のものとしてあなたのドメインから来るすべてのコンテンツを処理するという基本的な原則です。
確かにクロスドメインスクリプティングのように（セキュリティ上の欠陥が常に存在するが）最近のブラウザで（時には、常にではない）がブロックされている他の側面、
DOM攻撃がどのように機能するのか、私は少し誤解しています。私が見たすべての例では、URLにスクリプトタグが組み込まれていますが、例を複製しようとすると特殊文字がエンコードされます。サーバー側のコードをバイパスするDOMベースの攻撃は他にどのように実行されますか？ – James
これらの攻撃を見てください：https://www.owasp.org/index.php/DOM_Based_XSSとそれらを防ぐ方法：https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet –
@Ofer Zelig - 私はそれらのリンクを見てきましたが、DOM攻撃の例はうまくいかず、出力はJavaScriptによって自動的にエンコードされます。 私が読んだところでは、サーバー側の防御はDOMベースの攻撃に対して効果がないと考えられています。だから私はこれがサーバーの介入なしにどのようにできるのか理解しようとしている。 – James
はそれらを忘れるなどのリソースへのサードパーティ製のアクセスがありますold- 10年前からの学校XSSの試案。クエリパラメタからエスケープされていないものを取って、ページをレンダリングするためのJavaScriptを書くプログラマーは、長年前に角膜/骨格のようなフレームワークに切り替えられました。
しかし、反射/保存されたXSSは依然として広く存在する。これには、サーバー側とクライアント側の両方から適切なエスケープが必要です。現代のフレームワークはすべて、HTMLをレンダリングする際に敏感な文字をエスケープするための優れたサポートを提供します。たとえば、モデルデータからビューをレンダリングする場合、angleには、考えられるXSSの脅威に対処する$ sce（厳密なコンテキストエスケープ）サービス（https://docs.angularjs.org/api/ng/service/ $ sce）があります。バックボーンモデルには、XSSの脅威を排除するための "model.escape（attribute）"（http://backbonejs.org/#Model-escape）のようなメソッドもあります。
私は不思議です - この質問はなぜ投票されたのですか？ –