views:

674

answers:

6

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.

A: 

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.

Brian Scott
what's wrong w/this answer?
Jason
@Jason, the way in which a cookie can be stolen and used has nothing to do with storing a user name and password in the cookie. (I'm not the downvoter).
Yishai
You should not store either the username or the password in the cookie. The safest and sanest way to use cookies is to only insert a single value in the cookie, for example the hash of the correct username, the IP address the connection was made from and some server-side secret value. Store this hash into your database in a row with the username, and use it to fetch the correct data.You should always assume that either the user or someone else WILL tamper with cookie values if you let them, they should be cryptographically secure.
Tuna-Fish
I was only trying to simply demonstrate that storing the password in the cookie was not a good idea in the first place. I agree with Tuna-Fish that a hash would be a good idea for storing the username but I was trying to convey the idea simply to put them on the right track,
Brian Scott
I place +1 just because even if the login info on cookie are totally encrypted, the password is unknown even to the system (hash checked), and nothing shown on any cookie, how ever is not bad to say that again and again.
Aristos
@Tuna-Fish: Actually, the way ASP.NET does it is even safer: it stores an arbitrary value that cannot easily be guessed at. This value is used as a lookup to retrieve the session dictionary on the server side, which is what contains any information about the user (but *never* their password).
Steven Sudit
+2  A: 

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

Paddy
The session is also connected with the cookie. One or two cookies, connect the user with the session and the login.
Aristos
+1 for understanding the threat posed by CSRF, but this doesn't really answer the op's question.
Rook
+4  A: 

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.

Rook
Thank you for the informations, and yet I log, check, and automatically check the ip for every login and act according some rules, but I need to think again my strategy on that. How ever I do not know what asp.net do to ensure the security.
Aristos
@Aristos i updated my answer. But to be honest, if your using a Microsoft development platform your application will be inherently insecure.
Rook
The problem with IP address checking is that a lot of people are behind load balancers these days, which means the IP address is not stable for users.
Yishai
@The Rook, can you provide real data supporting your (vague) statement?
Bruno Reis
@Bruno If you sort all vulnerabilities by severity you will see that Microsoft is a clear leader https://www.kb.cert.org/vuls/bymetric
Rook
So the company with the most software products has the highest number of vulnerabilities ? I would think that would just be common sense. If you follow that logic to the extreme, then the most obscure platform must be the most secure.. security by obscurity ? Not a good way to make a platform decision.
markt
@markt Have you tried to write an exploit for a Windows application? Have you tried to write an exploit that works with SELinux, such as a default Fedora?
Rook
@The Rook: It seems to me that typical web vulnerabilities, such as XSS are mostly platform independent.
DrJokepu
You may also want to add some details about XSRF/CSRF too. Such an attack does not require the authentication cookie to be stolen so it may be handy to mention these too. To add, IP address checking is no more secure than user-agent or anything else in the sent HTTP headers.
Russ Cam
@Russ Cam ip address checking does stop session id theft, where as checking anything in the http header doesn't stop anything at all because they are attacker controlled variables. CSRF does come into play, but it wasn't asked about and i didn't get the check box, so oah well. On a side note you can check the referer to stop CSRF.
Rook
I'm afraid ip address checking does not stop authentication cookie theft, it is trivial to spoof the ip address and in addition, as has been pointed out by other commenters, the ip address can change mid session for users with some ISPs. The referer header again is easy to spoof and not all browsers send it/ it is easy for users to turn off sending of the referer header.
Russ Cam
@Russ Cam a tcp socket cannot be spoofed over the open internet due to the three way handshake. I recommend you do some research before posting on the [security] tag. Making a mistake here means someone will get hacked. I am well aware of load balancers and their affect on the outgoing ip address and i do not do this on my systems.
Rook
@Rook: A more scientific study would normalize the number of reported exploits against the number of users. MS is cursed with popularity. Back when the Mac was on the fringe, it was pretty safe. Now that it's more popular, it's less safe. So it goes.
Steven Sudit
@Rook: I read Russ Cam's comment, and his point was *not* that IP's can be spoofed but, rather, that an IP can change in the middle of a session for innocent reasons that are not an indication of spoofing. I strongly recommend that you read more carefully before responding, especially when taking such a negative tone. Thank you.
Steven Sudit
@Steven Sudit actually he deleted the comment. Maybe you shouldn't follow me around. MS has gotten better, but historically they have been the worst. They have left remote code execution vulnerabilities open in IE for YEARS. Look up the Drag and Drop vuln.
Rook
@Rook: I use Chrome for a reason. But don't flatter yourself: you're not the only one who follows the [security] tag.
Steven Sudit
@Steven Sudit three comments back to back? Its okay to read my posts and to respond, its another thing to ridicule my every post.
Rook
@Rook: I can't help it if you feel that my comments are ridicule, but I will point out that I've upvoted you in the places where you were correct and have not downvoted you.
Steven Sudit
@Steven Sudit well thank you, there are people that give me -1's because I'm an asshole. I'm not too bothered by it. I do like helping people and I like the thanks I get from people on SO. I am happy to answer any questions you may have or rebut a counter argument.
Rook
@Rook: I promise to try to be more patient with you, asking only that you attempt the same.
Steven Sudit
@Steven Sudit I am often very harsh with people when it comes to security matters. There is a lot of misunderstanding because it is a difficult topic and a mistake means you will be hacked. Never the less this is a academic setting and we should be respectful to our peers. I'm sorry if I have offended you.
Rook
@Rook: Nothing to apologize for. You are entirely free to disagree with me. All I ask is that you make an honest effort to explain the source of that disagreement, so that it doesn't become personal.
Steven Sudit
+4  A: 

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.

uncle brad
I strongly agree with you, needs more to check, and not get it all out of the box as you say.
Aristos
+4  A: 

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.

Thomas
The requireSSL=true, is something that I have miss. I think this is one of the most important.
Aristos
+1  A: 

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...

Aristos
Not sure I understand what you're getting at. May be a language problem.
Steven Sudit
@Steven I just place a flag on the session data (that are different from the login data) that the user has been pass the login page.
Aristos
Ok, but if the user logs in and then their session is hijacked, the flag will be set already. Or am I missing something?
Steven Sudit
@Steven he must hijack 2 different cookies, one for the login, one for the session. The one is transfer only using ssl. I think that is more difficult to hack 2 different cookies (with different way of code/decode/variables) than one. its a way to connect this cookies together. He can not log and hijack the session, because the log keep the critical information of permissions. This is for case that someone try to crack the cookies, or sniff them.
Aristos
@Steven this vide http://www.youtube.com/watch?v=yghiC_U2RaM is show what I try to prevent.
Aristos