Suppose a cookie say FB's authentication cookie is encrypted and sent to me. If i use tools like wireshark, Firesheep then I can sniff that encrypted cookie. I open a new browser and inject this encrypted cookie(using greasemonkey and some scripts) and eventually it's going to work. Whats the purpose of encryption here ?
Because the point is even after encrypting I am going to send the encrypted cookie each time I click something on facebook after logging in and the sniffing tools can get that. Pls explain ????
most websites use cookie to identify user login, and yes, the cookie is visible to you. but every time you login in the website, the website would send a new encrypted cookie to you, your old/previous cookie would not be working. And cookie has a date to expire, the encryption on the cookie is to stop user calculating the cookie for login next time. If the user could have the formula for generating the cookie string, there would be no security for the website. cheers!
By the way, you should understand this for doing good things, don't do bad things, keep our Internet safe and tidy! thanks!
Related
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
If client use cookie auto login for 30 days.hacker could login and change user information when get the client cookies. How to prevent this?
sorry for my bad english!
tks in advance!
You should make sure cookies are only ever transmitted over an SSL connection. This is pretty much the only way to prevent cookie hijacking.
Other ways to help prevent (but none will work 100% effectively) is to make sure you use unique identifiers in your cookie that expire. IE, after every login, change their user ID which is stored into their cookie. This means if someone hijacks a cookie, or hijacks old cookies there is a good chance they should have expired.
by not storing any login information on the client pc. At least not automatically. If the user does so, it is up to her. But you should not encourage her to do such unsafe things.
Go here and start reading: The Definitive Guide To Website Authentication
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:
requireSSL=true. This requires that the cookie only be transmitted over SSL
slidingExpiration=false. When true, an expired ticket can be reactivated.
cookieless=false. Do not use cookieless sessions in an environment where are you trying to enforce security.
enableCrossAppRedirects=false. When false, processing of cookies across apps is not allowed.
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.
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...
Due to a bug in Flash, I have to use the ASPXAuth cookie to log a user in on a page that a flash upload script calls after upload. See this page for more information: http://geekswithblogs.net/apopovsky/archive/2009/05/06/working-around-flash-cookie-bug-in-asp.net-mvc.aspx
I have to make the ASPXAUTH string "public" in the sense that it will be in the HTML of the page. My question is, how secure is this?
I understand that anyone that can get to the string in the HTML can probably get to it from the cookie just as easily, but let's say someone does have this ASPXAUTH string. Is it possible that they can login as another user using this cookie? Would they be able to decrypt it?
Bara
The value of the Forms Authentication cookie could be decrypted if a 3rd party had obtained the decryption key used by your website. Otherwise, I guess it would be a case of using brute force methods to crack it.
Make sure you prevent the page from caching at both client , proxy and server.
You really don't want the page to be stored in any caches if it contains aspxauth cookie values in the markup.
Personally I would use SSL for the connection if it was very sensitive data.
I'm working on a website where I get a feed of usernames / hashed passwords from another service. When someone sucesfully logs in I set a forms authentication cookie with FormsAuthentication.SetAuthCookie.
My client doesn't like multiple people logged with the same credentials. They would like a log in to invalidate any currently logged in clients.
There isn't a method on FormsAuthentication to tell the server "invalidate any other cookie under this name". KB900111 suggests the server doesn't maintain a list of valid cookies. So my approach isn't sounding good.
What's the alternative? Time to ditch forms auth?
Not necessarily. Forms auth still provides quite a bit of baked-in functionality you might want. Maybe you can generate and issue a Guid the first time each user logs in, and store that on the server-side, and in a cookie (security ticket preferably). Every time a request is made, you check to make sure the user is using not only the correct credentials, but also the same machine and browser (based on the cookie you issued the user when the user logged in). You would of course have to make sure that your Guid expires at some point, and also make sure you clear it out when the user signs out.