X-XSS- Protection

[Adlago]

In line 106 on file Output.php you entered XSS protection with a value of 0. Your description is this:

This is so when we post contents with scripts (which is possible in the editor, like when embedding a Twitter tweet) the broswer doesn't block it

When this is used with good find is great. But what happens to dDos attack? There is no protection.

All analysts of this defense recommend this

Block access to the entire page when an XSS attack is suspected
Make sure that the user’s browser does all it can to prevent an XSS-type attack.

XSS attacks
An XSS-type attack (XSS stands for Cross-Site Scripting) aims at injecting content into the page.

Recent browsers have an integrated protection against XSS attacks. However, this protection can be disabled. To prevent any harm to the user, we recommend that you force the activation of the XSS Protection, and should an XSS attack be detected, block access to any of the page content.

Solution: configure an "X-XSS-Protection" HTTP header
Add the "X-XSS-Protection" HTTP header with "1; mode=block" as value (1 to indicate the activation, and mode=block to indicate that the entire page must be blocked if a problem occurs).

Take a look at the last line

"mode=block to indicate that the entire page must be blocked if a problem occurs)"

So now you have removed this protection with this value of 0.

If each administrator decides and puts this protection correctly in his htaccess file, headers exclusion from duplicates two XSS protection rules.

The other solution is editing in output.php file. This works correctly for XSS protection - but in the next upgrade an original file should be restored. This is very uncomfortable for consumption.

Perhaps it is good idea, that all security headers are ACP options and that each administrator chooses how to use them for their own needs.
Please consider this.

[Stuart Silvester]

You posted this a few months ago and the answer is still the same (see linked topic for further information).

 

[Adlago]

4 minutes ago, Stuart Silvester said:

You posted this a few months ago and the answer is still the same (see linked topic for further information). 

 

@bfarber say

break functionality in the software

Please specify such interruptions with examples.
I have not noticed such a problem for these two months ...

[Adlago]

PS. If you use software secure protection with  Content-Security-Policy - yes, this topic will make no sense.
But as results from 4.4.3 beta report - do not use it again.

[bfarber]

We outright and intentionally disable the built in XSS protection because it can break functionality with the software (Twitter embeds used to be an example, I am unsure if they still are). The way this specific built in browser protection works is by sniffing request sent to the server for code (such as javascript code) and then verifying if that code is reflected back in the output. When you are submitting posts, that is exactly what is happening - you submit a post to the server, it then displays your post in the topic. Normally this won't trip up an XSS filter, but it is entirely possible to especially with things like remote embeds where we don't really have a lot of control over what will be embedded, so the protection must be disabled.

This is not an accident. It is not advised to force the protection enabled - if you do and run into problems with certain post content, there is nothing we will be able to do to resolve that issue.

[Adlago]

7 minutes ago, bfarber said:

We outright and intentionally disable the built in XSS protection because it can break functionality with the software (Twitter embeds used to be an example, I am unsure if they still are). The way this specific built in browser protection works is by sniffing request sent to the server for code (such as javascript code) and then verifying if that code is reflected back in the output. When you are submitting posts, that is exactly what is happening - you submit a post to the server, it then displays your post in the topic. Normally this won't trip up an XSS filter, but it is entirely possible to especially with things like remote embeds where we don't really have a lot of control over what will be embedded, so the protection must be disabled.

This is not an accident. It is not advised to force the protection enabled - if you do and run into problems with certain post content, there is nothing we will be able to do to resolve that issue. 

The solution is - put an option in ACP.
Every administrator needs to decide which option to use.

[bfarber]

Not when it will break functionality.

At that point if you are determined to do something we say not to do anyways, then you can (1) override the HTTP header at the server level or (2) create a plugin.

We don't intentionally add options to the ACP that we are aware can legitimately break functionality in the software.

[Adlago]

When added at the server level - a duplication of a rule is obtained - both the value 0 and the value 1 mode-block are obtained in the headers. Which is a contradiction and probably none of the rules work.
That's why I wrote that value should be edited in an output.php to be correct.

[Makoto]

Then use a plugin as @bfarber stated, or utilize something like headers-more in Nginx if you really want.

It's not something IPS is going to help you with for the reasons reiterated above several times.

It should not be edited in the core software because it already is correct. This is intended behavior. If you want to change it, you'll have to figure out how to do it yourself and live with the reality that you'll be breaking core functionality in the software and will not get support when that happens.

[Adlago]

39 minutes ago, Makoto said:

Then use a plugin as @bfarber stated, or utilize something like headers-more in Nginx if you really want.

It's not something IPS is going to help you with for the reasons reiterated above several times.

It should not be edited in the core software because it already is correct. This is intended behavior. If you want to change it, you'll have to figure out how to do it yourself and live with the reality that you'll be breaking core functionality in the software and will not get support when that happens.

Thank you for your opinion, but on this topic I am not looking for advice, but I express my position on this issue.
I think when a security feature needs to be shut down for software to run properly, then the software needs to be fixed before it is available for use.

[Makoto]

25 minutes ago, Adlago said:

Thank you for your opinion, but on this topic I am not looking for advice, but I express my position on this issue.
I think when a security feature needs to be shut down for software to run properly, then the software needs to be fixed before it is available for use.

It's not an opinion, it's a matter of fact.

IPS utilizes Content-Security-Policy headers in place of X-XSS-Protection by default (though you can explicitly disable these, it is strongly discouraged).

There is nothing to "fix." No matter how much you repeat that. It's working as intended. X-XSS-Protection is not necessary on modern browsers when CSP is utilized, which it is on IPS.

