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?
Related
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?
Assume you have XSS attack on your site.
Hacker can make any request with cookies.
So, what's point to hide this value from client?
In an XSS attack, "hackers can make any request with cookies", but NOT all cookies. If one cookie is HttpOnly, it cannot be accessed by client JavaScript, which means hackers cannot read the cookie value and send it to his own server, not even know whether this cookie exist.
Normally, when HttpOnly is used to protect cookie, the cookie's Domain is also set (if Domain is missing in HTTP response's Set-Cookie header, browser will set the cookie's domain as that HTTP connection's hostname). Hackers can trigger HTTP request and make browser put HttpOnly cookie in the request, but it would be restricted by cookie's Domain -- the cookie is sent only when its Domain match the HTTP request. Thus, HttpOnly cookie with website's Domain is safe, it will not be leaked to XSS attackers.
Well Http Only cookies can only be accessed by the server. They cannot be accessed from JavaScript. Which means it will be more difficult for hackers to use these cookies for their own use.
Http Only cookies reduces the possibility of Cross Site Scripting attacks on websites.
See this link for more information: https://www.owasp.org/index.php/HttpOnly
Let's say there is a website, which after authentication sets a browser cookie. This cookie is sufficient to authenticate a user, so if I were to transfer it to another computer's browser, the website would consider this browser authenticated.
The website uses HTTPS for all communications, except for the following. Whenever a user sends a request to http://domain.tld/ and gets redirected, the sensetive cookie gets sent in the first request, using HTTP (non-secure).
It seems weird to use HTTPS after sending the key using plain text. Is this a security concern, or am I not understanding this correctly?
Sensitive cookies needs to be protected by Secure attribute. Otherwise, it's easy to be intercepted by active network attacker. According to RFC6265:
The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS)
In this way, sensitive authentication cookie won't be sent in non-HTTPS requests, thus keep it confidential. Example Set-Cookie statement is:
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
However, please note Secure attribute only protect cookie's confidentiality, not integrity:
Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity.
Seeing as using session and cookies are so unsafe, is it possible to securely use just servlet context variables and hiddenform fields, url rewriting to implement same things that session does?
But will it be equally secure and convenient? Why is this method not used?
I am just trying to avoid cookies! Plus, if I save user details in servlet context variables , will it not work same as cookies, but just in server side?
Is that the reason that cookies are ultimately used,That they are client side?
No, Cookies are different from Servlet Context. ServletContext is singleton per application. Not per user.You should avoid using ServletContext for user specific information because you also need to take care of User Lifecycle such as deleting the User info when he is idle.
If you do not want to use Cookie, the alternatives for session tracking are:
URL Rewirting
Hidden Form Fields
But you can make Cookies Secured with the help of following properties:
httponly: On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript).
secured: A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server.
Domain : They tell the browser that cookies should only be sent back to the server for the given domain.
Path: They tell the browser that cookies should only be sent back to the server for the given path.
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.