"<img src =" XSSは何ができますか？

Question

XSSをブロックする場合、ほとんどのWAFはscriptやiframeなどの明らかなタグをブロックしますが、imgはブロックしません。

理論的には、img src='OFFSITE URL'、しかし何が起こる可能性があるのでしょうか？私はあなたがそれでIPを盗むことができることを知っています、しかしそれはそれですか？

grochmal · Accepted Answer

Anders のように： Blender は認証ダイアログについて非常に優れています。そして korockinout1 はon属性について正しいです。さらに、Adersはaタグについての議論を追加し、- Matija は、レンダリングを行うライブラリの利用についての良いリンクを持っています。

まだ、誰もまだSVGについて話していません。

まず最初に、すべての入力と出力が適切にサニタイズされていると仮定して、onerror/onloadを使用したトリックは不可能です。そして私達はCSRFに興味がありません。私たちはXSSの後です。

<img src=に関する最初の懸念は、同じOriginポリシーに従っていないことです。しかし、それはおそらくそれが思っているほど危険ではありません。

ブラウザが<img>タグをレンダリングするために行うこと

< img src="http://domain/image.png" >は、ブラウザーがパーサー（XMLやHTMLパーサーなど）を呼び出さず、画像（gif、jpeg、png）であることを認識しているため、かなり安全です。

ブラウザはHTTPリクエストを実行し、着信したもののMIME（Conetent-Typeヘッダー、image/pngなど）を読み取るだけです。回答にContent-Typeがない場合、いくつかのブラウザは拡張子に基づいて推測しますが、画像MIMEのみを推測します：image/jpeg、image/pngまたはimage/gif（tiff、bmpそしてppmは疑わしいです、いくつかのブラウザはそれらを推測するために制限されたサポートを持っているかもしれません）。一部のブラウザは、マジックナンバーに基づいて画像形式を推測しようとする場合さえありますが、その場合も、難解な形式を推測しようとはしません。

ブラウザーが（推測される可能性のある）MIMEと一致し、正しいレンダリングライブラリをロードできる場合、レンダリングライブラリはオーバーフローする可能性がありますが、それは別の話です。 MIMEが画像レンダリングライブラリと一致しない場合、画像は破棄されます。レンダリングライブラリの呼び出しが失敗した場合、画像も破棄されます。

ブラウザーが実行（スクリプト）コンテキストに近づくことさえありません。ほとんどのブラウザーは、JavaScriptパーサーからのみ実行コンテキストに入り、application/javascript MIMEから、またはXMLまたはHTMLパーサーから（スクリプトが埋め込まれている可能性があるため）のみ、JavaScriptパーサーに到達できます。

XSSを実行するには、実行コンテキストが必要です。 SVGに入ります。

<img src = "domain/blah/blah/tricky.svg">の使用

痛い、痛い、痛い。 SVGはXMLベースのベクターグラフィック形式であるため、ブラウザーでXMLパーサーを呼び出します。さらに、SVGには<script>タグがあります。はい、JavaScriptをSVGに直接埋め込むことができます。

これは最初に聞こえるほど危険ではありません。 <img>タグ内のSVGをサポートするブラウザは、コンテキスト内のスクリプトをサポートしていません。理想的には、<embed>または<object>タグ内でSVGを使用する必要があります。この場合、スクリプトはブラウザーでサポートされています。ただし、ユーザー提供のコンテンツに対しては行わないでください。

<img src=may内でSVGを許可することは危険だと私は主張します：

