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.
Related
I want to know which user is logged in currently into the ADFS.
I am using Claims Provider for ADFS and through that, I am logging into ADFS. Now I want to see in ADFS that this particular user is currently logged in. Basically I want to see the user details of logged in user in ADFS
There is no as such session monitoring console on ADFS, instead there are events generated for every successfull authentication that contains claims.
Also, if you want to check the entire header based interaction, please enable security logs.
Also, enabling security logs is not recommended for production environment as it creates enormously large count of events for every authentication request ADFS receives.
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.
I am trying to convert a Drupal 8 site to a progressive web app. I have cached all pages visited by a user using service worker. Is it possible to cache user login so that the user can start using the web app from login page when offline?
Whichever way you implement it, there is always going to be a security risk.
Having said that, similarly to a native application, while you cannot cache the login service for obvious security reasons, you could keep the user's logged in. This means that if they are not logged in, they are unable to login, but if they have already logged in previously while connected, then you could keep them logged in.
If the application is working offline and we require authentication then the risks are that someone gets a hold of the device. Since there is no traffic over the network, then that minimizes the attack surface and there isn't the need to worry about MitM attacks or someone getting a hold of the authentication cookie by sniffing.
I think it would help to understand your exact use for authentication while offline. If we are talking about a shipping cart (or different user journey) i would suggest storing some form of encrypted token (based on the user ID + salt) that would be used to recognize the user. These would be added upon successful login while connected to the internet and used to distinguish which user is currently accessing the site.
If you require authentication to gain access to some confidential data, then I would recommend that you require a connection to view that data so that confidential data is never stored on the device. If it is stored locally, then there is a security risk irrelevant of the authentication you have in place.
If I just store the provider and uid in a cookie is it secure enough? Or should I encrypt one or both of them? Should I augment provider and uid with a secure token?
Are there any other considerations that I should take into account?
You can use a signed cookie. These are cryptographically signed making it impossible to alter their data without invalidating them. This kind of cookie is typically used to store Rails session id/content.
Keep in mind that these cookies can still be decoded (it's just base64), but it shouldn't be a problem as provider and uid don't need to be kept secret.
If you don't want the cookie's content to be readable, you can use an encrypted cookie.
You can read more about the different types of cookies proposed by Rails here in the ActionDispatch::Cookies documentation
You say you can sign a user into your website when she visits if you've stored the provider and uid values you get from omniauth in a cookie. The problem with this is that it's not reliable as a means of authentication. Do you want to actually authenticate the user of your website? Then you need much more than just data that will allow you retrieve a unique user id from your database, as you recognize. You need some sort of guarantee that the user id you're associating with the session represents the user you think it does.
"Remember me" essentially relies on the assumption that the user-agent (e.g., the browser) is used only by the user who you originally authenticated. Can you or your user be sure of that? (This is why websites require you to opt-in to "remember me" - when you check that box you're promising that nobody who doesn't have authorized access to your user account has access to your user-agent.) It's not hard to see that this is pretty much essentially insecure. You can sign or encrypt your cookies, but unless you know that the user-agent is only accessible by the user you authenticated, you don't know that the user who visits your website the next time is authorized to access the original user's account.
If you're using omniauth, then you're essentially relying on some 3rd party to authenticate your users for you, either as a Relying Party as defined in by the OpenID Connect specification, or using some kind of non-standard authentication scheme on top of OAuth 1 or 2. What you're essentially asking is "Can I securely authenticate a user via a 3rd party just once and then safely assume that any time the same user-agent visits my site, it's the same user?"
The answer is NO.
But admittedly, there's a trade-off here between security and usability, and some people might think the risks (if the user's account isn't that sensitive) are outweighed by the usability benefits. However, if you're relying on a 3rd-party provider to authenticate your users, then the usability difference is almost literally zero. If the user has already authorized your application on google, facebook, or whatever other provider, and if they have a current session with that provider, then when they click the "log in with [provider]" link on your site, they can be logged in with no additional interaction from the user. No passwords or usernames to remember and enter, nothing. So the worst that can happen is they have to log in to google, facebook, or whatever, if they aren't already.
What's more, if you do this, you get more assurance that the user is who they say they are. Each time your user "signs in" with an OpenID provider, you get an id token that says who they are, that they were authenticated by by the provider, when that authentication event took place, etc. So you're not just assuming they're the user with a particular provider uid, you're trusting the provider's assertion that they are. Of course, even this is not perfectly secure, because it's possible the user's provider account is compromised, or in theory the provider could be untrustworthy. But it's still an improvement over "remember me."
TL;DR "Remember me" is inherently not secure, and offers no meaningful usability improvement over requiring sign in via an OpenID provider on each visit. Don't do it.
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.