11

I understand the concern about a tainted canvas - the idea that the bits of an image from another site can be sent back to a malicious server. But can you explain the details of how exactly this works?

Suppose the user visits nastysite.com and nastysite.com makes an image request to mydatingsite.com or mybankingsite.com to get an image that contains information that is private to the user, and then renders this image onto a canvas, gets the bits of the canvas, and sends those bits back to the nastysite.com server.

What exactly would that image request URL look like? Say it's your picture from a dating site profile you are logged into with a session cookie (mydatingsite.com), or a check image from a banking site you are logged into with a session cookie (mybankingsite.com). How does nastysite.com know what specific URL to use? And does it work if the connection you have to the dating or banking site is through HTTPS is part of a particular session?

I guess this is really a question more about session cookies. Does nastysite.com have free access to your session cookies for mydatingsite.com and mybankingsite.com? Can it use them in an image request that the mydatingsite.com and mybankingsite.com servers can't tell isn't a normal session request from their own page?

curiousguy
  • 5,028
  • 3
  • 25
  • 27
M Katz
  • 213
  • 1
  • 6

1 Answers1

9

What exactly would that image request URL look like?

It need not be anything complicated or abnormal. There are two main ways this could work (were it not for the restrictions in the browser):

  • In the first, there is a specific URL for the profile image of the current user, say http://mydatingsite.com/currentuser/profileimage.jpg. This might be an odd way to design a site, but I have seen it used. This sort of attack works against anyone logged in, and you do not need a customised URL for your target.
  • The second works for attacks targeted at a specific user. If I know you are the owner of the check with ID 12345 I could find out what it looks like by using a URL like http://mybankingsite.com/checks/12345.png.

How does nastysite.com know what specific URL to use?

As an attacker you have to do some research. You can find the URLs or at least the formats of URLs in the source code of the page you are trying to get data from.

And does it work if the connection you have to the dating or banking site is through HTTPS is part of a particular session?

Not sure what kind of session you are talking about here. But in general it would work as the user is logged in to the site in question in the same browser as they visit nastysite.com in.

Does nastysite.com have free access to your session cookies for mydatingsite.com and mybankingsite.com? Can it use them in an image request that the mydatingsite.com and mybankingsite.com servers can't tell isn't a normal session request from their own page?

You are right that all this comes down to cookies. You can not read cookies cross origins, so nastysite.com has no idea what your sessionid on mydatingsite.com is. But for this to work, there is no need to read cookies! The browser is kind enough to send cookies on all requests, no matter what origin the request comes from.

If browsers did not mark canvases with cross origin data as tainted, this would be a real problem. You would have a situation similar to CSRF, where all servers needs to have protection in place to stop cross origin mishaps. New features such as canvas should not break backwards compatibility and force all existing sites to adapt. That is why the tainted concept was introduced.

Note that short of browser bugs this is all quite theoretical since browsers should stop this kind of attack.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
Anders
  • 64,406
  • 24
  • 178
  • 215
  • Why is the browser is so "helpful" with sending another site's session cookies? It seems like not doing that would prevent a lot of this trickery. What are the reasons the browser can't restrict cookie use to the domain that installed the cookie? – M Katz Feb 10 '18 at 01:42
  • 1
    @MKatz You could make an argument that it would have been a better design decision. But that is not how it was written back in the early 90s when the internet was young and nobody had even dreamed of a canvas. And you cant really change it now. There is the `sameOrigin` directive now though, but it should not be relied upon. At least not yet. – Anders Feb 10 '18 at 08:24
  • "_The browser is kind enough to send cookies on all requests, no matter what origin the request comes from_" The "origin" of a request isn't even clearly defined except in the very simple cases. – curiousguy Jul 04 '18 at 20:56
  • 1
    @Anders "_There is the sameOrigin directive now though_" There are two `sameOrigin` modes. "_but it should not be relied upon_" You can't rely on it because the concept of origin of an HTTP request isn't clear: HTTP/HTML/JS was not built with the idea of a well defined "origin" or "responsibility". HTTP and HTML can cause redirection. It is almost never clear when a script or the user caused an event. Not even Google proved to be able to even manage to block popup windows in Chrome without frequently blocking the user who tries to open a link in another window! The cause of an action is lost. – curiousguy Jul 04 '18 at 21:01
  • 1
    @MKatz it's not completely related to having been designed in the early 90s as Anders pointed (which may be true, I don't know) because things can (and did) change in many ways on the web. If you initiate a request from `awesomeblog.com` to `facebook.com`, the browser sends your `facebook.com` cookies so that `facebook.com` knows it's you and you can use that Like button in `awesomeblog.com` without having to log in or anything. Not doing so would break so much functionality on the internet that it would become hard to use. At least that's my limited understanding of the subject. – Alejandro García Iglesias Jan 16 '19 at 16:53