17

Reference: Prevent HTTP Basic Authentication from displaying prompt for images

In order to protect my user-generated content from this potential "exploit", I added crossorigin="anonymous" to all [img] BBCodes.

Well, it worked in IE11: when I tested the exploit, the image no longer triggered the authentication dialog (tested with cache disabled and different URLs for good measure).

But in Chrome, the exploit doesn't work... because images aren't being loaded at all. Instead I'm getting the apparently fairly common error:

Image from origin 'XXXXX' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'YYYYY' is therefore not allowed access.

Maybe my understanding is wrong, but I thought the "anonymous" value of the attribute would allow this to work.

Am I missing something, and if so what other options are there to protect against this issue?

Community
  • 1
  • 1
Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • For me, my problem was that I had `crossOrigin` accidentally spelled as all lowercase `crossorigin`. – Ryan Mar 14 '20 at 19:28
  • This might help: https://www.hacksoft.io/blog/handle-images-cors-error-in-chrome#solution – Shahriar Apr 30 '22 at 11:21

2 Answers2

14

Firstly, as per my understanding, you mean to say the images didn't load in IE. Which is perfect! That's how it has to work.

Secondly(& finally), the behaviour of Chrome is perfect as well.

Process/Details:

The server does not give credentials to the origin site (by setting the Access-Control-Allow-Origin to Anonymous), the image will be tainted and its usage is restricted.

Now, if you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" or "download" images). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.

When the header is not from the same origin i.e., if the resource is fetched without a CORS request (i.e. without sending the Origin: HTTP header), and as it becomes invalid, then, it is handled as if the enumerated keyword anonymous was used.

So my guess is that null is either the same as not being present or being invalid in which case it is handled like anonymous.

So, you see that error in Chrome means exactly doing what IE is doing.

Some references that can help-

Though not a direct answer, but, helpful links-

Hope it helps! :) Happy coding!

Community
  • 1
  • 1
bozzmob
  • 12,364
  • 16
  • 50
  • 73
  • 1
    The main issue I've been having more recently is not that the "hack" fails, but rather that Chrome blocks all images altogether on account of them not having the access-control header. Removing the `crossorigin="anonymous"` attribute makes the images work again, but restore the vulnerability to the hack. – Niet the Dark Absol Jan 27 '16 at 18:06
  • 1
    Yes. I am not sure if I am not able to communicate clearly, but, what you are telling is the expected behaviour. – bozzmob Jan 27 '16 at 18:16
  • 2
    bozzmob good explanation! And @NiettheDarkAbsol , Yes, chrome will block all images if u don't send access-control headers as chrome will not be in a position to believe if the user request is genuine or not. That's how access-control mechanism works. – Sharan Kashyap Jan 27 '16 at 18:31
  • Right, okay, so the question becomes then: how can I prevent the "hack" without blocking images entirely? – Niet the Dark Absol Jan 27 '16 at 20:23
  • As per my knowledge, I don't think its possible. If you pass right headers, images will be visible, if made anonymous, then, not visible or will throw a CORS error. Have a look at - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img once :) – bozzmob Jan 28 '16 at 04:40
  • I don't understand why anonymous cross origin requests are not allowed though. If the browser is not sharing any session data, it's no longer being a "user agent". This, unless I'm missing something, eliminates the vulnerabilities that come with a cross origin request. Also we can easily mimic the anonymous request effect for the most part by setting up an intermediate server acting like a proxy to carry the response while complying with cross origin policy. – toraman Feb 28 '22 at 03:57
1

As per I researched,

Firstly What do you mean by Tainted canvas:

Although you can use images without CORS approval in your canvas, doing so taints the canvas. Once a canvas has been tainted, you can no longer pull data back out of the canvas. For example, you can no longer use the canvas toBlob(), toDataURL(), or getImageData() methods; doing so will throw a security error.
ref:https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image

CORS settings attributes:

In HTML5, some HTML elements which provide support for CORS, such as img or video, have a crossorigin attribute (crossOrigin property), which lets you configure the CORS requests for the element's fetched data. By default (that is, when the attribute is not specified), CORS is not used at all.
The "anonymous" keyword means that there will be no exchange of user credentials via cookies, client-side SSL certificates or HTTP authentication

Since, The image you're linking to isn't CORS-enabled, you are getting Access-Control-Allow-Origin error.

To fix the issue, not only do the crossOrigin attribute but proper headers need to be sent. You can set this to crossOrigin to use-credentials which sets the credentials request header - which the server can use to decide whether you have rights to the content. When the CORS headers are sent back from the server for an image, and that image is used on a canvas, the origin-clean flag is true.

Vicky Gonsalves
  • 11,593
  • 2
  • 37
  • 58