On Wed, Jun 10, 2009 at 11:58 PM, David Pollak < [email protected]> wrote:
> > > On Tue, Jun 9, 2009 at 11:39 PM, marius d. <[email protected]>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. 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. > >> >> Br's, >> Marius >> >> On Jun 10, 5:43 am, Oliver Lambert <[email protected]> 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 > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
