Re: Seamless iframes + CSS3 selectors = bad idea

passwords ARE setted some times by some apps (CUPS used it, as well as
Motorola's SURFBoard).. I think we loose nothing by forbidding them (wont
break existing apps) and we provide security for the ones that do use it..

Anyway, if we block all inputs for me it's fine :)

Regarding the why links:
<a href="?action=deleteAccount&sesc=1i19471gdh17">Delete this account</a>

I dont propose forbiding all links, just instruct the devs to start using
rel=nofollow on sensitive ones or something like that.

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

Sent from Hangzhou, Zhejiang, China

On Wed, Dec 9, 2009 at 12:00 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 8, 2009, at 7:52 AM, sird@rckc.at wrote:
>
> Hi!
>
> Ok maciej, that makes sense..
>
> Links for example may also hold sensitive information (actually the
> original PoC was to read links.. then we figured out that
> passwords/forms/inputs were better and easier), and I can see the case where
> devs want to use them there.. so it wouldnt be a real option in my opinion.
>
> What about blocking completely:
>
> input[type=hidden][value$=]
> input[type=hidden][value^=]
> input[type=hidden][value*=]
>
> input[password][value$=]
> input[password][value^=]
> input[password][value*=]
> input[password][value=] (to avoid dictionary attacks)
>
>
> I'm not sure why input[type=password] requires more protection than other
> input types. It's extremely unlikely for a password to be provided in the
> value attribute, and as mentioned, the value attribute only reflects the
> original default value, not the current value. Some examples *were* shown of
> attacking just plain input[type=text] to grab a username, so maybe we should
> just apply this to inputs in general.
>
>
> For the remaining examples, I don't understand the threat model enough to
> evaluate the effectiveness. Can you give some examples of sites with
> sensitive information in href, src or on* attributes?
>
> a[rel*=nofollow][href$=]
> a[rel*=nofollow][href^=]
> a[rel*=nofollow][href*=]
>
> iframe[src$=]
> iframe[src^=]
> iframe[src*=]
>
> frame[src$=]
> frame[src^=]
> frame[src*=]
>
> and eventhandlers as a whole (everything starting with on*) since devs
> usually put nonces inthere.
>
> Am I missing something?
>
> Greetings!!
> -- Eduardo
> http://www.sirdarckcat.net/
>
>
>
> On Tue, Dec 8, 2009 at 11:37 PM, gaz Heyes <gazheyes@gmail.com> wrote:
>
>> 2009/12/8 Maciej Stachowiak <mjs@apple.com>
>>
>>> Both of these would store any interesting information as text nodes
>>> inside the element. I don't believe any current selectors let you select
>>> based on text contents of the element.
>>>
>>
>> So the problem is we don't want the selectors to be used for certain
>> elements but those elements vary. Then why don't we have a sensitive
>> attribute with a HTML element which effectively disables the selectors.
>> Something like:-
>>
>> <input type="text" sensitive="true" />
>>
>> or selectively enable the selectors like:-
>> <input type="text" css-selectors="true" />
>>
>
>
>