0

Is possessing someone's cookie enough to bypass an authentication mechanism so that I'll be granted access to his / her account? I mean, if the "secure" flag is set on the cookie then it is encrypted so the attacker is out of luck. If the HTTPonly flag is set, Javascript code will not be able to read it but even if it does it's just a random string that will be collected. So how may the attacker even know where to send the cookie?

  • 1
    One clarification on the 'secure' cookie flag. This just instructs your browser not to transmit the cookie in requests unless they are sent over an encrypted SSL/TLS connection. It doesn't actually encrypt the cookie itself. – PwdRsch Feb 18 '17 at 17:48
  • depends; on this site yes, on gmail no... – dandavis Feb 19 '17 at 9:48
2

Usually with web applications, after the user has authenticated, the server will supply a session cookie to the browser, which is supplied with each subsequent request to the application in place of having the user supply their password with each request.

As such, if an attacker is able to steal a user's session cookie and make requests to the server, it is likely that the server will assume the request comes from the original user and provide access to the application, as long as that cookie remains valid.

All of this is speaking generally, in specific cases additional mechanisms might be used to mitigate the risk of cookie theft.

  • Is there any way to tell just by looking at the cookie in the browser what type of cookie it is? – cyzczy Feb 18 '17 at 12:16
  • 1
    In some cases the the web application framework used to develop the site will have a default name for their session cookie, e.g. .ASPXAUTH or PHPSESSID however there's nothing to stop the site renaming that. – Rоry McCune Feb 18 '17 at 12:18
  • So the solution to prevent cookie hijacking would be to implement HSTS and use SSL for all the conntent served by the web server,correct? – cyzczy Feb 18 '17 at 12:24
  • Definitely allowing session cookies over an unencrypted connection is a bad idea. I'd say SSL + HSTS + setting the 'secure' flag on the cookie are all good mitigations for that risk. Also worth setting 'httponly' on the cookie to reduce the risk of an application level flaw like XSS being used to steal that cookie. – Rоry McCune Feb 18 '17 at 12:42
0

Multiple cookies can be issued by using multiple Set-Cookie headers in the server’s response. These are submitted back to the server in the same Cookie header, with a semicolon separating different individual cookies. In most cases, applications use HTTP cookies as the transmission mechanism for passing these session tokens between server and client. The server’s fi rst response to a new client contains an HTTP header like the following:

Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

and subsequent requests from the client contain this header:

Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

This standard session management mechanism is inherently vulnerable to various categories of attack. An attacker’s primary objective in targeting the mechanism is to somehow hijack the session of a legitimate user and thereby masquerade as that person

0

That is generally the case but it is entirely dependent on how the application is coded. If that cookie is the only thing capturing the session then yes. As far as cookie security is concerned. Make sure to set the secure flag like you said. Also, make sure to use something approved by the security community to ensure sufficient entropy. Sometimes it's possible to predict future cookies if they aren't sufficiently random. Also, make sure to set the http only flag on it. This prevents it from being accessed from JavaScript. If a site is vulnerable to xss, an attacker could easily craft an attack vector, use document.cookie, and transport that cookie to a remote location, if the http only flag is not set.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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