XMLパーサーを使用して、SVGが<img>または<object>タグ内にあるかどうかを解析します。パーサーは確かに<script>コンテキストの<img>タグを無視するためにいくつかのパラメーターで調整されています。しかし、それはかなり醜いです、それは特定のコンテキストでタグをブラックリストに載せています。また、ブラックリスト化はセキュリティが不十分です。
<script>はSVGで実行コンテキストを実現する唯一の方法ではありません。SVGにはonmouseover（およびファミリ）イベントも存在します。これもまた、ブラックリストを作成するのに注意が必要です。
ブラウザーのXMLパーサーは、スクリプトブロックの周りのXMLコメントで注目に値する過去の問題を抱えていました。 SVGでも同様の問題が発生する可能性があります。
SVGはXML名前空間を完全にサポートしています。痛い。 xlink:hrefはSVGで完全に有効な構成体であり、XMLパーサーコンテキスト内のブラウザーはおそらくそれに従います。

したがって、はい、SVGは実行コンテキストを実現するためにいくつかの可能なベクトルを開きます。さらに、これは比較的新しいテクノロジーであるため、十分に強化されていません。 SVG処理に関するCVEが表示されても驚くことはありません。たとえば ImageMagickはSVGで問題がありました。

Blender · Answer

~~Firefox~~ （Nightly 59.0a1で修正）、 ~~サファリ~~ （Safariテクノロジープレビュー54で修正）、画像をリクエストすると、サーバーがHTTP基本認証で認証するように要求した場合、Edge、およびInternet Explorerは認証ダイアログを表示します。これにより、ユーザーのブラウザが画像を読み込もうとしたときに、攻撃者は認証ダイアログを表示できます。

Firefox。 Nightly 59.0a1で修正されましたが、最新の安定版リリースに警告が表示されます：
Safari。 Safari Technology Preview 54で修正されましたが、モーダルは最新の安定リリースにまだ存在しています。これはモーダルダイアログであり、Webサイトの残りの部分はグレー表示されていることに注意してください。「ログイン情報は安全に送信されます」も技術的には真実ですが、不注意なユーザーに誤った印象を与える可能性があります。
IE11。ネイティブのWindowsダイアログがブラウザ全体をロックします。

realmをa a a ...a の本当に長い文字列にすると、IE11は完全にロックアップします。

適切に選択されたドメイン名とレルムは、ユーザーをだましてユーザー名とパスワードを攻撃者のサーバーに送信させたり、Webサイトに完全にアクセスできなくさせたりする可能性があります。

multithr3at3d · Answer

_<img src=http://evil.com_はそれほど問題ではありませんが、<img src=a onerror=alert('XSS')>を使用して任意のJavaScriptを挿入できます。実際、「on」イベント属性（onerror、onclick、ontouchstartなど）と組み合わせたHTMLタグを使用して、無制限のJavaScriptペイロードを実行できます。

Adam White · Answer

さて、これはどうですか：（おそらくあなたは後ろに立つべきです。）

<img src="file://uhoh.gif”>

ああ、そうでしょう？なんてモンスター！

まあ、SMBを使用している場合は...

それは18年間存在していたバグです！この脆弱性レポートを1997年から参照してください。これは BlackHat、2015年での同じ脆弱性です。

これは、Microsoft Edgeを含むInternet Explorerに影響します。これはChromeまたはMozillaブラウザには影響しません。IEは攻撃者のWebサイトに対して自動認証を試み、ユーザー名とハッシュされたNTLMパスワードをリモートサーバー、そしてはいインターネット（!!）.

したがって、私はIMGタグを絶対に使用すべきではないと結論付けています。

はい、でもXSSですか？いいえ、それは必ずしも私が認識しているXSS攻撃を起動または構成するわけではありません。どちらからでも起動できますが、必須ではありません。クロスネットワークはカウントされますか？

The D · Answer

「img XSS」とは「src=""要素の<img />属性に任意の値を許可するサイト」を意味すると思います。

...この場合、攻撃者がターゲットに任意のGETリクエストを送信させることができるという意味で、主なリスクはクロスサイトリクエストフォージェリ（CSRF）です。 GETリクエストを使用した送金」の脆弱性。

