汚れたキャンバスについての懸念-別のサイトからの画像の一部が悪意のあるサーバーに送り返される可能性があるという考えを理解しました。しかし、これがどのように正確に機能するかの詳細を説明できますか?
ユーザーが_nastysite.com
_にアクセスし、_nastysite.com
_が_mydatingsite.com
_または_mybankingsite.com
_に画像リクエストを送信して、ユーザーに非公開の情報を含む画像を取得し、この画像をレンダリングするとしますキャンバス上に、キャンバスのビットを取得し、それらのビットを_nastysite.com
_サーバーに送り返します。
その画像リクエストURLは正確にはどのように見えますか?これは、セッションCookieを使用してログインしている出会い系サイトプロファイルの写真(_mydatingsite.com
_)、またはセッションCookieを使用してログインしている銀行サイトの小切手画像(_mybankingsite.com
_)だとします。 _nastysite.com
_は、どの特定のURLを使用するかをどのようにして知るのですか?また、出会い系サイトや銀行サイトへの接続がHTTPSを介した接続が特定のセッションの一部である場合は機能しますか?
これは本当にセッションCookieについての質問だと思います。 _nastysite.com
_は、_mydatingsite.com
_および_mybankingsite.com
_のセッションCookieに無料でアクセスできますか? _mydatingsite.com
_および_mybankingsite.com
_サーバーが自分のページからの通常のセッション要求ではないことを認識できない画像要求でそれらを使用できますか?
その画像リクエストURLは正確にはどのように見えますか?
複雑で異常なものである必要はありません。これが機能する主な方法は2つあります(ブラウザーの制限ではありませんでした)。
http://mydatingsite.com/currentuser/profileimage.jpg
です。これはサイトをデザインする奇妙な方法かもしれませんが、私はそれが使用されているのを見てきました。この種の攻撃はログインしている誰に対しても機能し、ターゲット用にカスタマイズされたURLは必要ありません。http://mybankingsite.com/checks/12345.png
のようなURLを使用して、小切手の外観を確認できます。
nastysite.com
は、使用する特定のURLをどのようにして知るのですか?
攻撃者として、いくつかの調査を行う必要があります。データを取得しようとしているページのソースコードで、URLまたは少なくともURLの形式を見つけることができます。
また、出会い系サイトや銀行サイトへの接続がHTTPSを介した接続が特定のセッションの一部である場合は機能しますか?
ここでどのようなセッションについて話しているのかわかりません。ただし、一般的には、ユーザーがnastysite.com
にアクセスしたときと同じブラウザで問題のサイトにログインしている場合に機能します。
nastysite.com
は、mydatingsite.com
およびmybankingsite.com
のセッションCookieに無料でアクセスできますか?mydatingsite.com
およびmybankingsite.com
サーバーが自分のページからの通常のセッション要求ではないことを認識できない画像要求でそれらを使用できますか?
これはすべてCookieに帰着するのは正しいことです。 read Cookieはオリジンを超えることができないため、nastysite.com
はmydatingsite.com
のセッションIDが何であるかを知りません。ただし、これが機能するために、Cookieを読み取る必要はありません。 ブラウザは、どのOriginからのリクエストであっても、すべてのリクエストでCookieを送信できるほど親切です。
ブラウザがクロスOriginデータでキャンバスを汚染されているとマークしなかった場合、これは実際の問題です。あなたはCSRFに似た状況になり、Originの事故を防ぐためにすべてのサーバーを保護する必要があります。 canvasなどの新機能は、下位互換性を壊さず、既存のすべてのサイトを強制的に適応させるべきではありません。そのため、汚染されたコンセプトが導入されました。
ブラウザのバグがなければ、ブラウザはこの種の攻撃を阻止する必要があるため、これはすべてかなり理論的なことです。