Re: CORS

You work on browsers? I am very glad to know you!

I can protect sensitive data on https://bankA.com/ since I am working
for it, its security is my responsibility. Whether the requested
resources contains sensitive data is known by me since I design
everything on https://bankA.com/, and I never ask the browser designed
by you to know which one is sensitive, which one is not.

If I need any feature from you for me to get my job done, I will make
a request. But I never ask your browser not to serve Florian's a.html.
Please tell me why you deny to serve his a.html?

when http://evil.com/a.html designed by Florian Bösch
<pyalot@gmail.com> wants to load https://bankA.com/ticker/GOOG, Why do
you deny a.html to load GOOG ticker data with fetch or XMLHttpRequest?
As I think, you just have to check by the rule -- is same origin -- if
yes, then serve the web page as requested. And as what I proposed,
a.html has already told your browser to deem https://bankA.com/ as
same origin, so serve him. Why not?

Be aware that I do not serve his a.html GOOG ticker data with the CORS
header. And the ticker data I will serve him is "{}".  If I serve him
with a piece of JS: var objname={}. Then his a.html can always get the
data as needed with a script element.

looking forward to your answer.

with best regards
Jack (Zhan, Hua Ping詹华平)


> Because the browser cannot automatically tell what page data contains
> sensitive information and what doesn't.  Just because the user visits
> evil.com, that does not automatically mean they grant evil.com
> permission to access all of their private data on other websites.  (Or
> worse - visiting good.com, and an ad from evil.com runs in an iframe
> and wants to slurp up all their private information.)
>
> As someone who works on browsers, it *is* my responsibility to make
> sure that, when it's possible to do so, I protect the user's
> information on bankA.com from evil people on evil.com.  There's a lot
> of stuff I *can't* do, either because I don't know it's bad, or
> "fixing" it will hurt too many other things, but there are some
> actions I can take (like applying the same-origin policy, preventing
> cross-origin scripts from accessing arbitrary stuff) that help a lot
> and hurt fairly little.
>
> This is you shooting yourself in the foot, then. Browsers block
> cross-origin data by default, to protect their users; you can unblock
> it with CORS.  If you refuse to use CORS, you can't unblock things.
> It's your problem that you're intentionally avoiding the tool that
> does what you ask.
>
> ~TJ

Received on Tuesday, 10 October 2017 23:59:55 UTC