Re: Seamless iframes + CSS3 selectors = bad idea

I also like this option:

4. add a declarative option to <link> and <style> elements to say
  the CSS parser should be in a "sandboxed" mode

I am doing something like that already on ACS (
http://docs.google.com/View?id=ddqtfnx3_381fxp3zjf3 ) but having it on HTML5
would be greaaat.

Would it be possible to add it to <script>? (I also support this on ACS
using Gareth Heyes's jsreg : http://tinyurl.com/jsreg ).

In script it could work to define functions with a different principal..
this way the stuff in there can only work with references it receives from
user functions (should have the same type of protections Mozilla adds to
addons interacting with web content with Wrappers).

This would probably be better than sandboxed iframes.. and would mitigate
quite a lot of problems.

What do you guys think? (maybe this should be a different thread).

Greetings!!
-- Eduardo
http://www.sirdarckcat.net/

Sent from Hangzhou, 33, China

On Tue, Dec 8, 2009 at 5:24 PM, gaz Heyes <gazheyes@gmail.com> wrote:

> 2009/12/8 Adam Barth <w3c@adambarth.com>
>
>> One of my favorite parts about security is that "the buck stops here,"
>> meaning finger-pointing about who's responsible for what doesn't
>> really matter.  In the end, we need to consider the security of the
>> system as a whole.
>>
>> If you agree that we ought to do something about the threat of
>> stealing CSRF tokens with attribute selectors, then the question
>> becomes "what should we do?" not "who's responsible for the problem?"
>>
>> So, what should we do?
>>
>
> One possible solution would be to ignore hidden field types and password
> field types when using selectors. So for example:-
>
> <style>
> input[value*="a"]#token {
> /*
> Any rules are disabled or limited as the field type is hidden
> */
> }
> </style>
> <input type=hidden id=token value=supersecret>
>
>
>