I just can't figure out how to require SSL for antiforgery cookies stored in clients browsers. The actual authentication cookie is marked as secure and httponly as expected.
Where do you define this? In cookie options? In antiforgery options? Is it even necessary or reasonable?
Thanks for any advice.
Related
Okay, so the idea was to use a HttpOnly cookie to store the JWT in the browser to authenticate and persist session.
Backend: http://<project>.<company>.test/api (internal test)
The problem is that the browser won't send the cookie to the backend using fetch (yes, I'm using the credentials: 'include' option).
I'm testing the frontend on localhost
If I use HttpOnly, the cookie cannot be accessed from within the client-side javascript code - this is good
I can't set it to Secure, because the cookie has to be sent over HTTPS
I can't set the Domain property, because "Setting cookies for another domain is not possible."
I'd have to set the SameSite option to None, but if the cookie’s attribute SameSite is None the cookie has to be set with flag Secure - so we're right back at the Secure "problem"
It sounded good and everywhere they say that storing the jwt in a http-only cookie is the safest bet, but I can't use it in a local test, nor in our internal test. What am I missing? Any tips or alternatives?
I have an application that uses 3rd party cookie for multidomain authentication, setting the cookie parameters: domain, httponly, secure, samesite none and expires, to work with the context
server domain: xyz.com
client domain: abc.com and qwe.com
In this way, the same authentication cookie works for both client domains. However, browsers have a privacy-focused initiative to eliminate 3rd party cookies. Safari and Brave have already implemented it. Chrome will roll out in 2022.
This new policy is breaking the way I add cookies with multidomain.
I've already researched how to solve this, without stopping using cookies, but I couldn't find a way, other than using the header authorization with the token stored in the browser's Storage. In this case, it is not a 100% safe and attackable solution.
Does anyone have any direction on how I should handle authentication with multidomain without relying on storing the token in storage?
I have a question connected with security.
Is it possible to implement authentication and authorization trough session variables without using forms authentication and forms authentication cookie stored in browser?
How is session id being sent in consecutive requests? Is it stored also in a cookie?
What are the drawbacks of using session instead of forms authentication for authentication?
Thank you
Using user session for authentication is a very bad idea from the security perspective. User session is maintained by a cookie (ASP.NET_SessionId), just like the authentication session (ASPXAUTH). However, ASP.NET has a lot of security safeguards built into the authentication session cookie management, such as encryption, validation, prevention of tampering, etc. None of these measures exist for the user session cookie, which makes it easy to break the site security.
There is absolutely no reason not to use forms authentication, it is actually more difficult to switch to using the session for authentication, because you have to custom code to support it.
Well, you got two questions.
Is it possible to implement authentication and authorization trough session variables without using forms authentication and forms authentication cookie stored in browser?
yes it's possible but we're not supposed to reinvent the wheel especially it is related to security. It's strongly recommended to use form authentication when possible unless you have strongly valid reasons.
How is session id being sent in consecutive requests? Is it stored also in a cookie? What are the drawbacks of using session instead of forms authentication for authentication?
to see the cookie.
step1: Create a new ASP.NET MVC project using internet template.
step2: Start it and create a new user and login.
step3: Open developer tools check the cookie section you can see two cookies
__RequestVerificationToken
.ASPXAUTH
.ASPXAUTH is the cookie that FormAuthentication consume to do the authentication. For all following requests to the server, the server will check this cookie to authenticate user.
You can specify "Remember me" when you login which will changes the life span of this cookie, if you don't tick it the life span is tied up to current session, if you tick it depends on the settings on the server side.
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
I have the impression that ASP.NET Membership encrypts its cookie by default.
Is it relatively safe to assume that ASP.NET Membership protects against session hijacking (ala Firesheep)?
ASP.NET membership uses the exact same mechanism as any other site and is absolutely vulnerable to Firesheep attack. The cookie itself cannot be encrypted in a way that keeps it from being hijacked. All communication with the server must be encrypted to protect from session hijacking, using SSL or WEP wireless encryption.
The cookie is encrypted, but that doesn't stop someone who obtains the cookie itself from acting as you.
Only if the entire session is on HTTPS.
Firesheep doesn't care about the contents of the cookie; all it needs to do is duplicate the cookie in the attacker's browser.
As long as the cookie is sent in clear text (as opposed to HTTPS or WPA), you're still vulnerable.