W3C home > Mailing lists > Public > public-html-testsuite@w3.org > November 2010

Re: Test Suite and XSS

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 8 Nov 2010 10:34:01 -0800
Message-ID: <AANLkTinfhUzRX1yedErLuQUhS4ZE6ys2wHX4JDfqFV=C@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Dominique Hazael-Massieux <dom@w3.org>, Anne van Kesteren <annevk@opera.com>, public-html-testsuite@w3.org
On Mon, Nov 8, 2010 at 8:20 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Nov 8, 2010, at 8:02 AM, Dominique Hazael-Massieux wrote:
>
>> Le lundi 08 novembre 2010 à 17:00 +0100, Anne van Kesteren a écrit :
>>> While we had the meeting everyone in the room sort of agreed that the
>>> safest solution would be to host the test suite on a domain that could not
>>> be made same-origin with w3.org using document.domain. And one that would
>>> not share cookies either. Dominique suggested that we could instead try to
>>> avoid such holes by not putting files that allow for XSS on test.w3.org.
>>> When I relayed this nobody thought that would be a workable solution.
>>
>> (FWIW, I'm making progress internally on setting up a separate domain
>> based on Anne's feedback on this)
>>
>>> It seems to me the most pragmatic solution here is to use a separate
>>> domain. This avoids the hassle of having to carefully review each file for
>>> XSS exploits and avoids tests having to be rewritten. It also removes the
>>> possibility for an exploit this way which seems like a major win.
>>>
>>> If people could reiterate their own points from the meeting that might
>>> help.
>>
>> I'm particularly interested on more details as to what are the XSS holes
>> that look hard or impossible to plug.
>
> I think it is more a matter of expected volume of tests than specific exploits. We expect a thorough test suite for HTML5 will run north of 100,000 tests. Many of the tests will run script, and a number of them will be deliberately probing edge cases of the same-origin security policy. Carefully reviewing all these tests for XSS vulnerability, or for that matter CSRF vulnerability, is probably beyond the means of the working group.

Indeed, this is my exact concern. Having written lots and lots of
tests for firefox, I can safely say that a large number of them has
CSRF and XSS issues in them. Many of which I've only realized after
the fact that they have this issue.

So given the very large amount of code that we'd need to audit, and
continuously re-audit, I would be worried that we'd end up letting XSS
and CSRF attacks through no matter what.

And note that it's not just cgi scripts where this issue appears. Many
times tests are written to use postMessage/onmessage in order to
communicate with "clean" or "cross site" environments running in an
iframe. Such pages are susceptible to XSS bugs if they are iframed and
sent malicious messages.

/ Jonas
Received on Monday, 8 November 2010 18:41:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:37 UTC