Re: XSS-Protection notes

Simplicity wins. We've dropped the `reflected` bits, and renamed back to
`ARTUR`: https://mikewest.github.io/artur-yes/

New naming suggestions welcome. :)

-mike

On Fri, Oct 14, 2016 at 12:20 AM, Brad Hill <hillbrad@gmail.com> wrote:

> +1 to Artur.  If the point of this header is to keep it simple, let's keep
> it simple.
>
> On Thu, Oct 13, 2016 at 6:16 AM Artur Janc <aaj@google.com> wrote:
>
>> 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
>>
>>
>>
>>
>>
>>