On Jun 11, 2:45 am, 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.

The eligibility criteria from a "web-string" to be converted to String
object may differ greatly from application to application. This is why
so fat I disagree with you. In some contexts receiving "<script>alert
('XSS')</script>" string is what application wants. Sometimes it is
not. Besides lift already protects us from XSS in great extent.

>
> 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.  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.
> 2) After, the input has been cannonicalized, ESAPI suggests that the input
> should be validated against a whitelist of allowed charaters.
>
> 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.

I have nothing against ESAPI but as far as I'm concerned more
compelling and concrete use cases are needed for it to be incorporated
into the framework. As David said if there is a security hole
somewhere we're keen to know about it and fix it immediately.

>
>
>
> >> 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 frameworkhttp://liftweb.net
> > Beginning Scalahttp://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