W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] idea about html code security anti xss

From: Ashley Sheridan <ash@ashleysheridan.co.uk>
Date: Wed, 16 Jun 2010 12:38:03 +0100
Message-ID: <1276688284.2219.52.camel@localhost>
On Wed, 2010-06-16 at 13:33 +0200, gabmeyer at westweb.at wrote:

> On 6/15/10 6:19 PM, gabmeyer at westweb.at wrote:
>  Hello,
> 
>  I had just this idea after reading so much about xss and code injection.
> 
>  I think there is a simple solution:
> 
>  1.)
>  I now invent an attribute called strlen=""
> 
>  I append this to ahtmlcode with strlen of 94843 bytes including whitespace
> 
>  The browser know knows the exact position where the divtag must end.
> 
>  You cannot inject some code that closes the tag before.
> 
>  2.)
>  you can now control the code inside the div.
>  you can also append a second attribute called "secure" that prevents any scriptcode to run from inside the div.
> 
> 
>  Maybe this idea is not new, or does not work.
> 
>  Please let me know what you think about this idea.
> 
>  Christian Gabmeyer
> 
> On 2010-06-16 03:29:50 arun at mozilla.com wrote:    
> 
> I think one approach that we're interested in pursuing at Mozilla is the 
> Content Security Policy approach:
> 
> https://wiki.mozilla.org/Security/CSP/Specification
> 
> In particular, restrictions on inline scripts, or at least on 'eval' 
> might be useful here, along with other mitigation on loading cross-site 
> content.
> 
> We'd like this in the Firefox 4 timeframe.
> 
> -- A*
> 
> 
> Hello Arun
> CSP: This seams to affect only the whole document, because it uses a header to switch browser into secure mode. but from a htmlcoder  point this is not the place where i work. everybody should be able to write secure code not only the developer, i think.
> 
> my aproach to be able to define a strlen attribute gives the browser the ability to check for broken/closing tags, and in case of an injection inside the string it must ignore the foreign closing tag .
> If i put all unsecure code into sections of <div unsecure="strlen in bytes"></div> it is posible for the browser to render the page correctly and than apply CSP to it.
> on the server side the developer must not know the content or even inspect it the only thing todo is run strlen() around it and create the tag surrounding the content.
> 
> -- C*
> 
> 
> 


You're still missing the fact that the way most attacks happen is
because the user-entered data is accepted by the server, and then output
by the server. From where is it expected to make a correct strlen()
calculation?! XSS attacks aren't just loads of code entered at the
client-side of things. It's an attack on a system to exploit the
browser, but at the end of the day, the onus is on the server to resolve
the issue, as the browser isn't going to always make the best judgement
call to fail something gracefully.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100616/fef274c0/attachment.htm>
Received on Wednesday, 16 June 2010 04:38:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC