Re: XSS-Protection notes

Without getting into a broader discussion about the value of XSS filters,
my preference would be to not include the filter behavior in the
XSS-Protection proposal.

To me, the main benefit of the new formulation of the nonce/hash-based XSS
mitigation approach is its simplicity (at least compared to CSP). On one
hand, adding a way to control filter behavior doesn't hurt because it's
just one extra flag; on the other, we've seen with CSP that people tend to
use a lot of the capabilities the mechanism provides without fully
understanding what they're doing. This increases adoption cost and makes it
difficult to explain to developers what the mechanism actually gives them
-- all problems we've seen in the CSP world.

Since XSS filters are enabled by default (and the UA should pick a sane
default behavior, i.e. blocking mode), the number of people who need to
tweak the filter's behavior should relatively small. XSS-Protection doesn't
attempt to subsume all XSS-related functionality of the browser which means
that people who need to use more "advanced" features will likely not use it
anyway, or will additionally have to set other headers (e.g. X-C-T-O:
nosniff, or parts of CSP not exposed by X-P like form-action). It seems
fine to require these power users to use X-XSS-Protection like before in
order to reduce the complexity of the new, more developer-friendly
mechanism.

Cheers,
-A


On Thu, Oct 13, 2016 at 7:35 AM, David Ross <drx@google.com> wrote:

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