Update: Cross_Site_Scripting_Prevention_Cheat_Sheet

[calabacito]

What is missing or needs to be updated?

We should update Bonus Rule #4: Use the X-XSS-Protection Response Header

How should this be resolved?

Browsers don't give proper support anymore:
Chrome has XSS Auditor Removed: https://www.chromestatus.com/feature/5021976655560704
Firefox have not, and will not implement X-XSS-Protection: https://bugzilla.mozilla.org/show_bug.cgi?id=528661
Edge have retired their XSS filter: https://blogs.windows.com/windowsexperience/2018/07/25/announcing-windows-10-insider-preview-build-17723-and-build-18204/

Some of the links were provided via: metabase/metabase#11444

Thanks,
Ariel Coronel

[jmanico]

Oh I agree so much. We should suggest that this is TURNED OFF since it actually adds vulnerability! Well done +1 - Jim

[ThunderSon]

I don't believe this should be disabled. If the browser doesn't support, that header won't hinder performance nor affect the user in any way, unless an attack vector exists, which is discussed in one of the points below.
Important points to note:

• By default, if the web-server doesn't set it, it's X-XSS-Protection: 1 set on filter or block, based on the browser version.
• Some websites shouldn't set it because of the xs-leaks attack vector.
• If a website is still served on older websites, the Header could help protect the user, so what is the concern that we're tackling?
• If there is no CSP implemented in the response, removing it isn't that logical.

More on the decisions taken here in the daily swigs.

[rbsec]

As with many things, I'm not sure there's a simple recommendation to make here. My understanding is:

X-XSS-Protection: 0

• More vulnerable to XSS in some browsers (IE, older Chrome, maybe others?)

X-XSS-Protection: 1

• More vulnerable to XSS in some browsers (as XSS auditor can break protection)
• More vulnerable to clickjacking (can break framebusters)

X-XSS-Protection: 1; mode=block

• Some protection against XSS in some browsers
• Potentially vulnerable to XS-Leaks (although depends on lack of CSRF protection/SameSite)

Having it in the default state (filtering) seems the most dangerous, as it introduces a vulnerability that you can't really do much about (the attacker being able to disable/break scripts in your page).

As long as you have other good protections in place (CSP, CSRF-style protection or SameSite=Strict to protect against XS-Leaks) then I'm not really sure it makes much difference whether you have it disabled on blocking (and it won't affect a lot of users anyway.

I don't have a particularly strong feeling either way, but if we're going to recommend disabling the header (which is the opposite of what almost everyone else recommends), then I think we need to have a strong (and documented) justification for doing so, and to expect arguments from people down the line about it.

[calabacito]

You guys gave great examples on why it needs an update.
Also there is no mention on XS-Leaks for example.

[jmanico]

Hey, I do think a simple recommendation is prudent. Disable it. The advice most security architects I know give is to turn x-xss-protection OFF since it's dangerous. Yes, dangerous. XSS defense should focus on escaping, HTML Santitization, CSP and Trusted Types. X-XSS-Protection is dead. Here is a reference to the dangers of X-XSS-Protection: https://medium.com/bugbountywriteup/xss-auditor-the-protector-of-unprotected-f900a5e15b7b And please note the browsers are all removing this feature, too. https://www.zdnet.com/article/google-to-remove-chromes-built-in-xss-protection-xss-auditor/ Thanks all, Jim

[jmanico]

It needs to be disabled. This header has a LONG history of doing harm. This is why all the browsers are removing it. It causes HARM and WEAKENS security. https://medium.com/bugbountywriteup/xss-auditor-the-protector-of-unprotected-f900a5e15b7b Aloha,

…

-- Jim Manico Manicode Security https://www.manicode.com

On 3/21/20 5:23 AM, Elie Saad wrote: I don't believe this should be disabled. If the browser doesn't support, that header won't hinder performance nor affect the user in any way, unless an attack vector exists, which is discussed in one of the points below. Important points to note: * By default, if the web-server doesn't set it, it's |X-XSS-Protection: 1| set on filter or block, based on the browser version. * Some websites shouldn't set it because of the xs-leaks <https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information> attack vector. * If a website is still served on older websites, the Header could help protect the user, so what is the concern that we're tackling? * If there is no CSP implemented in the response, removing it isn't that logical. More on the decisions taken <https://portswigger.net/daily-swig/google-deprecates-xss-auditor-for-chrome> here in the daily swigs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#376 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCLP6QEKEAADPPOW5QTRISBSPANCNFSM4LQNZTOQ>.

[mackowski]

Yeah we should either recommend to disable or describe a full threat model

[psiinon]

FYI we no longer report this as an issue in ZAP: zaproxy/zaproxy#5849

[ThunderSon]

Awesome to hear that, Simon.
Netsparker's take
Acunetix's take
I contacted Scott (Owner of Security Headers) to look this through. Once agreed, we can update the sheet.

I'll be in contact with the Security Headers Project in OWASP, and Detectify. Any other major player that should be contacted?

[jmanico]

So do you agree we should advise on disabling (Value 0) or just not set the header!?

…

-- Jim Manico @manicode

On Mar 23, 2020, at 7:13 AM, Simon Bennetts ***@***.***> wrote:  FYI we no longer report this as an issue in ZAP: zaproxy/zaproxy#5849 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[calabacito]

Awesome to hear that, Simon.
Netsparker's take
Acunetix's take
I contacted Scott (Owner of Security Headers) to look this through. Once agreed, we can update the sheet.

I'll be in contact with the Security Headers Project in OWASP, and Detectify. Any other major player that should be contacted?

Thanks, since we are working here for industry standards would be nice to keep track of this "things" and since ZAP is already part of OWASP, have some pipeline towards following or create an issue for this situations, right?

If anything I can help with, just mention.
Best regards,

Ariel.

[jmanico]

Ariel, My name is Jim I'm the project lead and chief editor for the cheatsheet project. I'd like to make the call. I've been studying this issue for a while and it's *dangerous* to set this header. It makes sites that are not vulnerable to XSS, vulnerable. Scott Helme's site does not evaluate header values, it just checks if they are present. The grades it gives are highly inaccurate. So let's change these recommendations. We have enough to make the call. Developers need to either remove the header or set it to zero, I think the debate is over. There is NO good reason to set this header to blocking mode. Respectfully, Jim Manico Cheatsheet Project Lead