-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X-XSS-Protection: header should be disabled by default #230
Comments
Commenting to follow this issue and possibly offer my help with the potential PR if approved. |
Is there a place I can go to learn more about the security issues caused by |
I don't think I understand the problem with setting this header in "block" mode. Could you elaborate?
|
Source: First link provided by @ThunderSon (https://portswigger.net/daily-swig/google-deprecates-xss-auditor-for-chrome) |
The major attack vector against the block method is the xsleaks attack. Google's services are setting the header to |
Does the video explain the XS-Leak attack? If not, none of the resources I've looked at describe it in detail. It's useful to have the high-level explanation (i.e., "[tricking] Chrome into believing that non-malicious script was attempting to execute XSS"), but I would also like to see a proof of concept. If it's sensitive, feel free to email me@evanhahn.com or send me a chat message on Keybase (no account needed). |
XS-Search came as a research study after XS-Leak attacks were identified. The video I provided you with is a PoC. Kindly note I do not have the luxury to run a PoC, I can provide you with this:
|
Interesting, I think I understand now. As for being able to disable this header: I think that's worth doing. I should give the option to set it to Then there's the question of what the default value should be. I'm not sure how to proceed here, and would love feedback. A web author seems to have two options with this header:
Ideally, a developer would protect themselves by disabling the filter and doing XSS protections by themselves. If every developer were well-versed in security, this is fine. But a big reason people use this mode (and its parent module, Helmet) is because you just have to use it and then you can forget about it, without having to understand too much. Should I try to protect users from trivial reflected XSS but expose them to cross-origin leaks, or should I protect them from cross-origin leaks but expose them to trivial reflected XSS? My leaning would be to disable the header and make sure to tell people that this header does not protect them against XSS. What do you think? |
Hi @EvanHahn ! Thank you for taking the time to understand the issue at hand 😄 As an offensive tester, once I detect a reflected XSS, bypassing the auditor becomes really simple. This is a reason to why it's being deprecated. It's not effective in what it does. It will only stop basic attacks (basic attacks are low percentage of the whole attack spectrum). If that's the threat model, there's a bigger issue here. Your last sentence is truly on point. Advising developers to try applying the CSP header is a much better alternative. It indeed is harder, yet it provides better security. If I can help you in any way, please let me know. |
I'll spend some time thinking about this and will try to figure out a plan. Thanks! |
@EvanHahn Hi! We will be opening an issue of this in the cheatsheetseries project to properly update the code examples and close the current PR. Please let me know when the update happens. Stay safe! 😄 |
To anyone reading this issue who wants to disable the header: you don't need this module. Here's a very short piece of custom middleware that does the trick: app.use(function (req, res, next) {
res.setHeader('X-XSS-Protection', '0');
next();
}); As I said before, I think users should be able to set the header's value to whatever suits them. If that's But what should the default value be?
No matter what we choose, the default will put some people at risk. I'm coming around to the idea that the default should be The Secure Headers module is also dealing with this issue and I want to discuss with them a bit, but that's my tentative plan. |
This has been added to Helmet v4, which I plan to release this Sunday, 2020-08-02. You can install the release candidate with |
Helmet v4 (and Thanks for reporting and for discussing this with me. |
@EvanHahn Hi Evan, I am using helmet: 4.4.1, still getting Or how can I change the behavior, there is no option in helmet.xssFilter to change the options |
@RezaRahmati It should be set to |
…ssuecomment-1500157600 and Hardenize report suggestions
…ssuecomment-1500157600 and Hardenize report suggestions
Following a decision by Google Chrome developers to disable Auditor, developers should be able to disable the auditor for older browsers and set it to
0
.The
X-XSS-PROTECTION
header was found to have a multitude of issues, instead of helping the developers protect their application.The following discussion describes the issue at hand with more references: OWASP/CheatSheetSeries#376
A PR is currently open to tackle the issue at the CheatSheet Series project: OWASP/CheatSheetSeries#378
If approved, we can help with creating a PR for this issue.
Available for further discussions 😄
The text was updated successfully, but these errors were encountered: