web-dev-qa-db-ja.com

element.setAttributeはXSSをどのような状況で許可しますか？

BurpはDOM XSSの潜在的な脆弱性を特定しました：

アプリケーションは、DOMベースのクロスサイトスクリプティングに対して脆弱である可能性があります。データはwindow.location.hrefから読み取られ、DOM要素の「setAttribute（）」関数に渡されます

この例では、脆弱なコードは次のようになります（機密保持のために実際のオリジナルを含めることはできません）。

var thing = windows.location.href;
...
element.setAttribute("fill", thing);

OWASP DOM XSSチートシート は、「実行コンテキスト内のHTML属性サブコンテキストに信頼できないデータを挿入する前のJavaScriptエスケープ」を示しています。それらが実行コンテキストで何を意味するのかはよくわかりません。

（Chromeで）いくつかの簡単なテストを行うと、これは脆弱になります：

document.getElementById("bob").setAttribute("onclick", "alert(1)");

しかし、これはそうではありません：

document.getElementById("bob").setAttribute("fill", "" onclick="alert(1)");

以上のことを考えると、バープが誤検知を報告したように思います。でも、何かを見落としているのではないかと心配しているので、さらなる情報提供をお願いします。

これが最近のブラウザーで悪用可能である場合にのみ興味があります。 「ベストプラクティスではない」または「IE 4で悪用可能）」には興味がありません。

xssdomburp-suite
9
paj28

setAttribute()は、属性の値を設定する以外何もしないので安全です。文字列で特殊文字を使用しても、追加の属性を挿入することはできません（3番目のスニペットで試みたように）。HTMLタグをエスケープすることは言うまでもありません。

Some属性は、some要素に対して危険です。あなたが示したように、_on*_属性はスクリプトイベントハンドラーを指定できるため、脆弱です。同様に、srcおよびsrcdocは_<iframe>_要素などでは危険です。

@Andersによって提案されたurl()を介してJSを挿入する手法は、過去に機能しました CSS属性の場合 。ただし、主要なブラウザでは不可能です。当時は、<rect fill="url('javascript:alert(1)')"/>などのペイロードが機能していた可能性があります。それがBurpが潜在的な脆弱性としてフラグを立てた理由かもしれません。ただし、最近のブラウザーでは攻撃ベクトルではありません。

5
Arminius