Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
"Safe" is a meaningless term, just as "secure". You have to define a context: who is your adversary? Do you consider the possibility of wiretapping? Do you consider a website with user supplied contain, like this very website? –  curiousguy Aug 8 '13 at 7:10
    
Yes, parameters in the URL are visible, will be stored in browser history, will be more likely to be stored in server logs, and can be passed in referer headers by the browser. –  SilverlightFox Aug 8 '13 at 9:23

4 Answers 4

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.

share|improve this answer
    
Are you saying Referrer contains the full query string? Or just variables passed as part of the path? –  lynks Aug 7 '13 at 9:42
    
Referer: (correctly misspelled) is up to the browser to implement, but as a rule it contains the referring URL exactly; including query string. –  tylerl Aug 7 '13 at 17:37
    
@lynks The Referer contains the whole URL as sent to the HTTP server. It does not contain the local part after the #. –  curiousguy Aug 8 '13 at 7:07
    
+1 Cookies also come with useful features like "secure" and "httponly". –  u2702 Aug 8 '13 at 16:42

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.

share|improve this answer
    
Is there any security advantage with the same origin policy? –  kishinmanglani Aug 7 '13 at 4:21
1  
The same origin policy prevents sites access to cookies which are not their own... but an advantage over what? –  Ditmar Wendt Aug 7 '13 at 4:34

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.

share|improve this answer
  1. URL parameters get sent in the Referer header to other sites, so are the worst way to pass sensitive data.

  2. 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.

  3. 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.

share|improve this answer
    
I would like to point out that the RFC you reference (2965) was obsoleted by RFC 6265 and depreciates and obsoletes the Set-Cookie2 and Cookie2 headers as their use and implementation are no longer recommended. –  Joshua Aug 8 '13 at 4:56
    
1: You (the webmaster) control the outbound links. If you can manage to have only links to sites under your control, 1. is not a problem. 2: Who implements Cookie2? –  curiousguy Aug 8 '13 at 7:05
    
@curiousguy, it's not just outbound links that have a referrer. If an attacker injects an image, javascript, or any other resource in the page, the browser will download the resource. When the browser fetches those resources, it'll include the referrer header too. –  Joshua Aug 8 '13 at 15:57
    
@Joshua "If an attacker injects an image, javascript" If the attacker can inject JS, then he just controls the webpage. He does not need the capture a 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. –  curiousguy Aug 8 '13 at 22:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.