You probably just read this off one of the hundreds of random automatic website scanners you use all the time and think because it reported this header was missing IPS absolutely must use it, without actually understanding what the header does or why it is not actually used.

Funnily enough, not only is X-XSS-Protection flawed and prone to being bypassed, enabling X-XSS-Protection can and has introduced new security vulnerabilities in the past, and even Facebook has had to disable it due to a bug that allowed attackers to hijack your account.

So please read up on things before you complain that IPS is not doing their jobs properly or that their code is broken, when it is in fact working exactly as it should.

[Adlago]

22 minutes ago, Makoto said:

IPS utilizes Content-Security-Policy headers in

 

This is easy to check and is not true. Do your security test and then say

[Makoto]

6 minutes ago, Adlago said:

This is easy to check and is not true. Do your security test and then say

Correction, IPS utilizes X-Frame-Options by default and provides CSP as a secondary option for communities that need it.

Anything else?

[Adlago]

30 minutes ago, Makoto said:

Correction, IPS utilizes X-Frame-Options by default and provides CSP as a secondary option for communities that need it. 

Anything else? 

Using this option will turn off X-Frame.
Do you like unsecured security?

 

[Makoto]

I'm sorry but I really don't have any more time or patience to go back and forth like this with someone who bases all their knowledge off of what random online website scanning tools say and can't actually take the time to research or try and understand what those directives actually mean or what they are for.

[Adlago]

26 minutes ago, Makoto said:

I'm sorry but I really don't have any more time or patience to argue with someone who bases all their knowledge off of what random online website scanning tools say and can't actually take the time research or try and understand what those directives mean or what they are actually for. 

I did not understand what you want in this topic. I have a position and defend it. This topic is not aimed at you, it is a team for development. They can decide whether to take it for analysis or not.

[Makoto]

4 minutes ago, Adlago said:

I did not understand what you want in this topic. I have a position and defend it. This topic is not aimed at you, it is a team for development. They can decide whether to take it for analysis or not.

They've already answered you.

And I provided you an even more detailed explanation on why this directive is not necessary and in many cases should not be relied on at all,

1 hour ago, Makoto said:

Funnily enough, not only is X-XSS-Protection flawed and prone to being bypassed, enabling X-XSS-Protection can and has introduced new security vulnerabilities in the past, and even Facebook has had to disable it due to a bug that allowed attackers to hijack your account.

You often-times post these things based off what random website scanners tell you and try and argue developers to death when they explain to you why what you read online is not necessarily true, and it becomes rather annoying after a while.

[Adlago]

Everyone is free to walk in his way even with the pants removed ....

[Makoto]

Just now, Adlago said:

Everyone is free to walk in his way even with the pants removed ....

I believe I would be arrested for indecent exposure if I walked outside of my apartment without pants.

[Mark]

I think you may have misunderstood the way the header works.

X-XSS-Protection basically provides a way to the browser "if anything on this page looks suspicious, don't run it" (either the whole page or just the bit that looks suspicious). It isn't supported by all browsers (Firefox, for example, doesn't support it).

In theory it's a reasonable idea, although a pretty weak protection - it only benefits the users of those browsers from being victims of XSS attacks if your server has already been compromised. Web applications therefore need to take much more sensible measures against XSS protection such as ensuring proper escaping of output (to stop them happening at all), http-only cookies (so even if there is an XSS exploitation it can't access your cookies), etc. We do all of this.

So in other words: all it provides is a very weak level of protection against something the backend already has much better protection for. And, as @Makoto points out, it kind of sucks at doing even that; it is known to have bugs and ironically, some of those bugs cause security issues themselves. Also, there are known ways to bypass it. That's probably why some browsers don't even support it.

Normally, it would barely be worth any thought and we would leave it at the default value. But it was breaking things with false-positives (i.e. it was thinking that code we deliberately wanted to run was suspicious) so turned it off. Apparently we are not alone in going for this option: I just quickly checked Google and Facebook, and both have it turned off (full disclosure: the other two sites I checked, Twitter and Amazon, don't).

You can turn it back online with a plugin or via your server configuration if you really want to, and it's also possible that the Content-Security-Policy header which we do have a setting for will override it (you'll have to check each browser), but we're not going to add a setting specifically for it.

--

tldr: It's a thing that isn't supported by all browsers, with a much grander sounding name than it deserves, which is buggy, and was breaking things. You don't need it on.

[Adlago]

@Mark Google is a search engine and you can not publish it there.
Facebook a few days ago collapsed for several hours - I'm not saying that's exactly why. The reason is unnecessary self-confidence of developers.
A sentence for everyone is right ... I already wrote it.
Thank you for your comprehensive answer.

[Day_]

55 minutes ago, Adlago said:

Everyone is free to walk in his way even with the pants removed ....

I find that wearing pants makes me more aero dynamic which means I’m much faster. 

Without pants my GTmetrix score drops to a B with a high priority recommendation to support my dangly bits. 

[Makoto]

23 minutes ago, dayh said:

I find that wearing pants makes me more aero dynamic which means I’m much faster. 

Without pants my GTmetrix score drops to a B with a high priority recommendation to support my dangly bits. 

I had to try so hard not to burst out laughing. You just made my day, thank you.

[Adlago]

27 minutes ago, dayh said:

Without pants my GTmetrix score drops to a B with a high priority recommendation to support my dangly bits.  

This is not good - if your pants are removed, your "GmMetrix" if it is not A ++ - which lady will test you?😀

[Nathan Explosion]

Just to put it on the record....I am not currently wearing any pants. I am also hoping that this bus gets me home before the police car behind us catches up.