Can some hacker steal the cookie from a user and l

Question

Reading this question

different users get the same cookie value in aspxanonymous

and search for a solution, I start thinking, if it is possible for some one to really steal the cookie with some way, and then place it on his browser and login lets say as administrator.

Do you know how form authentication can ensure that even if the cookie is stoled, the hacker not actual login using it ?

Or do you know any other automatic defense mechanism ?

Thank you in advanced.

Answer 1

I am working on this, and I am coming up with an idea, that I am not sure if it is 100% safe, but is an idea.

My idea is that every user must pass from the login page.
If some one stole the cookie, is not pass the login page, but is go direct inside to the rest pages. He can not pass the login page, because did not know the really password, so if he pass he fail anyway.

So I place an extra session value, that the user have been pass with success the login page. Now inside every critical page, I check that extra session value and if found it null, I login off and ask again for the password.

Now I do not know, maybe all that done all ready by microsoft, need to check it more.

To check this idea I use this function that direct make a user logged in.

FormsAuthentication.SetAuthCookie("UserName", false);

My second security that I have all ready fix and use, is that I check for different ips and or different cookie from the same logged in user. I have made many think on that, many checks (if is behind proxy, if is from different countries, what is look for, how many times I have see him, etc...) but this is the general idea.

This video show exactly what I try to prevent. By using the trick I have describe here, you can not just set the login cookie only.

Just sharing my ideas...

Answer 2

I don't know the specifics of the cookie in question but it's generally bad practice to store both the username and password in a user cookie. You generally want to only store the username in the cookie along with other non sensitive information. That way the user is prompted to provide their password only when logging in.

Answer 3

In a lot of cases, the cookies used for authentication are matched with a session on the server, so it's not just possible to take a cookie and be 'logged in', however, you might want to have a read about cross site request forgeries, which do allow a mechanism for this cookie to be used maliciously:

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Answer 4

Is it possible to steal a cookie and authenticate as an administrator?

Yes it is possible, if the Forms Auth cookie is not encrypted, someone could hack their cookie to give them elevated privileges or if SSL is not require, copy someone another person's cookie. However, there are steps you can take to mitigate these risks:

On the system.web/authentication/forms element:

1. requireSSL=true. This requires that the cookie only be transmitted over SSL
2. slidingExpiration=false. When true, an expired ticket can be reactivated.
3. cookieless=false. Do not use cookieless sessions in an environment where are you trying to enforce security.
4. enableCrossAppRedirects=false. When false, processing of cookies across apps is not allowed.
5. protection=all. Encrypts and hashes the Forms Auth cookie using the machine key specified in the machine.config or web.config. This feature would stop someone from hacking their own cookie as this setting tells the system to generate a signature of the cookie and on each authentication request, compare the signature with the passed cookie.

If you so wanted, you could add a small bit of protection by putting some sort of authentication information in Session such as a hash of the user's username (Never the username in plain text nor their password). This would require the attacker to steal both the Session cookie and the Forms Auth cookie.

Answer 5

There are many ways that a session id can be leaked to an attacker. XSS is the most commonly used attack to hijack a Session ID and you should test for XSS vulnerabilities in your application. . A common method of improving the strength of a session is to check the IP address. When the user logs in, record the ip address. Check the IP address for every request, if the IP changes then its probably a hijacked session. This secuirty measure could prevent legitimate requests, but that is very unlikely.

Do not check the X-Forwarded-For or User-Agent, its trivial for an attacker to modify these values.

I also recommend enabling httpOnlyCookies in your web.config file:

<httpCookies httpOnlyCookies="true"/>

This makes it more difficult for an attacker to hijack a session with javascript, but its still possible.

Answer 6

The scenario where a cookie can be stolen happens in a public wireless environment. While you or I would never operate in such a setup, it may be impossible to prevent your customers from doing so.

If the attacker knows what secure site you're connected to, the idea is that your browser can be tricked into posting to a non-secure version of the same url. At that point your cookie is compromised.

That's why in addition to httpOnlyCookies you'll want to specify requireSSL="true"

<httpCookies httpOnlyCookies="true" requireSSL="true" />

I disagree with The Rook's comment, in that I find it unfair;

@Aristos i updated my answer. But to be honest, if your using a Microsoft development platform your application will be inherently insecure. – The Rook 22 mins ago

Security doesn't happen by accident and it doesn't happen "right out of the box", at least not in my experience. Nothing is secure until it's designed to be so, regardless of the platform or the tools.