When a user logs out from a session-based site should their corresponding anti csrf token (stored in the session) be refreshed?
If the token should be refreshed then why specifically? Which possible vulnerabilities could bring not refreshing of the anti CSRF token?
The official OWASP advice is that yes, the corresponding Anti-CSRF token should be refreshed, though there is actually little security benefit in doing so:
Note that this value should be unique for every individual session. This guarantees that every form/request is tied to the authenticated user and, therefore, protected from CSRF. [...] The standard frequency of token generation is per-session, so make sure your sessions have a reasonable/configurable time-out. It is possible to issue new tokens on a per-request basis. However, the added protection may be insignificant, if this approach even fits your application.
However, the linked StackExchange question's accepted answer does have a security benefit if applied to anywhere with a principal change in the session stage (this is usually only on the login / log out) screen itself. This prevents a session fixation attack, where the attacker hijack's the victim's active session:
This is done via cookie theft, client-side scripting, abusing the <meta> tag or through the HTTP headers. Resetting the anti-CSRF token during the login flow prevents this. However, note that a secondary token should only be applied at such points, as that there is a usability cost in terms of problems in using the back button and browsing in multiple tabs.
Related
We have a log-in form in ASP.Net Webforms. and when user logs in we save the user id to session state.
Session["CurrentUserId"] = user.Id;
So this is how we know a user is logged in.
if(Session["CurrentUserId"] == null) Redirect("Login.aspx");
This is all we use Session for. I am storing session in DynamoDB because we have many load balanced servers. But sometimes DynamoDB gets overloaded or gives errors. So I trying to get rid of session state to avoid these errors and to simplify a login process.
So what alternatives are there? How do modern websites log people in and remember they are logged in, and timeout after x minutes?
Is there a way to use a secure cookie to just do it? And how would you expire it if user doesnt do anything for 20 minutes? It has to work over a collection of web servers.
Storing user ID in session is not necessarily bad but has to be combined with other things in order to secure the site against things like session fixation attack and CSRF (also known as "session riding"). It is also problematic in a web farm if you are using in-proc session state.
In ASP.NET web forms, the standard way to authenticate is to use forms authentication, which places an encrypted cookie ("authentication ticket") on the browser. You may also want to put the user ID somewhere in session and compare it to the authentication ticket in order to ensure they match.
if you using the standard FBA login providers?
You can get user logon ID with this:
Membership.GetUser.ProviderUserKey
And you can get user email with this:
Membership.GetUser.Email
So, the user logon id can be fetched with above.
As for session() being a bottle neck?
Well, it not all that bad - you not "updating" the session() value by doing this, so it certainly does not have to be written back each time (for a post) and also it means that a lock on session() during post backs etc. should not occur.
I would however consider one of the above two approaches, since then session() re-sets or anything else would not matter to get the user ID, or email.
As noted, this much depends on what security and authentication provider you are using here.
Part of our GDPR Requirement is to disable the GA tracking, we already achieved this by setting the window property to "window['ga-disable-UA-XXXXX-Y'] = true;". But aside from this, we also wanted to delete the set cookies (i.e. " _ga", "_gid"). Will expiring the said cookie suffice for the deletion of those cookies, or is there a better way to approach this?
Or if this cookies won't be deleted, what are they for if the tracking is disabled.
These are first-party cookie set via Javascript, so expiring them will work just fine.
what are they for if the tracking is disabled.
I would venture that Google did not put a lot of thought into this - after all their cookie solution precedes the GDPR and any widespread notion of data protection. They just remain there because that is the default behaviour for cookies. The obvious downside is that if the opt-out is revoked (either on purpose or by accident) the client id from the cookie might be reused and the tracking data would be connected to existing data. So deleting the cookie is a really good idea. If you want to be particularly thorough, you could pick up the client id of a user who opts out and sent a request to the User Deletion API. This will not remove aggregated data, but will remove PII (namely client id and user id) to anonymize the data.
Can't we just store in the session if the user is logged in or not and get rid of the .ASPXAUTH?
ASP.Net_SessionId is a cookie which is used to identify the users session on the server. The session being an area on the server which can be used to store data in between http requests.
For example, the controller action may perform:
Session["FirstName"] = model.FirstName;
Then, in a subsequent action the first name can be retrieved from the session:
var firstName = Session["FirstName"];
The ASP.Net_SessionId identifies the session for that users request. A different user will submit a different cookie and thus Session["FirstName"] will hold a different value for that different user.
ASPXAUTH is a cookie to identify if the user is authenticated (that is, has their identity been verified). For example, a controller action may determine if the user has provided the correct login credentials and if so issue a authentication cookie using:
FormsAuthentication.SetAuthCookie(username, false);
Then later you can check if the user is authorised to perform an action by using the [Authorize] attribute which checks for the presence of the ASPXAUTH cookie.
So in summary, the cookies are there for 2 different purposes. One to determine the users session state and one to determine if the user is authenticated.
To complete the answer to your question, yes, you could get rid of the ASPXAUTH cookie and just use session to identify the user (I have seen this done in older classic asp applications) but I wouldn't recommend it. It is much better to have a cleaner separation of concerns and use the appropriate method where necessary. The session and authentication will have their own time-out values set. By using the session for authentication you will only have the single time-out. I'm not sure though if there are any security implications in just using session for authentication, but still I would keep them separate.
.NET issues an entirely different cookie, named ASP.NET_SessionId, to track session state.
The ASPXAUTH cookie is used to determine if a user is authenticated.
So these are 2 different concept i.e. Session State Management and Authentication Management using Form Authentication.
If you use Session to Authenticate and forget Form Authentication you will get rid of .ASPXAUTH
Both are required , using either resulting in the following vulnerability:
*ASP.NET_SessionId Alone: Session Fixation
*Forms Authentication Cookie Alone: Can’t Terminate Authentication Token on the Server
Also, you need to ensure they coupled together properly.Otherwise, the configuration also pose risk:
*Loosely Coupled ASP.NET_SessionID and Forms Authentication Cookies: Still Vulnerable
ref:
http://blog.securityps.com/2013/06/session-fixation-forms-authentication.html
Session state and authentication have nothing to do with each other. You can use one without the other.
I've got a site that uses Forms Authentication (with a custom membership provider, but that's not important right now). In the secure part of the website, the customer can purchase goods and pay for them via WorldPay.
Once they come back from WorldPay, if there's a link back into the secure part of the website, can I reasonably expect the forms auth ticket (stored in a session cookie) to have survived (timeout notwithstanding)?
The ticket is set thus:
FormsAuthentication.SetAuthCookie(username, false);
FormsAuthentication.RedirectFromLoginPage(username, false);
The work is part of a redevelopment, and I would rather have a quick "yes/no/maybe" answer before writing lots of code that may not be required - we do not want to have the user log back into the secure part of the site so we recreate their login based on the information returned from WorldPay. Obviously, if the user is going to be remembered, I don't have to write that code - I'm quite lazy ;-)
Thank you for any suggestions,
Mike K.
Forms Authentication uses a cookie.
A session cookie (which is stored in memory) lives as long as the session does not timeout and you do not close the browser.
You may also be able to set the life time of the cookie, then it will be written to disk, and available to all browser instances. In this case you will also be logged out if the session timesout on the server.
If you're calling
FormsAuthentication.SetAuthCookie(username, false);
then the cookie will survive for as long as the value specified in your web.config or until the user logs-out.
If you redirect them to a 3rd-party site during the course of their visit to your site, this cookie will remain. The 3rd-party site won't have access to your auth cookie.
In short, they will still be logged-in on your site when WorldPay redirects them back.
Even shorter: yes.
Hope this helps.
The other answers here seem to point out to this being a non-issue, but I thought I'd just add that if you're posting data to their gateway, any variables which start with MC_ will be returned to you on the other side. I'm not sure if this helps or not!
I think, in almost all cases user preference data may be stored in a cookie with (almost) equally good results as when the User Profile API is used. Disadvantages of using cookies (for authenticated users) seem to be that a cookie can be deleted or time-out, in which case the user preference data will be lost. For anonymous users, if the preferences data needs to be persisted across sessions then a cookie will have to be used even when User Profiles are used.
So what are some of the biggest advantages/disadvanges of using either User Profiles or cookies for storing user preferences?
One of the benefits of registering on a site is that it remembers my preferences - if you're storing that information in a cookie on my machine instead of on your server then when I log into your site from another computer, I've got to set all my preferences up again - from a usability point of view, this is fairly bad.
For an anonymous user, storing the prefs in a cookie may seem fairly sensible - you don't know who they are, or whether they will comeback, and as you state, you can't work out from one session to the next who they are - however you'd probably be better off storing some sort of token in the cookie and mapping that to a preferences store on the server.
Also, I've noticed different browsers have different implementations for cookies - for example IE can now receive 50 cookies from one domain (up from the original 20), but it is still limited to a total of 4096 bytes for the entire cookie collection (and previous) - other browsers will support 4KB per cookie, rather than per domain.
Another disadvantage to holding all the preference data in cookies is that all of that data will have to be sent in every request from the client and in any response from the server whenever a change to the data is made. Whilst this may seem like a minor point in the age of broadband it is still an additional overhead. Using the Profiles API meands that the data is held at the server and only a session identification cookie needs to be sent by the browser.
Also, as you stated, for anonymous users if cookies are deleted then the user preferences held in the Profiles DB will no longer be accessible. However this will not be the case with registered users of your website. If they remove their cookies the server will still be able to retrieve their user preferences the next time they log in.
Cookies are limited in maximum length and they are using an implementation beyond of your control (after all, they are a feature of your visitors browser). Personally, I dislike relying on unknown third-party implementations I don't have any control over and if I have to, I'm trying to use it in the simplest way possible.
So from where I'm coming from, I would always store the user data on the server and just pass around a cookie pointing to that information.
Aside of not trusting the browser with a potentially big chunk of data (which may be lost, incorrectly stored or not stored at all depending on not only the browser but also, say, some antivirus application or whatever), this has various other advantages:
You are hiding your implementation from the user: If you store the data in the cookie, it's visible for anybody and can be analyzed or modified at will. This can even lead to users changing cookies to there liking and thus force you into keeping stuff around you probably want to get rid of just because some users are depending on your particular implementation at any time.
As cookies are stored in plain text, on shared machines, everybody can no longer easily see all the settings the previous user made, nor change them at will.
But the most important point remains the disconnect from not-quite-working browser implementations (just storing small tokens is the common, tested use-case)
Don't forget that one of the biggest disadvantages of using cookies is that they can be copied, so its dangerous to store authentication info on them.
I'm not familiar with User Profile API but I'm guessing it stores the information on the server(?). If thats the case then you could have a problem if you have to many users.
Overall maybe the best solution is to use User Profile if it guarantees the persistence of the information.
Keep in mind that its possible to write a ProfileProvider that persists user data in a cookie, so you can have the best of both worlds if you determine the state you want to persist is appropriate for cookies (size, security, etc).
Actually, you do not need to persist preference data in cookies for anonymous users when using the ASP.NET Profile Provider. Simply store the current UserID (which is some horrible looking session-related string) in a cookie. This becomes the previous UserID on subsequent visits, and then you can just grab the old Profile information and migrate it to the current Profile, or even authenticate them as that old anonymous Profile.