RE: XSS-Protection notes

I disagree with the basic strategy being proposed.

Issues the Microsoft team has found with XSS filtering:

·        False positives break sites that are not actually vulnerable.

·        Perf issues where the regexp to detect vulnerable sites cause pathological amounts of time to be consumed before deciding, sort-of breaking some sites.

·        False negatives because attackers can test their attacks against browsers until they find one that passes the filter

Thus the filters are hurting sites and users, and not really defending anyone.

Observation: XSS is a site fault, and site owners should fix the faults.

Conclusion: our various XSS detectors should not block anything. Instead, they should silently report XSS faults that they think they detect to either the browser vendor, the site owner, or both.

From: Ángel González [mailto:angel@16bits.net]
Sent: Wednesday, October 12, 2016 4:54 PM
To: public-webappsec@w3.org
Cc: David Ross <drx@google.com>; Sebastian Lekies <slekies@google.com>; Artur Janc <aaj@google.com>
Subject: Re: XSS-Protection notes

On 2016-10-10 at 15:19 -0700, David Ross wrote:
Here's another way to consider achieving the intended result...  There are certainly some bits of configuration that have gelled over the years and are now simply extra header cruft we might expect any reasonably secure page to serve.
Some examples to consider:
  - X-Content-Type-Options=nosniff
  - The secure bit on cookies

With the move away from whitelists, best practice around CSP has changed recently and may continue to change going forward.  So we might want to avoid including CSP in any canonical security configuration.  Well, at least today, in 2016.

Consider something like:
Security-Config: level=1; someConfigData=foo; otherConfigData=bar

Level 0 would be nothing.  (Same as not including this header.)
Level 1 would be whatever we define in 2016.
Level 2 would be whatever we decide to define in 2017.
...etc.

With this, developers could drop all the extra header cruft and follow more simplified security guidance.  An opt-in model means that we avoid automatically breaking pages.

We'd need to define a very clear philosophy about what we would include in level=N+1.  Being too aggressive would hurt adoption, while being too lax would pass on an opportunity to improve web security.  And of course we'd need to define level=N+1 periodically, perhaps at an annual meeting on a warm tropical island.  =)

Dave


Hello Dave

I wouldn't use bare numbers there, but some kind of tags, like "legacy-2016", "modern-2016" or "safest-2017", which would alias the «security flags that should be expected from a modern application developed in 2016». Those expectations are what would need to be defined each year (as opposed to a paranoid flag that simply enables everything available at that point in time).
In addition to the defined levels for security configuration, it should also allow the developers to add or remove flags from a named configuration level. So that the developers could refer to a policy by the alias but add/remove a few flags.

Another point is what should be the behavior when a webpage requests a security config it knows nothing about (eg. the level corresponding to 2050). I guess the UA should apply the higher level [of that name] it knows about, instead of falling back to no security at all, but that would produce unintended results for old browsers if there's a version that drops a flag previously added.

Best regards