Re: XSS-Protection notes

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