4 ms·
So, it depends on the request type, GET vs POST and others. Before the client does the request for data, it does a preflight request via OPTIONS to determine w
by dillonmckay 7y ago
So, it depends on the request type, GET vs POST and others.
Before the client does the request for data, it does a preflight request via OPTIONS to determine what is allowable (is this domain allowed, this type of call).
If it is allowed, it can send and request cookies on the requested domain in the current standard.
However, this is not supported in older browsers, so the request will just work.
In newer browsers, without the preflight check, the server still receives and replies to the request, but the reply is ‘ignored’ by the browser and throws an error.
- mehrdadn 7y agoI'm aware of OPTIONS but it still seems like the same exact stupid browser security hole (edit: or perhaps I should say HTTP protocol flaw?) being half-patched on the server side. Like, I'm saying that -- independent of the HTTP method -- there should be no communication of privileged information in the first place by default. If a website really wants other arbitrary websites to send e.g. a cookie along, then there should be a way to mark that cookie as such at the time that it is originally set, not having it checked post-facto. It sounds like the only reason this is done is backward-compatibility?
- dillonmckay 7y agoDefinitely not disagreeing. The server still sees the request, so the data can be exfiltrated. In terms of backwards compatibility, it is actually the opposite. Newer browsers will block stuff that worked in older versions.
- tgsovlerkhgsel 7y agoYou can mark a cookie as samesite: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#samesite-cookie-attribute https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... (as you mentioned, backwards compatibility requires that this is opt-in when the cookie is set, not opt-out)
- mehrdadn 7y agoOh wow, 2017. Finally...