Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I was recently told that a cookie is "safer" than a regular old HTTP header, which is safer than a URL parameter, particularly when passing around access tokens. What is the reasoning behind a cookie being safer than an HTTP header?
Also, I'm pretty sure I understand why a URL param is unsafe: because it is visible all the time and can easily be grabbed. Is that correct?
Cookies are HTTP Headers. The header is called Cookie:, and it contains your cookie.
But cookies are in fact safer than URL parameters because cookies are never sent to other domains. URL parameters, on the other hand, will end up in the Referer: header of any site you visit directly from the one with the URL parameter.
Referrer contains the full query string? Or just variables passed as part of the path?
Referer: (correctly misspelled) is up to the browser to implement, but as a rule it contains the referring URL exactly; including query string.
Referer contains the whole URL as sent to the HTTP server. It does not contain the local part after the #.
Aug 8, 2013 at 7:07
There are three standard ways to pass data from the browser: GET, POST, and cookies (which are sent for both GET and POST requests). Here's an example request as it's sent to a server if you asked for www.example.org/spec.html?secret=foo:
GET /spec.html?secret=foo HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*
Putting session information in the URL makes it prone to being copied by the browser's user. From a visibility standpoint on the wire, though, it makes no difference. It's for this reason that sensitive data is often POSTed. Whichever way you make a request, keep in mind it probably should be protected against CSRF.
As for cookies, they provide a way to store data that lasts across the duration of a session or throughout browser tabs.
If you are passing authorisation token via http headers then you need to have a client side logic to pass this to server every time you make a request. A skimmer can look for this in your client side code and can hijack your user session with Java script.
But if the same info is passed via cookies then it is the browsers responsibility to pass the cookie whenever a request is made(you are freed of writing client side logic). So making it a bit difficult(but not impossible) to identify the mechanism in which the token is being passed.
If the cookie is set to be httponly then session hijacking becomes almost impossible via JavaScript(have read some browsers do give out this info to JavaScript but support is increasing). And cookies have a same origin policy. But still using tools like fiddler a determined hacker will be able to access this info.
But the hacker should be able to sniff the network to get to this info.
So in conclusion a cookie is definitely safer.
If you are so concerned about security then go for SSL certificates which almost removes the threat of network sniffing a futile activity.
Cookies are part of the HTTP header, so they can not be safer than themselves. Cookies have security flags built into their specification: HTTPOnly and Secure, the latter of which prevents transmission over non-SSL connections.
Parameters as part of the URL are prone to being logged by web services you're running as part of statistics or otherwise, leaving them open to read in plaintext for anyone who can get access.
URL parameters get sent in the Referer header to other sites, so are the worst way to pass sensitive data.
The (obsolete) Cookie2 header is encrypted using a nonce provided by the site in its Set-Cookie2 response header. This therefore is the least bad, but isn't supported well.
Other request headers (including Cookie) are somewhere in between.
None of these options are "safe".
The only safe option is HTTPS (i.e. SSL) using a mutually trusted certificate authority.
Referer. He can read (even capturing form data) and modify any part of the page (displaying incorrect information to the user, or changing form data just before submission), and retrieve any cookie not marked HTTPOnly, and do anything on behalf of the user.
Aug 8, 2013 at 22:17
I guess both cookies and headers have strong and weak points. Since some answers already point to the cookies strong points, I will mention the strong point of headers. Headers need to be transmitted programmatically by the js application; they are never automatically transmitted by the browser upon accessing an URL on the respective domain. This makes such that other js applications or snippets cannot send the header automatically, thus eliminating a whole range of attacks in the CSRF or cross site scripting areas. Of course using only HTTPS over TLS and disabling downgrading to HTTP are necessary in both cases.
refererheaders by the browser.