Re: <iframe doc="">

On Mon, Jan 25, 2010 at 3:56 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au>wrote:

> Shelley Powers wrote:
>
>> On Mon, Jan 25, 2010 at 2:09 PM, Tab Atkins Jr.<jackalmage@gmail.com
>> >wrote:
>>
>>  On Mon, Jan 25, 2010 at 1:35 PM, Leif Halvard Silli
>>> <xn--mlform-iua@xn--mlform-iua.no>  wrote:
>>>
>>>> 1) So, is the text/html-sandboxed itself simply a security myth - since
>>>> it doesn't solve e.g. SQL injection?
>>>>
>>> No?  SQL injection is red herring...
>>>
>>>  It's not a red herring.
>>
>> The use case for this thing is weblog comments. Comments have to saved
>> in a database, hence the very real possibility of SQL injection.
>>
>
> Yes, it is a red herring because that security vulnerability happens in a
> completely different layer from that which is being addressed by sandboxing.
>  That's like saying that door locks are completely useless because they
> don't stop anyone from getting in through an open window.
>
> From what your saying, it seems like you don't even understand what SQL
> injection is.


Oo, hold on partner, I definitely know what SQL injection is.

The point I was trying to make is that the perceived security that something
like srcdoc supposedly provides by comments is already handled by tools that
not only provide the same security, but a whole lot of other security
measures, too.

Since srcdoc does not provide all of these other security measures, they
still have to be used, leading one to question why we would need to have
both. In particular when srcdoc gives us no control over what is, or isn't
managed -- it's basically an all or nothing approach, while the other tools
give us much more finely tuned control.

In addition, srcdoc brings with its own problems, not the least of which is
all of the issues associated with embedding markup into attributes, the
changing code needed for web bots to now deal with escaped markup embedded
within attributes -- all for something that I find no real customer for.



> SQL injection is a technique where input sent to the server can cause the
> execution of arbitrary SQL.  This can happen if a server side script doesn't
> properly deal with string literals before passing them to an SQL statement.
>
> http://en.wikipedia.org/wiki/SQL_injection
>
> That security issue is completely independent from XSS, which is where
> client-side scripts are inserted into user generated content which, when
> subsequently output by the server in the page and viewed by other users,
> execute in the browser with the same origin, and thus priviliges, as a
> normal script inserted by the page owner would have.
>
>
I think I know what this is too, Lachlan.


> http://en.wikipedia.org/wiki/Cross-site_scripting
>
> Sandboxing in this context in an additional layer of protection against
> XSS.  It's a signal to the browser that it should not permit, for example,
> the execution of scripts, or to allow scripts but resrict their access in
> specific ways (depending on the sandbox attribute's value).
>
>
Specifically for comments. Well, funny thing happens with comments: all that
crap gets filtered out before the comment is saved, so you don't have to
worry about what's executed or not when the comments are displayed in the
page.

There's that taking care of the problem once, when the data is saved, rather
than many times when the data is displayed issue again. That came up with
something else recently.

These security vulnerabilities, XSS and SQL injection, occur and very
> different places and have no relation to each other.  The fact that a
> security measure designed for one doesn't help in the slightest with the
> other, is completely irrelevant and it is absolutely a red herring.
>
>
Yes, they are relevant when you consider that they can all be solved by one
piece of software at one time.


>
>  So, srcdoc can't replace current security measures, provided by the the
>> software you seem to disdain.
>>
>
> srcdoc itself isn't even a security measure.  It needs to be combined with
> the sandbox attribute to provide any security at all.  It just happens that
> most of the use cases for srcdoc usually require sandboxing.  (I'm not sure
> if there are any compelling cases where one wouldn't want srcdoc content to
> be sandboxed.)  But even so, it would be better if you could focus your
> critique of srcdoc on the issues related specifically to srcdoc, and not
> issues related to whether or not sandboxing is useful.
>
>
I think perhaps you all need to focus on the arguments I'm making about
existing tools and software, how people do things now, the potential
customers involved and whether they would be interested in this spiffy new
addition to HTML5, rather than continually telling me you don't approve of
how I participate in this group. It is getting tedious.

There is no justification, none whatsoever for srcdoc, not the least it is
useless for its main use case, which is weblog comments.

Shelley


> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>