Re: <iframe doc="">

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.  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.

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).

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.

> 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.

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

Received on Monday, 25 January 2010 21:56:44 UTC