is there a way to set a httponly cookie with blazor server side?
Setting a non httponly one with js-interop is not a problem but in case of httponly it is obviously not possible this way.
Thanks in advance
Holger
It seems that HttpOnly cookies are not accepted with Blazor Server as they are with Blazor WASM.
One of the reasons I was interested in using HttpOnly cookies with Blazor Server was for passing authentication tokens from a Blazor App to some back-end in a secure fashion.
Fortunately, there is a secure alternative to HttpOnly cookies in Blazor Server that may assist you. This is called ASP.NET Core Protected Browser Storage. You can store what ever you want in local storage or session storage, but it will be encrypted so that only the server can decrypt and read the stored details. This reduces the potential risk of tampering with stored data. While this is technically different to HttpOnly cookies, it can be used as a solution to solve similar problems.
You can read more about it here: ASP.NET Core Protected Browser Storage
Related
I am using django to create a python backend and am storing the user's access token and refresh token in httponly cookies so I can authenticate requests to my backend.
1) Is this the right way to do this?
2) I know that httponly prevents seeing the cookie using 'document.cookie', but you can still see the cookie by analyzing the network tab in Chrome Dev Tools. Is this fine because only the user can see it (not other people)? Or is this still bad?
I can't answer #1 authoritatively but it sounds fine to me. For #2, httponly is there to protect the cookie from being scraped by malicious code, not to keep the user from being able to find it in the developer tools. Even if it wasn't visible in the Network tab, it would be visible under Application (or Storage in Firefox). This makes sense, because the user should always be able to see (and delete) individual cookies, regardless of how the server defined them.
In our application, we use J2EE session variables for session management. We recently migrated from ColdFusion 9 to ColdFusion 2018. After migration, the logout functionality is not working. What we found is that, in ColdFusion 2018, the cookie JSESSIONID is not getting cleared from the browser because the HttpOnly flag has been set to true in the browser.
We tried to disable this HttpOnly flag in the browser in following ways,
By disabling HttpOnly flag and Global Script Protection in CF admin.
By modifying the jvm.config via CF admin by adding "-Dcoldfusion.sessioncookie.httponly=false".
But this way the HttpOnly flag is still showing as enabled in the browser. Because of this, the client-side script is not able to clear the cookie JSESSIONID and hence logout functionality is not working.
Is there any way, in CF2018, to disable the HttpOnly flag in the browser for the cookie JSESSIONID?.
Note:
In CF9, the HttpOnly flag is disabled in the browser for the cookie JSESSIONID.
We use the CF2018 enterprise edition (Trial Version, not yet expired).
Restarted CF services after updating the settings in CF admin.
You'll likely have to refactor your application to address a number of OWASP vulnerabilities that could not be handled by CF 9 out of the box. Depending on your audience, you should get a 3rd party to perform a security penetration test against your code base.
You're going to need to refactor your log out process. You shouldn't disable httpOnly on the jsessionid cookie, it's a prevention against Cross-Site Scripting attacks.
https://www.owasp.org/index.php/HttpOnly
According to the Microsoft Developer Network, HttpOnly is an
additional flag included in a Set-Cookie HTTP response header. Using
the HttpOnly flag when generating a cookie helps mitigate the risk of
client side script accessing the protected cookie (if the browser
supports it).
https://learn.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN
When using JEE session IDs, you need to add this to part of your logout process:
<cfset getPageContext().getSession().invalidate()>
Then redirect to another page like your login screen. This will delete the jsessionid cookie and actually invalidate the JEE session on the server.
I understood webstorage is vulnerable to xss
And Cookie to CSRF also makes sense
What makes me puzzled is that it seems like implicitly said that cookie is not vulnerable to xss, but isn't it also vulnerable to xss?
If I can run a script on other's browser, I think I might be able to just send request to server & get important data cause browser automatically attach cookies & I dont' need to do anything to get authenticated.
If a cookie is set with the httpOnly flag, it cannot be accessed from Javascript (injected js cannot read or write such cookies), so it is not possible to steal the cookie value if it's httpOnly. This is very relevant for a session cookie. In this case, this cookie is not affected by XSS. Note that this is solely because of the httpOnly flag - cookies without httpOnly are affected by XSS, because they are accessible to Javascript.
Any cookie (regardless of flags*) will still be sent with any request to the server it was received from, but that is the realm of csrf, actually, it is the fundamental problem in csrf. If anybody (from any website) makes a request to a server, any cookie for that server will be sent, and the attacker can exploit csrf if there is no protection. That's why you need protection against csrf if you have cookie-based authentication.
Also note that if the page is vulnerable to XSS, than any csrf protection is useless, because xss can be used to read the token, wherever it is stored.
*Sidenote: the new SameSite cookie flag changes this, but that is only supported by Chrome.
I'm using the Cookie Middleware in ASP.NET Core for session cookies. The session cookie data is encrypted by the framework using the Data Protection API.
Just wanted to understand in detail what the level of protection is from this process. These are my current assumptions:
The cookie data cannot be viewed in transit or at rest in the browser and is tamper-proof
The cookie data can be replayed if sniffed over HTTP
The cookie data cannot be replayed if issued and sent only via HTTPS
If any of these assumptions are wrong or need more detail then I'd appreciate an answer.
Your assumptions are right: although authentication cookies are marked as HttpOnly by default, nothing prevents an attacker from stealing a cookie from browser's container and using it as-is to make malicious requests if he manages to install a malware on victim's machine.
In the future, ASP.NET Core will support a feature called "TLS token binding" that will make stealing authentication cookies much harder.
When supported by both the server and the user agent, this feature allows the server to bind sensitive data like authentication cookies or bearer tokens with a secret value only known by the original client (i.e by the browser).
In ASP.NET Core, this feature will be implemented at the cryptographic level: the secret transmitted by the browser will be used to derive the encryption/validation keys used by Data Protection to protect and unprotect the authentication cookies, so that no one will be able to use a stolen cookie without also sending the corresponding token.
I have a cookie that is being set by Microsoft ISA. I want to check that the cookie exists from ColdFusion, but the cookie isn't listed in the cookie scope. The page I'm trying to read the cookie value from is using HTTPS. Why can't I read the cookie? All the non-secure cookies are listed in the cookie scope.
If the domain value of the cookie was set by another domain then it can't be read by your web application.
It would be a security breach if www.attackerwebsite.com could read session cookies from www.yourbank.com.
I think I've found the problem. The cookie is created by the ISA server as httpOnly. Does that mean the only way to access the cookie is from the server it was created on?
The definitive answer: the ISA server sits between the client and the web server, and it grabs the cookie and doesn't let go. I can access the cookie through ColdFusion from any machine on the domain that is not behind the ISA server. So the solution I came up with was to get the cookie value through an JSONP AJAX call to another machine in the domain.