ただし、必ずしもCross Site Request Forgeryである必要はありません-ユーザーが提供する<img />要素を許可するサイトの主なタイプはWebフォーラムであり、Webフォーラムであると思います同じWebサイトに管理コントロールパネルを配置する傾向があるため、GETを介して「有用な」管理アクションまたはモデレーターアクションを呼び出すことができる場合、それは別の可能性ですが、これはまだCSRFの傘下にあります。

VLAZ · Answer

Dの回答は、GETを使用してcrossサイトとsameサイトの両方でコマンドを発行できることを指摘しています。「GETリクエストです-注意してください」と言っても、通常、問題が発生する可能性があるwhyを伝えることができないため、この概念をさらに詳しく説明します。

他の回答でカバーされていない1つの攻撃は、サービス拒否です。以下を検討してください。

あなたはフォーラムにいて、誰かが<img src="/logout" />が埋め込まれたメッセージを投稿します-これにより、画像が読み込まれるときにeveryoneがログアウトされます。現在、そのページが表示されている限り、ユーザーは誰もフォーラムを使用できません。

これは比較的簡単な例ですが、それでも潜在的な問題です。どのようにそれがより問題であるかを示すために、メインページにユーザーのコメントを表示するある種のニュースサイトまたは他のものであり、ログイン後にそこにリダイレクトされると想像してください。現在、誰もすぐにログアウトしないとログインできません。

これまでのところ、これらはクロスサイト攻撃ではありません。ただし、比較的簡単にそれを変えることができます-Facebookまたは他の人気のあるWebサイトが画像の任意のソースを許可し、次の投稿を行っていると想像してください<img src="http://yourdomain.com/logout" />-人々はyourdomain.comにアクセスしなくてもログアウトされます。これは、煩わしい（「うーん、ウェブサイトが私のパスワードを尋ねるagain "）」から問題が発生する可能性がある（「待て、保存していないすべての作業はどこに行ったの？」）までさまざまです。

画像が対象としていることがログアウトさえされていない可能性は十分にあります。ユーザーが同意なしにWebサイトを「離脱」するhttp://yourdomain.com/deleteMyUserの場合はどうでしょうか。または、おそらくもっともらしいhttp://yourdomain.com/findPrimes?count=9001は、最終的にサーバーに過負荷をかけて重い計算を実行しますか？

この種の攻撃で最も苛立たしいのは、imgタグ自体に問題がないことです。your webappが画像に注意を払っていても、他の誰かはそうではないかもしれません。問題の核心は、ログアウトリンク（または攻撃者が悪用する可能性のあるすべてのリソース）がGETを介して呼び出されるだけで、ブラウザーにGETを発行させるための画像は単なるベクトルです。問題は、多くの開発者にとって完全に明らかではないことです。

Matija Nalis · Answer

すでに述べた他のすべての回答に加えて、画像自体が意図的に変更されて、解析によってユーザーマシンが悪用され、リモートでコードが実行される可能性があります。参照 JPEG画像を単に解凍すると悪用がトリガーされますか？ =

Anders · Answer

Blender は認証ダイアログについて非常に優れた点を示しており、 korockinout1 はon属性について正しいです。ただし、1つ追加します。

状況によっては、画像の制御を使用してページのレイアウトを変更したり、ページの一部を偽装したりできます。私は動的に何もできないのであまり強力ではありませんが、時には賢い方法で使用できます。

たとえば、imgタグを検索して検索結果ページに挿入できる場合、偽の検索結果が含まれている画像を含めることができます。そうすれば、ローカルニュースで「UFO」を検索したように見せることで、2016年のエイリアンの着陸に関するストーリーを返すことができます。

脆弱性がアクションを実行するaタグ内にある場合、ページの他の部分を模倣した画像を挿入できます。これにより、ユーザーが[OK]をクリックすると、偽の[OK]ボタンの描写を含む画像が実際にクリックされますが、実際には[削除]リンクの一部です。

画像を含む独自のリンクを作成できれば、さらに良くなります...

私が言ったように、世界で最も強力なハックではありませんが、必要のない場所で画像を許可しない十分な理由があります。