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 email@example.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 -~----------~----~----~----~------~----~------~--~---