5 ms·

I'm a bit confused, so CORS doesn't apply when trying to load an image? If they set CORS to allow interaction from anywhere, why use an image and not load data

I'm a bit confused, so CORS doesn't apply when trying to load an image? If they set CORS to allow interaction from anywhere, why use an image and not load data with js?

sombremesa 7y ago
CORS is set up to protect data from being given to a third party, e.g. JS requests obtaining and being able to observe data they shouldn't have access to. Since images are being loaded by the browser (second party), there is no such protection, since a third party should not be able to read them anyway (barring some other vulnerability). It's assumed the first party is correctly doing what it's supposed to, an example could be fetching an image from a cdn.
- fokinsean 7y ago
  Hmm I still don't understand why they have to use the image hack. Since they control the server on localhost they can set the CORS headers to allow all domains, then JS from a site could access localhost right?
  - chrisfosterelli 7y ago
    Yes. I don't think there is any good reason to use the image hack. Further, they could have made the CORS lock only the production zoom domain for better security...
    - rajsite 7y ago
      A user on Reddit suggested the image url hack was a way to bypass mixed content blocking from the zoom https site to the local http server: https://www.reddit.com/r/programming/comments/cavblo/zoom_zero_day_4_million_webcams_maybe_an_rce_just/etdw0qn/ https://www.reddit.com/r/programming/comments/cavblo/zoom_ze... > One potential hiccup I encountered was that Firefox blocked my XHR request due to a policy against "mixed active content". This was because my origin site was accessed through an HTTPS connection and the localhost server was only HTTP. That's one potential reason Zoom might have opted to use their <img> garbage; since <img> elements are passive not active content, they could avoid using HTTPS on the localhost webserver. That's not a good excuse, but clearly they weren't interested in finding a good solution -- whatever the problem that prompted the <img> hack was.
      - chrisfosterelli 7y ago
        Very interesting, thank you! This is definitely no excuse for not filtering the origins -- they just don't get it for free through passive but they still need to do it, or since they are a native app, generate and install a cert -- but it could be the motivation for the decision to go this route which is really useful to know.
      - chrisfosterelli 7y ago
        Lots of this got me thinking so I wrote a bit of a piece on it: https://fosterelli.co/developers-dont-understand-cors https://fosterelli.co/developers-dont-understand-cors

I'm a bit confused, so CORS doesn't apply when trying to load an image? If they set CORS to allow interaction from anywhere, why use an image and not load data with js?

sombremesa 7y ago

CORS is set up to protect data from being given to a third party, e.g. JS requests obtaining and being able to observe data they shouldn't have access to. Since images are being loaded by the browser (second party), there is no such protection, since a third party should not be able to read them anyway (barring some other vulnerability). It's assumed the first party is correctly doing what it's supposed to, an example could be fetching an image from a cdn.

fokinsean 7y ago
Hmm I still don't understand why they have to use the image hack. Since they control the server on localhost they can set the CORS headers to allow all domains, then JS from a site could access localhost right?
- chrisfosterelli 7y ago
  Yes. I don't think there is any good reason to use the image hack. Further, they could have made the CORS lock only the production zoom domain for better security...
  - rajsite 7y ago
    A user on Reddit suggested the image url hack was a way to bypass mixed content blocking from the zoom https site to the local http server: https://www.reddit.com/r/programming/comments/cavblo/zoom_zero_day_4_million_webcams_maybe_an_rce_just/etdw0qn/ https://www.reddit.com/r/programming/comments/cavblo/zoom_ze... > One potential hiccup I encountered was that Firefox blocked my XHR request due to a policy against "mixed active content". This was because my origin site was accessed through an HTTPS connection and the localhost server was only HTTP. That's one potential reason Zoom might have opted to use their <img> garbage; since <img> elements are passive not active content, they could avoid using HTTPS on the localhost webserver. That's not a good excuse, but clearly they weren't interested in finding a good solution -- whatever the problem that prompted the <img> hack was.
    - chrisfosterelli 7y ago
      Very interesting, thank you! This is definitely no excuse for not filtering the origins -- they just don't get it for free through passive but they still need to do it, or since they are a native app, generate and install a cert -- but it could be the motivation for the decision to go this route which is really useful to know.
    - chrisfosterelli 7y ago
      Lots of this got me thinking so I wrote a bit of a piece on it: https://fosterelli.co/developers-dont-understand-cors https://fosterelli.co/developers-dont-understand-cors