On Wed, Jun 10, 2009 at 4:45 PM, Oliver Lambert <olambo...@gmail.com> wrote:

> On Wed, Jun 10, 2009 at 11:58 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>> On Tue, Jun 9, 2009 at 11:39 PM, marius d. <marius.dan...@gmail.com>wrote:
>>> Hi,
>>> For most apps cannonicalization is not really necessary as the
>>> character stream for form-url-encoded is UTF-8 by default as Lift uses
>>> UTF-8 by default. Oh and the conversion from URL encoding to plain
>>> UTF-8 content is really done by container and when we get the params
>>> from the request object they are already well formed. Now if we're
>>> talking about a higher level of validation that's a different story
>>> and IMO this is an application aspect and not much a framework one.
>> And Lift does URL Decoding of the paths before presenting them as the
>> Req() object.
>> More broadly, Lift should provide all the features of ESAPI out of the
>> box.  If there are particular things that ESAPI offers that Lift doesn't,
>> please flag them and we'll add them.
>> I did a bunch of years as VPE and CTO at a web app security company.  In
>> general, I've worked to make sure that Lift has security baked in and that
>> the developer has to work to make the app insecure, rather than vice versa.
>>  If I missed a spot, Lift will be enhanced to make sure it does have
>> security baked in.
> From my perspective Lift is secure, much more so than other frameworks I've
> used. The current set of Lift apps, that I've helped develop, have survived
> outsourced penetration testing without requiring any modifications at all.
> Great!
> I'm not a security expert, but I am being asked to consider ESAPI features.
> From my limited understanding, the UTF-8 encoding is fine and Lift protects
> the response from displaying any scripts or html that might have
> inadvertently been added to the database.  The problem is more what is being
> validated and how its being validated. I don't buy Marius's claim that this
> is somehow a higer order validation that is an application concern rather
> than a framework one. The internet has all the insecurities it has, because
> security has been left to the application developer.
> As far a I can see, one problem lies when a string is obtained from the web
> page and instanciated into a String object.  For instance, if it comes in as
> <script>alert('XSS')</script>, then its probably not what you want.

I see no reason that you don't want this.  As long as it's a String, it will
be XML escaped when it's presented to the user.  Unless this String were put
into an Unparsed block (some affirmative action by the developer), it would
always appear to the user the way the user typed it.  This is the advantage
of keeping everything as XML until just before the page is delivered to the

> Why does it matter if something like this gets stored in your database -
> perhaps because it's one part of your security.  In addition if it comes in
> doubly encoded as
> %253Cscript%253Ealert('XSS')%253C%252Fscript%253E
> then its probably also not what you want.
> 1) To stop double encoding, ESAPI suggests that you use cannonicalization
> to convert the strings to a similar format before validation.

Lift is fact does this.  Lift and/or the app server converts the bytes to
Strings using UTF-8 encoding and then splits and URL-decodes the Strings
before delivering them to the application.  The application always sees the
String as the user typed the String.  All validation is done against Strings
that have been decoded the same way.

> 2) After, the input has been cannonicalized, ESAPI suggests that the input
> should be validated against a whitelist of allowed charaters.

I disagree with this recommendation within the bounds of a Lift app.
Strings in Java survive having \00 characters.  They are impurvious to
buffer overflow attacks.  Strings are escaped before being used as part of
queries by the JDBC and/or JPA systems (unless the developer explicitly
builds their own query string, which requires that the developer sign and
date the code and is a place where one can grep for the construct during a
code review.)  Strings back out to XML or XHTML will be escaped properly,
unless the developer uses Unparsed() in rendering... once again, something
that can be easily checked for in a code review.

The above rules don't apply to PHP or other code that builds queries from
raw Strings.  The above rules don't apply to any templating system (all that
I know of except perhaps Seaside) that emits Strings or byte strings from
templates rather than well formed XML.

So, personally, I would be interested in seeing what ESAPI does that Lift
doesn't already do.



> Now, I can't see that 1 or 2 is necessary if you are creating a number from
> the input, but perhaps it should be, if you are creating a ordinary String
> object. I also am not sure how much work would be involved in using a
> whitelist in a location aware multilingual way, but perhaps it could be done
> as a default.
>>> Br's,
>>> Marius
>>> On Jun 10, 5:43 am, Oliver Lambert <olambo...@gmail.com> wrote:
>>> > Looks like I might have a requirement for implementing OWASP secure
>>> coding
>>> > practices, as described by
>>> >
>>> > One thing that I definitively don't do and I believe Lift doesn't do
>>> out of
>>> > the box is Canonicalize input
>>> > before validation/filtering. I was looking into using OWASP
>>> > ESAPI<http://www.owasp.org/index.php/ESAPI>but I'm put off by it's use
>>> > of
>>> > property files and system resources.  Do any of you Canonicalize input,
>>> if
>>> > so, do you use a Library? Does Lift
>>> > need this feature, or any of the others described in the above
>>> document?
>>> >
>>> > cheers
>>> > Oliver
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
> >

Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to