In one of the applications , there was a vulnerability-they were not marking the cookie as 'HTTPOnly' but marking it as 'Secure'. I recommended them to as a best practice, flag the cookie as 'HTTPOnly' as well.
Set-Cookie: JSESSIONID=AJ122112KJYS.......; secure
Now they fixed it- They were setting the Cookie (Set-Cookie) as soon as the application loads in the browser and marking it as 'Secure'. Once the user is successfully authenticated they were regenerating the session ID and again (Set-Cookie) and this time marking it as 'HTTPOnly' only.
Set-Cookie: JSESSIONID=7H8TKLSDOPC56.......; HTTPOnly
Fine! but really? They were using the Set-Cookie header two times. First time they were marking it as 'secure' and again after regenerating it marking it as 'HTTPOnly'. Now this was the problem. Setting the cookie with Set-Cookie again overwrites the earlier attribute of Cookie. That means if you are setting cookie as 'secure and again setting with some other attribute , for example, 'HTTPOnly' then your cookie is no longer 'secure' now.
So best practices is flag it simultaneously with both the attributes:
Set-Cookie: JSESSIONID=7H8TKLSDOPC56.......; HTTPOnly; secure
Nice link: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
Thanks to Sripathi Krishnan for sharing this.
It says:Overwriting cookies: if a new cookie with the same NAME, domain, and path as an existing cookie is encountered, the old cookie is discarded. Otherwise, even if a subtle difference exists (e.g., two distinct domain= values in the same top-level domain), the two cookies will co-exist, and may be sent by the client at the same time as two separate pairs in Cookie headers, with no additional information to help resolve the conflict.
Set-Cookie: JSESSIONID=AJ122112KJYS.......; secure
Now they fixed it- They were setting the Cookie (Set-Cookie) as soon as the application loads in the browser and marking it as 'Secure'. Once the user is successfully authenticated they were regenerating the session ID and again (Set-Cookie) and this time marking it as 'HTTPOnly' only.
Set-Cookie: JSESSIONID=7H8TKLSDOPC56.......; HTTPOnly
Fine! but really? They were using the Set-Cookie header two times. First time they were marking it as 'secure' and again after regenerating it marking it as 'HTTPOnly'. Now this was the problem. Setting the cookie with Set-Cookie again overwrites the earlier attribute of Cookie. That means if you are setting cookie as 'secure and again setting with some other attribute , for example, 'HTTPOnly' then your cookie is no longer 'secure' now.
So best practices is flag it simultaneously with both the attributes:
Set-Cookie: JSESSIONID=7H8TKLSDOPC56.......; HTTPOnly; secure
Nice link: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
Thanks to Sripathi Krishnan for sharing this.
It says:Overwriting cookies: if a new cookie with the same NAME, domain, and path as an existing cookie is encountered, the old cookie is discarded. Otherwise, even if a subtle difference exists (e.g., two distinct domain= values in the same top-level domain), the two cookies will co-exist, and may be sent by the client at the same time as two separate pairs in Cookie headers, with no additional information to help resolve the conflict.
Comments