Re: XSS-Protection notes

Ángel:
That sounds great.  We should be careful to avoid adding complexity to the
extent that this new header becomes even more unwieldy than what we have
today.  (Not that what you're proposing is too complex.)

Crispin:
It's been difficult to watch how things have played out over the past few
years with the IE / Edge filter, for sure.  It doesn't seem that the filter
is being maintained with consistency, and when changes do pop out they
often seem indefensible and surely create perf / compat headaches.  (E.g.:
The regex that was added to block anchors.  Or the change to the neuter
replacement character from # to ^.)  I've pinged the team in June & July to
suggest disabling the IE / Edge filter but haven't heard back.  I'll add
you to the thread as it looks like this may help.

Dave

On Wed, Oct 12, 2016 at 6:39 PM, Crispin Cowan <crispin@microsoft.com>
wrote:

> 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
>
>
>