I've been looking into the CSRF vulnerability and how to fix it in .NET application.
Based on my research here is the pseudo algorithm I need to do:
Check request for CSRF token in the request cookie, if it is not there, create one
on the server.
Once the token is created, add the token to the
response cookie to send back to client. Client sends this CSRF
token for all future request cookie.
When server receives a request and it
sees the CSRF cookie, the server validates against its stored CSRF
token value.
When it matches, then business as usual, if the values
don't match then stop the request.
My question is in step #3, I'm using ASP .NET web form; I can store this CSRF token in either Session or a ViewState.
I don't want to use ViewState because all the pages in our application have to support EnableViewState="true". If not, the ViewState content is wiped out on each and every post-back call.
Can I use Session in this situation? Does it compromise the fix if I use Session instead of ViewState?
So you're going for the Synchronizer token pattern (STP) technique, using a single token per user session.
There's no problem in using the ASP .NET session storage for saving CSRF tokens, based on the trivial assumption that the attacker has no access to it, this doesn't compromise your solution in any way. Nonetheless, as pointed out in Gabor Lengye's comment, using cookies to send the CSRF token to the server is flawed, embed the token in an HTML form instead, or use the Cookie-to-header token technique.
That said, I suggest you take a look at the AntiForgery Class which has built-in token generation, HTML embedding and validation methods. Security wise it's never a good idea to implement your own solution, instead go for established, trusted solutions.
Also make sure to use HTTPS to prevent your tokens from being hijacked in a Sniffing attack
I'm building a website with asp.net core and I had the idea to let my users log in as follows:
Let the user enter a discord tag (in the more general case, you could use an email address instead)
Send a token to the given discord user (or email address)
Let the user enter the token that was sent to them
I've read about asp.net core's cookie login system, but I have trouble applying it with this authentication sequence and I am not sure if this is a safe way to log in.
My first thought was to use sessions. I'd generate a random token and store it together with the given discord tag in a session and I'd wait for the user to provide the token and compare. However, I read here that it's not safe to store sensitive data in a session and on top of that, I read that the use of a session gives the app a big performance penalty, so I feel like using sessions is not the right approach.
So my question is like this: Can I perform this authentication sequence without a session?
The only other way I know to keep data between requests is to use a cookie, but I know that it's not secure at all to keep login data in a cookie, even if it's encrypted, because users can change their cookies locally.
My idea with cookies was to create a json string with the username, the generated token and a timestamp and encrypt it server side with a symmetric encryption algorithm. Then when the user sends their token, I can decrypt the cookie and read the discord user and the expected token and see if it has timed out or not with the timestamp. But because cookies are stored client side, I'm not sure if this is secure.
Here's some context, just in case:
I'm building a small web based game and I want it to be both controllable throught the website and through discord. I somehow have to know from a requester which discord account belongs to them, so I want them to use their discord tag as a username to log in. I figured for a small game like this, it would be overkill to force people to make an account if they're only using it a few times, so I just want to quickly verify that the discord name they use is the one that they own.
I am not very familiar with authentication, so I don't know if I'm thinking in the right direction or if I'm doing it completely wrong.
Using Firefox: I am authenticated with valid credentials with ZAP proxy I capture the 302 response code and a valid cookie.
Using Chrome: I am providing wrong credentials and replace the response with the captured 302 response containing the valid captured cookie. I'm now able to login to the application.
Is this finding a False Positive case or not?
If not then what will be the mitigation to resolve this issue.
Mitigation Suggested:
Multiple user logins in multiple browsers and multiple machines should be validated.
If matched, invalidate the existing cookie and make the user authenticate again.
I am a penetration tester and doesn't have the application code.
User should not be authenticated to the application without providing valid credentials.
Keep in mind, that if you steal session cookie - it's like you have stolen valid credentials. the fact that you given wrong credentials earlier doesn't care - as long as you have valid session cookie it's the same as if you had valid key to door - you'r allowed to enter.
is it ok? It depends.
First, it depends on session cookie. If it has flags HttpOnly, and secure flag, and whole communication is send via ssl (https) we may assume that this cookie is kind of safe, because in theory - it could be accessed only on server and sending device, only via browser. The only case it could be stolen (in theory) is as you did - someone has access to logged in device and steal it. It's matter of anty-virus software, user etc to secure this PC, not a tested system to prevent such stealing.
on the other hand - if system stores some crucial data it should validate user not only by cookie. It should also check if request was send from the same browser as the one associated with cookie, with the same ip etc. Keep in mind that those data still can be tampered.
session cookies are like a key to a door - if someone got yours, he could enter building. Problem here is not with the fact that a valid key allows anyone using it to enter, but the fact what this key allows to open. It depends on what he enters. If the key allows entrance to bike lockers or toilet - nah, it's secured enough - as long as you don't allow anyone to have your key (or steal cookie) its good. But if this key allows user to enter a bank vault - it's a big security issue, because entering vault should not only rely on having valid keys, but also on some other kind of person verification such as fingerprint or eye scanner.
so without knowing the context of an app it's hard to answer you'r question. I hope i explained it to you properly
i am using a session cookie (not a permanent one) to save the user id to know if the user is logged in.
basically, user logs in, we check the credentials, then set a session cookie userID = 37 (for this particular user, another user would have 73 or 69, etc...)
Session.Add("UserID", 37);
my question is, is it possible for the logged in user to somehow change this session cookie from 37 to 73 and thus fool the server into thinking he is actually user 73?
if YES, then what am i doing wrong, how to handle this case? it seems insane to put in session user id and password hash and check them EVERY TIME??
we are using this userid value also in queries later to restrict them.
i am sorry if this is not an EXACT code question, but it is very much relevant to my code.
The session cookie contains only the session id. It is used to identify the user. It contains nothing more. The actual information for this session is stored on the server. So this is secure. The user can never change the value that has been stored on the server. The user cannot change his id if you stored this inside the session.
This being said, when dealing with user ids you could consider using forms authentication to track authenticated users instead of reinventing wheels with the Session.
ASP.NET session state provides an important security advantage over client state management techniques in that the actual state is stored on the server side and not exposed on the client and other network entities along the HTTP request path. However, there are several important aspects of session state operation that need to be considered in order to maintain application security. Security best practices fall into three major categories: preventing session ID spoofing and injection, securing the state storage in the back-end, and ensuring session state deployment security in dedicated or shared environments.
Read : Securing Session State
That isn't the cookie, and is perfectly safe as it cannot be changed by the user. The only thing stored on the server side in a cookie is the session ID.
As the other answers have noted, the actual value (37 in the example) is stored on the server, not the client, but that doesn't mean that you're immune to potential attacks. This mechanism is still vulnerable to cross site scripting attacks. Basically, what is stored on the client's cookie is some big long identifier. If someone other than the actual user gets ahold of that identifier they can put that in a cookie of their own and essentially pretend to be that user. You can research cross site scripting more on your own (I'm not an expert on the subject) to see some of the common ways that a malicious user will attempt to look at other users' cookies and to try to set it as their own, along with ways of defending against such attacks (some of which I'm sure will be done for you by browsers and ASP).
I am using asp.net mvc 2.0 and I am wondering how secure is it to put information in a cookie?
Like I put in my cookie a forms authentication ticket that is encrypted so can I put information that could be sensitive in there?
string encryptedTicket = FormsAuthentication.Encrypt(authTicket)
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
Like I am not storing the password or anything like that but I want to store the UserId because currently every time the user makes a request to my site I have to do a query and get that users Userid, since every table in my db requires you to use the userId to get the right row back.
So these start to add up fast so I rather have it that if a user is authenticated once then that's it till they need to be re-authenticated again. If I would store this userId I could save so many requests to the database.
Yet I don't want it floating around in clear text as potential someone could use it to try to get a row out of a database when they really should not be.
Show how good is this encryption that Authentication uses?
The encryption is good enough, that's not the weak link.
The weak link is that the cookie value could be intercepted, and someone else could impersonate the user.
So, the information in the cookie is safe enough, but you can't protect the cookie itself.
The title of your question doesn't really match what you are asking. There are two different things you are asking here.
1. Is there a secure way to store data in a cookie?
The answer is yes. To safely store data in a cookie you have to encrypt the data you want to store then sign the encrypted data. Encrypting it prevents attackers from being able to read the data, signing it prevents attackers from modifying the data. This will ensure the integrity of the data. You could use this method to store data about the user you want to keep private (their email address, date of birth, etc). Note: Securely storing data in a cookie is not a safe way to authenticate a user! If you stored the user id of the user in the signed and encrypted cookie, nothing prevents an attacker from stealing the entire cookie and sending it back to the server. There's no way of knowing if the authentication cookie came from the same browser where the user entered their user name and password. Which leads us to the second question (the one you were actually asking)...
2. Is there a secure way to authenticate a user with a cookie?
Yes. To securely authenticate a user you must combine the techniques from question 1 with SSL (https). SSL ensures that only the browser will be able to access the authentication cookie (the signed encrypted cookie with the user id in it). This means that your login process (accepting the users name and password, as well as setting the authentication cookie) must happen over SSL. You must also set the HttpCookie.Secure property to true when you set the authentication cookie on the server. This tells the browser to only include this cookie when making requests to your website over SSL. You should also include an expiration time in the encrypted auth cookie to protect against someone forgetting to log out of your site while they are at the library. A side affect of this approach is that only pages on your site that are SSL will be able to authenticate the user. Which brings up a third question...
3. How do you securely authenticate a user without using SSL?
You don't. But you do have options. One strategy is to create two auth cookies at login, one regular cookie and one that is ssl-only (both encrypted and signed though). When performing sensitive operations on the users behalf, require the page be in SSL and use the SSL-only cookie. When doing non-sensitive operations (like browsing a store that is customized based on the country their account is in) you can use the regular auth cookie. Another option is to split the page so that information that requires knowing who the user is is retrieved async via AJAX or json. For example: You return the entire page of the blog over http and then you make an SSL AJAX request to get the current users name, email, profile pic, etc. We use both of these techniques on the website I work on.
I know this question was asked almost a year ago. I'm writing this for posterities sake. :-)
Along with cookie encryption, you should also implement a rotating token to prevent replay attacks.
The idea being that the encrypted cookie contains some value which can be compared to a known value on the server. If the data matches, then the request succeeds. If the data doesn't match then you are experiencing a replay attack and need to kill the session.
UPDATE
One of the comments asked if I meant to store the value in the cookie. The answer is yes. The ENTIRE cookie should be encrypted, which can be automatically done through the use of an HttpModule. Inside the encrypted cookie is any of your normal information + the changing token.
On each post back, check the token. If it's valid, allow the transaction, create a new random token, store in the cookie, and send that back to the browser. Again, in an encrypted form.
The result is that your cookie is secure (you are using 3DES?) and any attacker would have an extremely limited window of opportunity to even attempt a replay attack. If a token didn't pass muster, you could simply sound the alarm and take appropriate measures.
All that's needed server side is to keep track of the user and their current token. Which is usually a much smaller db hit than having to look up little things like the users name on each page load.
UPDATE 2
I've been trying to figure out whether this is better or worse than keeping the changing value stored in session. The conclusion I've come to is that storing a rotating value in session on the web server does absolutely nothing to prevent replay attacks and is therefore less secure than putting that value in a cookie.
Consider this scenario. Browser makes request. Server looks at the session id and pulls up the session objects, work is then performed, and the response is sent back to the browser. In the meantime, BlackHat Bob recorded the transaction.
Bob then sends the exact same request (including session id) to the server. At this point there is absolutely no way for the server to know that this is a request from an attacker. You can't use IP as those might change due to proxy use, you can't use browser fingerprinting as all of that information would have been recorded in the initial exchange. Also, given that sessions are usually good for at least 30 minutes and sometimes much longer, the attacker has a pretty good sized window to work in.
So, no matter what, to prevent replay you have to send a changing token to the browser after each request.
Now this leaves us with the question about whether to also store values such as the user id in an encrypted cookie or store it server side in a session variable. With session you have concerns such as higher memory and cpu utilization as well as potential issues with load balancing etc. With cookies you have some amount of data that is less than 4kb, and, properly done, in the 1kb or less range that gets added to each request. I guess it will boil down to whether you would rather add more / larger servers and internal networking equipment to handle the requests (session) or pay for a slightly larger internet pipe (cookie).
As you've stated, a good practice for storing any data in cookies is to encrypt the data. Encrypt before putting into the cookie, and decrypt after reading it.
In the example of storing a user identifier, choose something that's not likely to be used against your system. For the user id, use a guid rather than the likely incrementing integer that's the PK on the database table. The guid won't be easily changed to successfully guess another user during an attack on your system.
Once the user has been identified or authenticated, go ahead and store the user object, or key properties in Session.
In an ideal world with an ideal cipher this wouldn't be a problem. Unfortunately in the real world nothing is ideal, and there never will be an ideal cipher. Security is about solving these real world threats. Cryptographic systems are always vulnerable to attack, weather it be a trivial(brute force) attack or by a flaw in the primitive its self. Further more it is most likely that you will botch the implementation of the primitive, common mistakes include non-random or null IV, Key management, and incorrect block Cipher mode.
In short this is a gross misuse of cryptography. This problem is best sovled by avoiding it all together by using a session variable. This is why sessions exist, The whole point is to link a browser to state data stored on the server.
edit: Encrypting cookies has led to the ASP.NET oracle padding attack. This should have been avoided all together by using a Cryptographic Nonce. Like i said, this is a gross misuse of cryptography.
For your very specific scenario (user id), the short answer is NO!
For the long answer, imagine this hypothetical scenario:
You navigate to stackoverflow.com;
Fill your username/password and submit the form;
The server sends you a cookie containing your user ID, which is going to be used to identify you on the next requests;
Since your connection was NOT secure (HTTPS), a bad guy sniffed it, and captured the cookie.
The bad guy gains access to your account because the server didn't store, let's say, your IP address, and thus, can't distinguish between your machine and the bad guy's.
Still in this scenario, imagine the server stored your IP address, but you're on a corporate LAN, and your external IP is the same of another 100 machines. Imagine that someone that has access to one of these machines copied your cookie. You already got it, right? :-)
My advice is: put sensitive information on a HTTP session.
UPDATE: having a session implies a cookie (or at least an ugly URL), thus leading us back to the very same problem: it can be captured. The only way to avoid that is adding end-to-end encryption: HTTP+SSL = HTTPS.
And if someone says "oh, but cookies/sessions should be enough to discourage most people", check out Firesheep.
It's okay (not great, but not wrong) from a security standpoint. From a performance standpoint, however, it's something you want to avoid.
All cookies are transmitted from client to server on every request. Most users may have fast broadband connections these days, but those connections are asymetric — the upstream bandwidth used for transmitting cookie data is often still very limited. If you put too much information in your cookies, it can make your site appear sluggish, even if your web server is performing with capacity to spare. It can also push your bandwidth bill up. These are points that won't show up in your testing, which most likely happens all on your corporate network where upstream bandwidth from client to server is plentiful.
A better (general) approach is to just keep a separate token in the cookie that you use as a key to a database lookup for the information. Database calls are also relatively slow (compared to having the information already in memory or in the request), but primary key lookups like this aren't bad and it's still better then sending the data potentially a quarter of the way around the world on every request. This is better for security as well, because it keeps the data off the user's machine and off the wire as much as possible. This token should not be something like the userid from your question, but rather something more short-lived — a key used to index and hide away larger blocks of data, of which your userid is perhaps one part.
For your userID, which is likely only a single integer, as well as other small and important data, keep it in memory on the web server. Put it in the session.
The use you are looking at is the exact intended purpose of being able to store information in the Forms Auth Ticket.
No. It have been shown with Padding oracle attack that receiving encrypt data (CBC) can be dangerous because of the errors leakage.
I'm definitely not a crypto expert but I recently saw a demo where encrypted view-state was decrypt using this attack.
Encrypting the userid value in the cookie only prevents the user from knowing what the value is. It does not
prevent cookie replay (use SSL to
prevent an attacker from intercepting
a victim's cookie)
prevent tampering
(an attacker can still blindly flip
bits in the encoded cookie with a
chance that it will decode to a valid
userid, use an HMAC to prevent this)
completely prevent a user from getting the decrypted value (the user can brute force the value off line, use a strong encryption key to make success less probable)
Encrypting the cookie also introduces a key management problem. For example, when you rotate the encryption key you have to make sure "live" sessions with the old key won't immediately fail. You thought about managing the encryption key, right? What happens when admins leave? It's compromised? etc.
Does your architecture (load balancers, server distribution, ...) preclude using server-side session objects to track this information? If not, tie the userid to the session object and leave the "sensitive" data on the server -- the user only needs to have a session cookie.
A session object would probably be a lot easier and more secure for your stated concern.
To ensure proper auth cookie protection, you should make sure that you specify a secure encryption/hashing scheme (usually in the web.config) by setting the machineKey validation="SHA1" property (I use SHA1 but you can replace that with a different provider if desired). Then, make sure that your forms auth has the protection="All" attribute set so that the cookie is both hashed AND encrypted. Non-repudiation and data security, all in one :)
ASP.NET will handle encrypting/decrypting [EDIT: only the auth cookie!] the cookie for you, although for custom cookies you can use the FormsAuthentication.Encrypt(...) method, so just make sure that you're not sending the UserId via other cleartext means like the querystring.
HttpCookie c;
c.Secure = true;
Obviously this only works when transmitting via SSL, but this setting tells the browser not to send the cookie unless the connection is SSL, thus preventing interception via man-in-the-middle attacks. If you are not using a secure connection, the data in the cookie is totally visible to anyone passively sniffing the connection. This is, incidentally, not as unlikely as you'd think, considering the popularity of public wifi.
The first thing to address is whether the connections involved are secure. If they are not, assume the cookie or anything else between you and the client will be intercepted.
A cookie can be a liability once it is on the client machine. Review cookie theft, cross-site request forgery, confused deputy problem.
Cookies limitations: size, may be disabled and security risk(tampering). Of course if you encrypt cookie, there could be a performance hit. Session and Viewstate would be good alternative.
If you want it to be stored at client side, viewstate would be better. You can encrypt the string userid and store in viewstate. Session would be best option.
If your database calls are slow, consider caching
Viewstate