4

I have read the OWASP information and also a range of articles including Jeff Atwood's Protecting Your Cookies article and I still feel I need to understand HttpOnly cookies better.

This came about because I needed to add some Google Adword tracking code to a site. This javascript needed to set and read a cookie on the website's domain and I assumed that this was an issue. The website is a .Net application with httpOnlyCookies="true" in the web.config, so I assumed that the best approach would be to replace the javascript and write the cookie from the backend to ensure that the generated cookie was HttpOnly. I could then easily read the cookie in the server-side too.

I understand that setting the HttpOnly of a cookie property largely prevents a cookie from being read and manipulated by the client. But what I don't understand is:

  • Given the example above, would there have been a problem with me using the javascript implementation?
  • Would it still have been ok to write the cookie using javascript (but still read it using the server-side)? I'm thinking not as the cookie is then not a HttpOnly cookie
  • If I have done the right thing (moving everything to a server-side implementation), why are Google Analytic cookies always implemented as non-HttpOnly cookies? Surely they pose a security issue too?

So as the title says, I guess what I'm asking is - when (if ever) is it appropriate to have non-HttpOnly cookies on your domain?

Digbyswift
  • 10,310
  • 4
  • 38
  • 66
  • Cookies that retain information that's not of a secure nature (like, a cookie that remembers the last-used browser window size) are really not a security issue. Who cares if the information is leaked? – Pointy Mar 18 '14 at 12:57
  • 3
    Any time you _want_ JavaScript to be able to read the cookie, you need it to not be HttpOnly. You don't want to do this with, for example, an authenticated session key. – mah Mar 18 '14 at 13:01
  • @mah Yes that is fairly obvious :) The question is when is it appropriate to use a non-HttpOnly cookie? If I can handle all my cookie implementations server-side, should I? Or is it overkill? If so why? – Digbyswift Mar 18 '14 at 13:06
  • 2
    To answer the question you must first consider the purpose of the cookie. If it's related to a user preference in how something gets displayed then perhaps JavaScript handling is a better solution. If instead it's a user preference concerning what data gets displayed (filtering out data perhaps) then a server side solution might be better (to limit bandwidth) but HttpOnly is probably not important (since there's no security ramification -- or shouldn't be). HttpOnly is really only necessary for things that are security sensitive. – mah Mar 18 '14 at 13:09
  • 1
    So a HttpOnly requirement can be disregarded for *any* cookies that contain non-sensitive information. It's that simple? – Digbyswift Mar 18 '14 at 14:30
  • Yes, it's that simple. – mah Mar 18 '14 at 18:20

2 Answers2

3

So this is much more straightforward than I assumed. According to the comments left by @mah above, flagging a cookie as HttpOnly is redundant when the cookie contains non-sensitive information.

Digbyswift
  • 10,310
  • 4
  • 38
  • 66
2

The httpOnly option was response to JavaScript tricks to steal user's session cookie. It was because the session cookie is a temporary credential that allows you access to user's logged-in session on the server.

In case of any other, non-session cookies it really depends on your own risk assessment. If you're not really concerned about slightly increased exposure without httpOnly or you just have a business need to access their values from JavaScript, just ignore this option.

Some security scanners or incompetent pentesting teams will report missing httpOnly flags for each cookie just because it's trivial to spot and allows them to easily inflate their report. But explaining the actual purpose and origin of httpOnly should be sufficient to counter that.

kravietz
  • 10,667
  • 2
  • 35
  • 27