Can some hacker steal a web browser cookie from a user and login with that name on a web site?

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 stolen, the hacker does not get to use it in an actual login?

Is there any other alternative automatic defense mechanism?

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.

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.

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.

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.