web-dev-qa-db-ja.com

JSファイルのアップロードを許可するWebサイトへのXSS攻撃?

ユーザーが任意のJSファイルをアップロードできるWebサイトexample.comについて考えてみましょう。このファイルはサーバーに保存され、JSコンテンツタイプで訪問者に提供されます。攻撃者はこれを使用してexample.comにXSS攻撃を実行できますか?

最初、私は答えが明白なイエスだと思った。しかし、それについて考えると、これをどのように行うのかは明らかではありませんか?アップロードされたJSファイルのURLを被害者に向けるだけの場合、ブラウザはコードをダウンロードして表示しますが、実行はしません。他の脆弱性がない限り、攻撃者はHTMLファイルをアップロードしたり、既存のHTMLファイルにスクリプトを強制的に含めることはできません。これをevil.comに含めると、example.com Originで実行されなくなるため、役に立ちません。

ファイルのアップロードには多くのセキュリティ問題があることは承知していますが、ここでは、JSのアップロードを許可した場合のXSSの可能性にのみ関心があります。

2
Anders

これは、WebサイトがURLを介したファイルのインクルードを許可するかどうか、またはサイトがJavaScriptを永続化して後で再度実行できるかどうかによって異なります。

リモートファイルの包含について

Webサイトに外部JavaScriptファイルにリンクして実行できる機能があると想像してください。これがリンクを介して実行できる場合、たとえば、 example.com?src=evil.com/mal.js経由の場合、これは反映されたXSSの脆弱性です。

アプリケーションがリモートJavaScriptをインタラクティブにロードする機能では不十分です。これはURLを介して実行する必要があるため、被害者はURLをクリックするだけで済みます。

持続性について

他のユーザーが作成したJavaScriptをユーザーが実行できるようにするWebサイトの場合、保存されたXSSの脆弱性がある可能性がありますが、これはサイトの構造によって異なります。たとえば、example.com/mallory/mal/にアクセスすると、マロリーによってmal.jsを実行するかどうかを確認し、信頼できないコードを実行するリスクについて警告する場合、問題はありません。しかし、ウェブサイトがそれを実行しているだけなら、私はこれを格納されたXSSとして分類します。

ソーシャルエンジニアリングについて

これは、攻撃者が悪意のあるJSファイルをダウンロードしてWebサイトで実行するようにソーシャルエンジニアリングを行う可能性のある自己XSSの場合であると主張する人もいます。これは正当な懸念事項ですが、これを大きな脆弱性と見なすことはありません。警告を表示することで、このリスクをある程度軽減することができますが、ユーザーはクリックして離れてしまう可能性があります。

1
MechMK1