W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: <iframe doc="">

From: Smylers <Smylers@stripey.com>
Date: Mon, 25 Jan 2010 21:34:24 +0000
To: public-html@w3.org
Message-ID: <20100125213424.GC4702@stripey.com>
Shelley Powers writes:

> 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 and I still have no idea why it was
> > brought up.  It is a server-side issue concerning user-input and
> > server-side databases.  It it *never* something that can be affected
> > by client-side measures of *any* kind, even theoretically.  It is so
> > far from being relevant to the discussion as to be patently
> > ridiculous.
> 
> 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.

SQL injection, a server-side exploit, is easy to avoid on the server
side, by use of database access libraries where parameters are supplied
separately from the 'fixed' SQL (for example DBI in Perl or using the
Zend Framework in PHP).  This completely avoids them, without individual
programmers having to think about which input characters are a risk.

However, however good those library routines are at SQL injection
protection (and it's straightforward to avoid 100% of it), they do
nothing at all to prevent browser-side exploits, such as cross-site
scripting attacks; something further is needed.

Also, SQL injection protection needs to on data _input_.  HTML escaping
is typically performed on _output_ (leaving the user's raw input in the
DB -- for example to be available for reference, to make it easy to use
in different output formats with different escaping requirements, or to
avoid the risk of a bug in filtering destroying the original data).  In
which case it needs to be in a different place.

> The minor security against script injection that srcdoc provides is a
> drop in the bucket compared to other security risks associated with
> comments.

<iframe srcdoc="..."> can replace server-side code which is filtering
out cross-site scripting attempts.  It doesn't replace code for
inserting into a database, but that's usually completely different from
the code for output filtering, so the saving is genuine.

Smylers
-- 
Watch fiendish TV quiz 'Only Connect' (some questions by me)
Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
Received on Monday, 25 January 2010 21:34:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:13 UTC