This looks to be a very significant selling point for Lift.  I realize there
are some high level comments about Lift being designed for security, but I
haven't seen any details explaining what measures have been put in place to
qualify those statements.  This is a prime example of what should be put
into some "marketing detail" pages on the wiki.  I would love to see a
writeup covering these security measures exhaustively.

On Sat, Jun 13, 2009 at 4:47 PM, David Pollak <feeder.of.the.be...@gmail.com
> wrote:

>
>
> 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 user.
>
>
>> 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.
>
> Thanks,
>
> David
>
>
>>
>>
>> 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 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to