IMGタグの脆弱性
任意のドメインの画像を表示しても安全ですか？つまり私のページに画像があるとしましょう：
_<img src="http://badguy.com/image.gif" />
__image.gif_がjs攻撃ベクトルを返すが、画像は返さない場合はどうなりますか？既知のベクトルはありますか？
javascript:alert(1)または同じものを提供しようとしましたが、base64でエンコードされています。しかし、運がありません。何か案は？
以前は、画像がHTTP 401 Unauthenticated応答を送信し、ユーザーのログイン画面をトリガーする「脆弱性」がありました。これをフォーラムのアバターとして設定すると、あなたのアバターが表示されているページにアクセスした人のために、ログインポップアップが表示されます。多くの人が、ユーザー名とパスワードの組み合わせでログインを試みます。これはおそらくフォーラムアカウントのものです。
私の友人はこれを数年前に発見しましたが、現在はもう機能していないようです。少なくとも数か月前は簡単に再現できませんでした。 編集：私は間違っていました。この攻撃はまだ可能です！/ edit
この方法でのXSS攻撃については、安全です。ブラウザーは、何が含まれていても、どのヘッダーを送信しても、常にこれをイメージとして解釈します。リクエストに基づいて画像をカスタマイズできます（フォーラムソフトウェアに小さな画像を提供して、画像が縮小されないように画像を事前にチェックしてから、他のすべてのユーザーに拡大します）。または、メモリが不足するか何かになるまで、ブラウザに大量のgifデータを供給します。しかし、私が知る限り、リモートコード実行を可能にする実際の大きな脆弱性はありません。
あなたが適度に安全であるのはCSRF攻撃です。画像はHTTP 302 Moved Temporarily応答を発行し、新しい場所にリンクできます。たとえば、リンクできますが、https://accounts.google.com/logoutのような特定のURLを思い出せず、Googleからログアウトします（これは数か月前に機能しました）。または、少し悪意を持って：http://example.com/guestbook.php?action=post&message=spam-url.example.com。
私が知る限り、この方法で実行できるのはGETリクエストのみです。または、画像が最初にPOSTリクエストとしてロードされていた場合は、POSTをリダイレクトすることはできるが、POSTデータを変更することはできないと考えられるため、これはかなり安全です。
最後に重要なことですが、攻撃者が（SMFフォーラムなどの）フォーラムアバターなどのURLを制御している場合、訪問者からIPアドレスなどの情報を入手することが可能です。 SMFのaction=whoページを使用してIPアドレスをユーザー名にリンクするツールを少し前に作成しました。ユーザーにそれを表示し始めたとき（画像に "Hello $ username with IP：$ IP"と表示）、すべてが壊れました。 「どうしてそれを知ることができますか？！」彼らはたいてい10代前半から半ばの技術者だったので、IPアドレスが何であるかは知っていましたが私はそれでハッキングできなかったことを知っています。ただし、少なくともオランダでは、個人を特定できる情報と見なされているため、管理者はこの慣習にあまり満足していませんでした。それを表示しないと、誰も知らないでしょう。
注：この投稿が急いで書かれているように見える場合は、そうです。私もほとんど目が覚めていません。ストーリーテリングが多すぎて、具体的な事実や脆弱性を十分に挙げていない場合は、おそらく明日整理します。とにかくこれが役に立てば幸い！
IMGタグはデータを画像として解釈しようとするため、Javascriptは実行されません。
デコードすると膨大な量のメモリを必要とする画像（「PNG爆弾」）を送信することが可能になり、グラフィックルーチン自体が悪意のあるコンテンツに対して脆弱になる可能性があります（デコード時に慎重に作成された画像、埋め込みコードの実行をトリガーします）。そのような脆弱性がありました ほぼ10年前 、そしてありそうもないことですが、別の脆弱性が出現する可能性があります。
[〜＃〜] update [〜＃〜]：別の did 。そして another 、そしてこれは9.3のCVSSスコアを持っています-"システムの完全性が完全に損なわれています。システムの保護が完全に失われ、その結果、システム全体が危険にさらされています "
そうして HTTP_REFERERタグを使用すると、画像サイトの所有者はどのページにアクセスしたかを知ることができます。また、追跡Cookieを使用することにより、一部の情報開示が可能です（たとえば、悪意のあるサイトはサイトA、B、C間で共有される画像をホストしています）画像の所有者は、画像がサイトAで使用されるとCookieを設定し、サイトのユーザーから同じCookieが送信されるため、サイトAの特定のユーザーがサイトBの別のユーザーと同じ人物であることがわかります。 B）。シナリオによっては、これは望ましくない場合があります。
攻撃者は、ホストサイトのデザインの画像部分を埋め込むことにより、ユーザーをだまして、サイトが実際には存在しないコンテンツをホストしていると信じ込ませます。これには、HTML/CSSが突然の画像サイズ変更に対して脆弱であることが必要です。たとえば、証券取引所のサイトでは、200x80のバナーの代わりに、最上部の行が元のバナーと同じである200x600のバナーが表示され、下の部分は証券取引所のサイトをシミュレートするように作成されており、株式を「押しのけ」ています。ティッカー。同じ株価ティッカーを再現しますが、値は異なります。不注意なユーザーは、だまされて完全に偽の株価をだましてしまう可能性があります。十分な数のユーザーが納得した場合、これは一種の「ポンプとダンプ」スキームを可能にするかもしれません。
報告によるとよく発生するこのバリエーションは、適切な許可なしに画像をリンクした場合です。 yourビューアに画像を運んで提供するコストを負担するWebサイトの所有者は、 完全に異なるもの で画像を切り替える可能性があります。これは、事前に意図的に行われる場合があります。つまり、「ジューシーな」画像が適切なフォーラムにシードされ（たとえば、一部のサッカーチームとのマッシュですか？）、次に反対の内容の何か（そのチームのArchライバルと同じ）に切り替えられます。 。追加の楽しみのために、トローリングウェブマスターは、画像をダウンロードした元のIPを記録し、元の画像を送信し続けます。したがって、チームAのファンはラズベリーを自分のチームに対して宣伝し、なぜ誰もが笑っている理由を理解しません-毎回彼らが見える画像では、チームBをからかっているのが見えます。これは警告として機能します：あなたが見ている画像があなたのユーザーが見ているものと同じであると仮定しないでください 。
リモートサーバーが変更されても、JavaScript自体は実行されません [〜＃〜] mime [〜＃〜]Content-Typeからtext/javascriptへ。 IMGタグ内の特定のMIMEタイプ。ただし、それが実際に使用しても安全であるとは限りません。
私がお勧めする1つのスレッドは 外部画像をブログやWebコンテンツに添付することを許可しても安全ですか？ です。要するに、外部イメージをリンクしているサーバーは、エンドユーザーのブラウザーによって送信されたHTTPリクエストからのすべてのデータ（つまり、リクエストIPアドレス、ユーザーエージェント文字列、プロトコルバージョン、および非HTTPS発信）を引き続き読み取ることができます。 refererURL文字列と、もちろん非セキュアなHTTP Cookieなど、他のリクエストヘッダーもリクエストします。
リモートサーバーは画像を動的に生成し、他の懸念事項（不適切なコンテンツ、IPアドレスなどのエンドユーザー要求情報を追加して監視を恐れるなど）を作成する可能性があります。または、説明されているHTTP要求ヘッダーを検査してサーバー上のユーザーアクティビティを追跡することもできます。以前、またはdroppingサードパーティのトラッキングCookieとその応答。保護されていないHTTPリクエストのreferer文字列でのURLの露出は無視されることが多く、サーバーのWebアドレスが実際には望ましくない可能性がある場合があります（CMSの場所、URLセッションデータ、...）。同じことが、単一のドメイン（場所）に限定されず、サードパーティによって読み書きされる可能性のある非セキュアなCookieにも当てはまります。
さらに、悪意のあるコードは、適切にパッチが適用されていないクライアントシステム上の巧妙に細工された画像を介して繁殖する可能性があります。有名なそのようなエクスプロイトの1つは、パッチが適用されていない以前のバージョンのWindowsでの リモートコード実行を可能にする可能性のあるGDI +バグ でした。 他の同様のエクスプロイト もあり、その一部はまだすべてのシステムで適切に対処されていません。
一部の最新のエクスプロイトのうち、一部のブラウザでは、特別に細工されたSVG画像からJava（JavaScriptではない）コードをトリガーできます [1][2] ：
Exploit-DB-SVGイメージからのJavaコードのトリガー ：
SVGは、静的またはアニメーション画像用のXMLベースのファイル形式です。一部のSVG仕様（SVG 1.1やSVG Tiny 1.2など）では、SVGファイルを開いたときにJavaコードをトリガーできます。
そして
Metasploit-Squiggle 1.7 SVG Browser Javaコード実行 ：
このモジュールは、SVGサポートを悪用して、jarファイルを参照する巧妙に細工されたSVGファイルを介して、Batikフレームワーク1.7に含まれるSquiggle BrowserでJavaコードを実行します。任意のコードを実行するには、ブラウザは次の条件を満たす必要があります。（1）少なくともSVGバージョン1.1以降をサポートしている、（2）Javaコードをサポートしている、および（3）「セキュリティを強化する」スクリプト」チェックを無効にする必要があります。モジュールはWindowsおよびLinuxプラットフォームに対してテストされています
そして、可能なSVGエクスプロイトについてもう少し詳しく SVGアップロードでのエクスプロイトまたはその他のセキュリティリスク？ スレッドで読むことができます。
つまり、簡単に言えば、安全ではなく安全ではなく、それを悪用しないために画像をリンクするリモートサーバーへの信頼に依存している可能性があります。
はい、あなたは安全です。
もちろん、右クリック>画像の表示のときに表示されるページは悪意のあるものである可能性がありますが、Webサイトのコンテキストではスクリプトは実行されません。
さらに、画像のWebサイトの所有者は、画像が埋め込まれているすべてのページで訪問者を追跡できることを忘れないでください。
IMG要求は、任意のサーバーへのGET要求です安全でない可能性があります
サーバーの応答により、ブラウザの動作に影響を与える可能性があるCookieが削除または上書きされる可能性があります。
詳細
Stackoverflowは、このバグによって一度かまれました。ログアウトREST APIは、単純なGETリクエストでアクセスできました。
シナリオは次のようになったと思います：
- スパマーが特定のページにスパムを投稿しました。
- そのページには、
/users/logoutIMGタグ内 - ユーザーの認証Cookieは、HTTPヘッダーを介して削除されました。
- 管理者またはモデレーターがSPAMを削除しようとしたときはいつでも、ログアウトされていました。
これが、SOで[ログアウト]をクリックしたときに[ログアウト]ページが表示される理由の1つです。
余談：SOはHTTP（ "s"/SSLなし）サイトですが、安全なCookieは脆弱であると思います