Re: XSS out of scope

On 2007-04-05 00:13:47 -0000, Close, Tyler J. wrote:

> I've added a new Out of scope section to our Note to cover XSS
> attacks. See:

> http://www.w3.org/2006/WSC/drafts/note/#XSS

> This edit addresses ACTION-160

The current text suffers a bit from declaring an entire attack out
of scope, when that attack really stands for a number of things:

- Generically dealing with domains of control between web
  applications and all kinds of things that browsers can do to get
  into the way of the cross-site scripting in my view is an
  interesting topic, but out of scope.

- Dealing with things such as mixed content that might be the result
  of a cross-site-scripting attack (or just a legitimate screw-up!)
  is, in my view, an integral part of what is in scope.

I wonder if what we really want to say is that work on cross-domain
security policies is out of scope, as opposed to declaring the
attacks and all their possible effects out of bailiwick.

Incidentally, "Web content formats are not currently designed such
that the receiver can readily distinguish content that was produced
on purpose versus content that was produced by accident." is kind of
true, but besides the point when the attack, e.g., might work by
using frames and therefore would get us directly into a discussion
as to what the security context of a frameset is, with relevance to
certain xss attacks.

On 2007-04-06 16:53:41 +0000, Mike Beltzner wrote:

> We need to get this straightened out. 

> Johnathan asked if we were unfairly limiting scope to
> visible-UI-only solutions, meaning we couldn't recommend that the
> browser should silently make choices that increase a user's
> security.

In my view, recommending that a certain decision should not normally
be made by the user (except, perhaps, with some kind of expert
override in effect) is in scope.  It would be extremely odd to make
that kind of recommendation without saying what decision the browser
would make by default.

> The question really becomes: is the goal of this WG to only
> generate recommendations on how to *display* security context to
> users, or is it to also recommend what type of content should be
> blocked from being displayed. The latter is, IMO, a wider set of
> recommendations, since it starts talking about types of content
> that can/should be untrusted.

I thnk "type of content" is far too broad and exceeds both the
group's and this discussion's scope.

On 2007-04-06 17:01:48 +0000, Shawn Duffy wrote:

> I'm not sure we're saying the browser should _block_ anything,
> but notifying the user that something looks amiss may be in
> scope.

And I think that a "block" vs. "tell user that something looks
amiss" discussion isn't one that we ought to have when trying to
understand our scope, but one that we ought to have when trying to
understand possible recommendation material.

> In my eyes, this isn't really about including XSS, but is more
> about acknowledging that XSS is an avenue for modifying trusted
> content and, thus, impacts the security context for the user.

Yep.

> So, using XSS to steal cookies, hijack sessions, etc. would not
> be included but using XSS to modify site content in a phishing
> attack, perhaps, should be.

... to the extent to which a client can tell, yeah.

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Sunday, 8 April 2007 17:52:23 UTC