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

[jmanico]

... the debate to keep this header ON is for older browser support. But I politely reject that side of the debate. X-XSS-Projection actually makes applications MORE DANGEROUS in older browsers when it is turned on, is my conjecture and is also the point made in several of the articles we've been passing around. Remove it! :) Aloha, Jim

…

On 3/23/20 11:12 AM, Jim Manico wrote: 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 On 3/23/20 11:08 AM, Ariel Coronel wrote: > > Awesome to hear that, Simon. > Netsparker's take > <https://www.netsparker.com/blog/web-security/goodbye-xss-auditor/> > Acunetix's take > <https://www.acunetix.com/blog/web-security-zone/chrome-removes-xss-protection/> > I contacted Scott (Owner of Security Headers > <https://securityheaders.com/>) 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. > > — > 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/AAEBYCNAHTBFFE6JJVEJIT3RI53NTANCNFSM4LQNZTOQ>. > -- Jim Manico Manicode Security https://www.manicode.com

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

[jmanico]

.... last pitch. We agreed to keep browser specific defenses out of the cheatsheet series as much as we can. Since this is fully removed from several browsers, it fits that criteria as well. - Jim

…

On 3/23/20 11:16 AM, Jim Manico wrote: ... the debate to keep this header ON is for older browser support. But I politely reject that side of the debate. X-XSS-Projection actually makes applications MORE DANGEROUS in older browsers when it is turned on, is my conjecture and is also the point made in several of the articles we've been passing around. Remove it! :) Aloha, Jim On 3/23/20 11:12 AM, Jim Manico wrote: > > 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 > > > On 3/23/20 11:08 AM, Ariel Coronel wrote: >> >> Awesome to hear that, Simon. >> Netsparker's take >> <https://www.netsparker.com/blog/web-security/goodbye-xss-auditor/> >> Acunetix's take >> <https://www.acunetix.com/blog/web-security-zone/chrome-removes-xss-protection/> >> I contacted Scott (Owner of Security Headers >> <https://securityheaders.com/>) 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. >> >> — >> 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/AAEBYCNAHTBFFE6JJVEJIT3RI53NTANCNFSM4LQNZTOQ>. >> > -- > Jim Manico > Manicode Security > https://www.manicode.com -- Jim Manico Manicode Security https://www.manicode.com

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

[calabacito]

Thank you Jim !
Can you update the ticket later with the final changes around the different OWASP projects please?

[ScottHelme]

I agree that the only universally applicable advice is to disable the Filter/Auditor with a value of 0 in the header. There are some edge cases where you could argue against this but they are too complicated and burdensome. It's worth noting that some very large sites, like Facebook, have been disabling the Filter/Auditor for quite some time and at the time of writing are still doing so.

It's also worth nothing that Security Headers (securityheaders.com) deprecated this header in July 2019 at which point is was no longer required for the A+ grade (source) and we do not recommend that sites set it if it is missing.

As for Jim's comments:

Scott Helme's site does not evaluate header values, it just checks if they are present. The grades it gives are highly inaccurate.

We do evaluate header values Jim, you can see us give grade restrictions for severe problems in a CSP header or warnings for problems in Cookie headers, as just two examples. As for inaccuracy in grading, could you let me know what we're inaccurate compared to or why they are inaccurate? I'd be happy to improve something if there is an issue 👍

[jmanico]

Scott, First of all forgive me acerbic comment. I stand corrected, a ran a few tests and dang things improved a lot since I last checked it carefully. My mistake and thank you for jumping in. I use secure headers likely a dozen times a week. Thank you for your work there. If I see something that looks off I’ll drop you a polite note. Regards, Scott. -- Jim Manico @manicode

…

On Mar 24, 2020, at 1:00 PM, Scott Helme ***@***.***> wrote:  I agree that the only universally applicable advice is to disable the Filter/Auditor with a value of 0 in the header. There are some edge cases where you could argue against this but they are too complicated and burdensome. It's worth noting that some very large sites, like Facebook, have been disabling the Filter/Auditor for quite some time and at the time of writing are still doing so. It's also worth nothing that Security Headers (securityheaders.com) deprecated this header in July 2019 at which point is was no longer required for the A+ grade (source) and we do not recommend that sites set it if it is missing. As for Jim's comments: Scott Helme's site does not evaluate header values, it just checks if they are present. The grades it gives are highly inaccurate. We do evaluate header values Jim, you can see us give grade restrictions for severe problems in a CSP header or warnings for problems in Cookie headers, as just two examples. As for inaccuracy in grading, could you let me know what we're inaccurate compared to or why they are inaccurate? I'd be happy to improve something if there is an issue 👍 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ThunderSon]

Thank you @ScottHelme for your feedback, and apologies for any misunderstanding that occurred 😄
The document will be updated to remove the header and set a note to inform the users that this header has been deprecated. A small study on the sheet will be conducted in order to update it.

Thank you all for your help and support!

[ScottHelme]

No problem at all Jim, we're constantly working on improving. Let me know if you ever see something we can work on!