How can we prevent session hijacking in an asp.net mvc application? The following steps were performed by the testers to hijack the session - OWASP A2.
Login as a low-privilege user.
Login as a admin user. (in a separate browser - from the same machine)
Copied the ASP.Net Session ID of the admin user
Replaced the ASP.Net Session ID of the low-prev user with the that of the admin user.
By doing the above steps, the low-prev user was able to access the admin areas of the app.
The application is hosted with SSL (https).
Cookies have been set to Secure and HttpOnly.
Cookies are set to expire on Session_End and Signout.
Still, I am able to reproduce the scenario explained above using Fiddler. Could someone please help on ways to arrest the above issue.
Thanks.
I would argue that if someone were able to still the cookie, then she should be able to log in. The mitigation should be using short-lived cookies for sensitive resources, and require the user to re-enter her credentials before doing any sensitive data. For example, setting a password, granting permissions etc. Also, you should make it hard to still a cookie - which seems like you already did. Worth also adding Same-Site), and keeping your site secure.
Related
Is there a good way to implement 2-Factor authentication on an MVC web application that is using Windows Authentication?
I see examples that show how to implement 2-Factor on a Forms-based MVC app, but couldn't find one for a Windows-based MVC app.
Any help would be appreciated!
2-factor doesn't make sense in the context of Windows Auth. The application is authorized by the user's domain account. The security aspect lies on the domain-end, not the application-end.
However, if you're dead set on doing this, you effectively can't use Windows Auth. That sounds a little contradictory, I know. How you would have to handle this is use application-based authentication, such as Identity, so the web application itself would hold the user accounts. Then, you can authenticate via connecting to LDAP directly. You'll have to set all this up yourself, in other words; no easy set it and forget like you get with Windows Auth. With something like Identity, you can implement 2-factor auth, so you're golden there. However, instead of validating the password via your application's database and users, you authenticate via LDAP.
This is actually pretty common among enterprise-class applications utilizing AD. Typically, they'll have a script that you can run, as a consumer of the app, to periodically update the application's user database from AD, so all the same users with the same details exist in both places, except for the password, which remains solely with AD. This way, the application can associate its own data with its copy of the user, but authentication and authorization still happens at the AD level.
Imagine the following scenario.
User visits a site A (ASP.NET), authenticates using ADFS and gets a set of claims . At some point, they need to register for an additional service so they are redirected to a provisioning site B (ASP.NET) (also using ADFS – so SSO) where they register by entering their relevant details and are redirected back to A.
However, part of the provisioning process added attributes to a repository (normally AD) and we would like those attributes to form part of their claim set.
To do this they have re-authenticate? Is the best way to do this by forcing a federated logout? Would this be done by site A or site B?
If they are internal users using WIA, they would be logged in “behind the scenes” and the whole process would be transparent.
What if they are external users using FBA? Wouldn’t they have to log-in again? Given that this is not a very satisfactory user experience, is there a way around this?
There are some references out there that talk about writing a signed token as a cookie to the client browser and then the STS later authenticating the SSO token from the cookie. How would you do this with ADFS?
Have a look at the blog post I wrote about a similar scenario:
Refreshing Claims in a WIF Claims-Aware Application
In this case, the user is logged out locally but then redirected back to ADFS where they are "signed back in" since their ADFS cookie is still valid. This little hop is mostly transparent to the user and will update the claims.
I need some clarity around how cookie-based sessions work. I'm building an app where I authenticate a user and upon successful authentication, I stick a GUID identifying his user into the session, which in turn gets persisted as a cookie. Now when a user logs in, whats to prevent someone from sniffing traffic, stealing the contents of the user's cookie and creating a cookie on their own end and login to my site as that person? Another scenario could be if I had physical access to a machine where the person was logged in, I could also steal the contents of the cookie and impersonate as the user.
Whats to prevent someone from sniffing traffic, stealing the contents of the user's cookie and creating a cookie on their own end and login to my site as that person?
SSL - the only way to stop that is to run your web site on HTTPS.
I had physical access to a machine where the person was logged in
Once you have physical access to a machine all your security methods are moot. You can do nothing about this.
I think you have two questions here. In regard to the second you should not be storing a session key in a cookie and have it stick around longer than the session, set the timeout on the cookie to expire quickly and invalidate the session on the server as soon as reasonable and the cookie becomes useless. If you are flowing important information over the wire use https.
I have a Spring MVC web application, there are no secure areas so all users can see all pages however i do have a Facebook log, using spring social, in and i do identify each user by session id. the scenario is that a user can see pages as a guest where the application identify him (or her) by the session id, when the user log in with his (or hers) Facebook account, a record is save for the user with the corresponding Facebook data.
the next time the user visit the application i want to be able to identify him.
i thought about using spring security remember me feature (and an infrastructure for maybe future use).
so my question is, is spring security the right solution for me? and if so is it possible to set authentication by session id?
Spring security is good for authenticating users. If you were just to authenticate by session id, there is the possibility that bogus users could access user info by spoofing their session data.
Excuse the extremely newbie question...
Once I have verified the users login credentials, Where should I store the state for whether a user is logged in or not?
Once you have validated that your user is OK according to the backend, you can make ASP.NET set an authentication cookie for the user in the response by doing a FormsAuthentication.SetAuthCookie(username, persistent).
From then on, ASP.NET will decrypt that cookie in requests and extract the username from it, giving you access to it via HttpContext.Current.User.
To me, it sound like this is what you're looking for.
You don't normally need to store this state yourself. If you are using one of ASP.NET's built in authentication mechanisms (e.g. Form Auth) you can simply check: Request.IsAuthenticated