- From: Smylers <Smylers@stripey.com>
- Date: Mon, 25 Jan 2010 21:34:24 +0000
- To: public-html@w3.org
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