Let say my site is vulnerable by xss.
What happend then.
Javascript nowaday cannot get the cookie (HttpOnly is marked 'true')
Could the attacker do something specific on my site then?
Thanks.
You are saying that your website is vulnerable to XSS and it enabled HttpOnly flag.
If the victim's browser supports HttpOnly flag then the attacker can't get cookie of victim as it is not accessible by malicious script but what if the victim's browser does not support HttpOnly flag? In this case, the browser ignores the HttpOnly flag and creates normal accessible cookie, so the attacker can get cookie.
HttpOnly flag does not prevent execution of malicious script, so the attacker can do much more things.
Ex. Key logger, redirecting user to malicious sites, injecting fake login forms, etc.
Related
Wouldn't a malicious site be able to read the cookie using xss cookie stealing and put it in the header of an ajax request?
Of course, if the site is vulnerable to xss, it's also vulnerable to csrf, but that's the smaller issue then.
If there is no xss though, the attacker has no way to read the token due to the same origin policy.
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.
Django allows you to specify that the session expires at browser close (with some caveats for Chrome). Why doesn't it do that for the CSRF cookie?
I ask because it seems to me that the CSRF token is vulnerable to being leaked (e.g., by mistakenly putting it in a post to an external site), and this would be a mitigation for that. Am I misunderstanding something?
I'll repost my answer from the developer's list that Carl linked, so that stackoverflow has it too:
If the cookie were set to expire at browser close, it would cause CSRF
errors for users who closed a browser (or bookmarked a page with a
form on it) and then loaded that page from a browser cache and
submitted the form. I'm ambivalent about whether this use case is
worth supporting (it may be important on mobile devices, for example),
but I don't believe that setting the cookie to expire on browser close
provides much security benefit to an otherwise properly configured
site (HTTPS, HSTS, etc.).
Django's CSRF implementation differs[1] from many others which store
CSRF information alongside session information on the server. The CSRF
mechanism functions by matching a token provided in a form with a
token provided as a cookie in the browser. If you set the cookie to
'zzz', it will still function perfectly well. The security comes from
the fact that an attacker cannot set the cookie, not that it happens
to contain any specific cryptographic value.
If the concern is that an attacker could access a user's physical
computer between sessions and steal a CSRF token, setting it to expire
at browser close would not prevent an attacker from inserting a cookie
of known value that would be used during the next session. I'm not
convinced we can secure the tokens of a user whose computer has been
physically accessed by an attacker.
Still, if it can be convincingly demonstrated that setting the cookie
to expire at browser close would not break existing use cases (mobile
browsers are my chief concern) I'd be open to changing the default
behavior. We generally consider it a bug if any non-malicious user
can, through innocent behavior, trigger the CSRF warning.
[1] Django's CSRF implementation usually sets off all kinds of false
alarms in most pen-tester tools, since it doesn't work exactly the
same way other implementations do, and isn't tied to the session
cookie.