I want to re-raise this issue because I feel it is important.

> > * Do not use cgi.escape for HTML escaping because it does not escape
> > single quotes and may lead to XSS - See
http://www.pythonsecurity.org/wiki/web2py/#cross-site-scripting-xss
<http://www.pythonsecurity.org/wiki/web2py/#cross-site-scripting-xss>
> > and  
> > http://www.pythonsecurity.org/wiki/cgi/<http://www.google.com/url?sa=D&q=http://www.pythonsecurity.org/wiki/cgi/&usg=AFQjCNGMx8qw9zHiaXIBN9IIbcH6l_ceGA>


> I assume you refer to attribute escaping. When using helpers like
 > {{=A(link,_href=url)}} then link is escaped using cgi.escape but url

> is escaped differently (quotes are escaped). The problem is that the
> escape function does not know whether a variable is to be inserted in
> html, css, js, attribute, a string in js, etc. etc. and therefore if
> the function does know the context it is in it can never always escape
> correcly. I do not believe there is a general solution to this
> problem. web2py assumes {{=....}} is escaping HTML/XML. If you need to
> scape attributes we suggest using helpers.  If you need to scape js
> code or strings in js code, you may have to do it manually.

That's not quite what I was getting at. You're right about needing the
context in order to escape correctly though. I think the default escaping
should include single and double quotes. cgi.escape escapes double quotes
but not single quotes.

I thought that the default escaping was going through cgi.escape by way of
the xmlescape method, but given the below, that appears to not be the case.
I'm a little confused.

Here's an example of something I don't think I should be able to do:

Controller:         return dict(data='" onload="alert(1);" bad="')
View:               <body class="{{=data}}"></body>
Output:            <body class="" onload="alert(1);" bad=""></body>

The same attack works with single quoted attributes. While you're right, we
can't do full proper escaping without knowing the context, I don't think
quotes should be permitted in any web context.
-- 
Craig Younkins

Reply via email to