| Time |
S |
Nick |
Message |
| 07:06 |
|
|
xqmqwohsys joined #rest |
| 07:47 |
|
|
wsieroci joined #rest |
| 08:08 |
|
|
Haudegen joined #rest |
| 08:32 |
|
|
interop_madness joined #rest |
| 08:43 |
|
|
Haudegen joined #rest |
| 13:48 |
|
|
Haudegen joined #rest |
| 16:42 |
|
|
Haudegen joined #rest |
| 17:13 |
|
|
tbsf joined #rest |
| 17:36 |
|
|
Tomatosoup- joined #rest |
| 17:48 |
|
|
wsieroci joined #rest |
| 18:22 |
|
|
Guest55277 joined #rest |
| 21:01 |
|
|
tbsf joined #rest |
| 21:04 |
|
|
tbsf_ joined #rest |
| 21:36 |
|
|
k_j joined #rest |
| 21:36 |
|
k_j |
hi |
| 21:37 |
|
k_j |
is there any reason why a server that sets "Access-Control-Allow-Origin: <origin>" (without any check on the <origin> in the request) should not just set "Access-Control-Allow-Origin: *" ? |
| 21:48 |
|
whartung |
what do you mean “without any check on the <origin> in the request”? |
| 22:05 |
|
asdf |
k_j, (note that the check is performed by the client, not by the server - it's implemented in browsers) |
| 22:10 |
|
k_j |
I mean, is there any difference from between setting "Access-Control-Allow-Origin: <Origin in the Request>" and "Access-Control-Allow-Origin: *" ? |
| 22:10 |
|
whartung |
to the browser, yes |
| 22:11 |
|
whartung |
(and to be extra pedantic, this has nothing to do with Rest….) |
| 22:13 |
|
k_j |
what is the difference assuming the server always sets whatever it's in the request? |
| 22:13 |
|
whartung |
it limts what resources scripts can use |
| 22:14 |
|
whartung |
* means it can download stuff from anywhere |
| 22:16 |
|
k_j |
yes, but if the malicious client code puts "Origin: malicious.com" and server answers with "Access-Control-Allow-Origin: malicious.com" why not just answer with "Access-Control-Allow-Origin: *" ? |
| 22:17 |
|
whartung |
the ACAO header is implemented by the browser. The brwoser is required to honor its setting, so if you have the ACAO properly set then, ideally, there won’t be any “malicious code” downloading in to your page from a server you did not authorize. |
| 22:18 |
|
k_j |
ok |
| 22:18 |
|
k_j |
I thought there was a way to set the ACAO from third-party client code |
| 22:18 |
|
whartung |
no, that wouldn’t make any sense. (but I don’t know, I doubt it) |
| 22:24 |
|
k_j |
whartung, suppose I open http://malicious.com by mistake. The browser then downloads some malicious js code trying to invoke a PUT to http://mybank/api (where you are eventually logged in). What is the Origin set by the browser in the PUT request in our opinion? |
| 22:25 |
|
whartung |
it’s not designed to stop that. |
| 22:26 |
|
whartung |
actually I’m not sure how that works |
| 22:26 |
|
whartung |
I don’t do much work with browsers. |
| 22:26 |
|
asdf |
it kinda is designed to stop that, no? |
| 22:26 |
|
k_j |
well if the server answers "Access-Control-Allow-Origin: mybank,com" then I am safe, BUT if it answers "Access-Control-Allow-Origin: malicious.com" or "Access-Control-Allow-Origin: *" then I am not safe |
| 22:26 |
|
asdf |
yes, and it's the bank's responsibility to set it correctly or otherwise you're SOL |
| 22:27 |
|
whartung |
no, it’s designed to prevent your page from being hijacked, not necessarily a malicious page from doing bad things — that’s controlled by somethin gelse |
| 22:27 |
|
k_j |
exactly, so back to my question again: *assuming* a server (wrong or not) sets "Access-Control-Allow-Origin: <any origin>" , what is the differnce from just setting ""Access-Control-Allow-Origin: *" |
| 22:27 |
|
asdf |
what else prevents this from happening? |
| 22:28 |
|
whartung |
I don’t know. It’s a different mechanism I think |
| 22:28 |
|
whartung |
but at the same time, obviously the browser will honor references to any domain (any hyperlink for example) |
| 22:28 |
|
whartung |
but I don’t know if it only applies to XHR or not |
| 22:28 |
|
asdf |
k_j, if the server always guesses your origin and sets that (and i dont think it's always possible to guess), then indeed there's no difference between that perfect guessing and setting * |
| 22:29 |
|
k_j |
ok |
| 22:29 |
|
whartung |
I would think that the People That Know Better have somehow managed to deal with this in some way. |
| 22:29 |
|
whartung |
but, I don’t know |
| 22:30 |
|
k_j |
I am analyzing a server (the source code) which does exactly that. I am not intersted in determining if the server has a vulnerability or not, I am trying to understand the difference between the two approaches |
| 22:30 |
|
whartung |
perhaps it’s only for friendly sites, not malicious ones |
| 22:30 |
|
asdf |
i do think the same origin policy (which you relax by using ACAO) mostly applies to xhr |
| 22:30 |
|
whartung |
beause there’s nothing stopping a server from using ACAO to enable google.com, yahoo.com, bank.com, etc. etc. |
| 22:31 |
|
k_j |
asdf, I also think there is no difference |
| 22:31 |
|
asdf |
yes but this is the server saying "it's ok if google.com has scripts that xhr me", it's the server's choice |
| 22:31 |
|
asdf |
(and it's the browser who needs to actually obey that choice) |
| 22:31 |
|
whartung |
no, that’s different. The question was what was to stop scripts on a page from malicious.com from access services on bank.com |
| 22:32 |
|
asdf |
yes, and so, bank.com can choose to allow scripts on malicious.com to work or not, right? |
| 22:32 |
|
whartung |
ACAO makes complete sense to limit scrips on pages from bank.com |
| 22:32 |
|
whartung |
but assuming that they don’t. |
| 22:32 |
|
whartung |
(otherwise they wouldn’t be malicious) |
| 22:33 |
|
whartung |
ACAO says that “pages from bank.com will only talk to services on bank.com and partner.com” with a whitelist, so “malicious.com” is locked out |
| 22:33 |
|
asdf |
i think what k_j and i mean is the question of whether bank.com is configured correctly |
| 22:33 |
|
whartung |
wel if it’s not configure correctly then this is a pointless discussion. YOu can’t make a “bad configuration” work correctly |
| 22:33 |
|
whartung |
“correctly" |
| 22:34 |
|
asdf |
whartung, i'm under the impression you think response with a "ACAO: bank.com" means that scripts delivered with that response can only access this? |
| 22:34 |
|
asdf |
that's not true |
| 22:35 |
|
whartung |
That’s what the wiki said. That ACAO limits what domains resources on a page may access. IT’s specifcally designed as an execptioon to the “same origin” policy for scripts et al so that folks could include scripts from other, friendly domains |
| 22:35 |
|
asdf |
instead, you go to malicious.com, the script there sends a XHR to bank.com, your browser sends a OPTIONS to bank.com and examines the ACAO on the response, to decide if it should allow the real request or not |
| 22:35 |
|
asdf |
yes, but it's the included, not the includer, who decides |
| 22:36 |
|
whartung |
eh? |
| 22:36 |
|
whartung |
there’s no way that the server is going to check the ACAO header. Why would it do that? Does the browser even SEND that? It’s a browser side configuration |
| 22:36 |
|
asdf |
i didn't mean to imply the server checks anything |
| 22:37 |
|
whartung |
I’ve never seen an OPTIONS request from a browser |
| 22:37 |
|
asdf |
the included resource (bank.com's response) comes back with ACAO, and the browser decides to display it or not, by comparing the ACAO to the current origin |
| 22:37 |
|
whartung |
(I’m sorry, I misread your comment) |
| 22:38 |
|
asdf |
it should be there :) |
| 22:38 |
|
whartung |
I don’t think the browser makes the rquest at all if the domain on the request is not whitelisted in the ACAO |
| 22:38 |
|
asdf |
the browser can't know what's whitelisted, until it receives a response with the header (response to the OPTIONS) |
| 22:39 |
|
asdf |
because it's the included resource's whitelist that matters |
| 22:40 |
|
whartung |
the browser will load hit a URL, and download the resource. That resource will have an ACOS header (for the sake of discussion). AS the browser interprets the contents of the resource (i.e. the HTML page), it will apply the ACOS whitelist on any requests made by the internal scripts |
| 22:40 |
|
whartung |
and I’m talking about a hit from a A link or a bookmark or whatever. |
| 22:40 |
|
asdf |
no, that's not true |
| 22:40 |
|
whartung |
That’s an “initiating request” for lack of a better term |
| 22:41 |
|
asdf |
there's a very short example on https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Simple_example |
| 22:41 |
|
whartung |
vs an automated request via a script |
| 22:42 |
|
asdf |
as you can see, the wiki example talks about a example.com origin script, that sends a xhr to service.example.com, and service's response has a ACAO that allows the request |
| 22:42 |
|
asdf |
the ACAO list from the original html example.com (if any, there shouldn't be any) doesn't matter at all |
| 22:43 |
|
whartung |
guess I completely misunderstood it then — no surprise. Did I mention that I don’t do much with browsers? |
| 22:43 |
|
asdf |
:) |
| 22:45 |
|
whartung |
so the browser compares the ACOS header with the domain of the parent page make the XHR request? |
| 22:46 |
|
asdf |
yes, and sends the real (non-options) request or throws a javascript xhr error |
| 22:46 |
|
whartung |
ok |
