[Lift] Re: Security Explained

[aw]

Thank you for this, and so quickly!  I was able to leverage this for
what I needed.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: Security Explained

[David Pollak]

On Thu, Oct 22, 2009 at 4:54 PM, Randinn  wrote:

>
> I've been pondering this for some time, could an actor be used as a
> cookie,


No


> if so would that render the stealing attack mote?
>
> >7. Lift uses the container's session management (usually JSESSIONID)
> for
> >session management.  As far as I know, Jetty, Tomcat, Glassfish are
> secure
> >in terms of the way they deal with sessions.  Of course, anything
> that's not
> >over SSL is vulnerable to a cookie stealing attack.
>
> >
>


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

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: Security Explained

[Randinn]

I've been pondering this for some time, could an actor be used as a
cookie, if so would that render the stealing attack mote?

>    7. Lift uses the container's session management (usually JSESSIONID) for
>    session management.  As far as I know, Jetty, Tomcat, Glassfish are secure
>    in terms of the way they deal with sessions.  Of course, anything that's 
> not
>    over SSL is vulnerable to a cookie stealing attack.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: Security Explained

[David Pollak]

On Thu, Oct 22, 2009 at 10:49 AM, aw  wrote:

>
> My company is looking for an explanation of how Lift is secure.
>
> I recall reading a comment saying that Lift deals well with most of
> the Top 10 OWASP vulnerabilities (http://www.owasp.org/index.php/
> Top_10_2007 ), but how?
>  Most, not all?  Are there strategies that are
> recommended to deal with the weaknesses?
>

Quickly:

   1. Lift is resistant to XSS attacks.  By default pages are composed in
   XML rather than Strings.  It takes the developer extra work to insert XSS
   strings into output rather than having to make sure each String is properly
   escaped before being cat'ed to the output.
   2. Lift is resistant to SQL Injection attacks because mapper and JPA do
   not compose Strings into SQL statements, but rather bind well typed
   parameters into prepared statements.  So, if you go the normal path, you get
   SQL injection resistance.  If you want to manually craft a String to send as
   a query, in mapper you have to "sign" the string with the time, date and a
   certification that you've reviewed the String for SQL Injection problems.
   3. Lift never shells out.  You can't cause a file to be executed from a
   Lift app unless your app manually uses Java's Runtime.execute() call.
   4. By default, Lift creates opaque GUIDs to refer to components on the
   server side (whether that's a function to execute when a form field is
   submitted, what to do on an Ajax call, etc.)  By default, it's easier to use
   this callback mechanism than advertise a primary key or other sensitive
   piece of information.  Lift also has the KeyObfuscator which will create a
   session-specific mapping of primary keys to opaque ids.  Using
   KeyObfuscator, you can send JSON objects to the client with stable primary
   keys that are obfuscated and not usable outside the current session.
   5. By default Lift's form fields contain GUIDs that are cryptographically
   impossible to predict.  It's not possible to do CSRF because one does not
   know the name of form fields (they are not stable)
   6. Lift has different production vs. development mode error messages.
   There's little information that leaks about underlying configurations, even
   exceptions, in production mode.
   7. Lift uses the container's session management (usually JSESSIONID) for
   session management.  As far as I know, Jetty, Tomcat, Glassfish are secure
   in terms of the way they deal with sessions.  Of course, anything that's not
   over SSL is vulnerable to a cookie stealing attack.
   8. Crypto key storage is a container-level issue.  See #7
   9. See #7
   10. Lift's sitemap is the best and most secure integration of UI and
   page-level access.  You can look at the sitemap to determine the access
   control rules for a given page (it's declarative) and it's enforced long
   before your page gets accessed.

Hope this helps.


>
> I am very interested in a Wiki post that explains how Lift addresses
> the top 10 vulnerabilities.  (No pressure, but I needed this
> yesterday.)  Please point me to any existing resource/documentation
> that explains this.
>
> Very often, I see points that mention how secure Lift is, and I
> certainly appreciate the fact that Lift promotes security as a core
> initiative.  I can also see how secure it is compared to other
> strategies (yeah, you heard me ColdFusion!).  Keep up the good work.
>
>
> Does anybody have experience submitting Lift Apps to third party
> security assessment or vulnerability analysis?  Any tips from that
> experience?
>
> >
>


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

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: security

[James Matlik]

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  wrote:

>
>
> On Wed, Jun 10, 2009 at 4:45 PM, Oliver Lambert 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. 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
>> alert('XSS'), 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

[Lift] Re: security

[David Pollak]

On Wed, Jun 10, 2009 at 4:45 PM, Oliver Lambert  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. 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
> alert('XSS'), 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 pe

[Lift] Re: security

[marius d.]

On Jun 11, 2:45 am, Oliver Lambert  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. 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 "alert
('XSS')" 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
> alert('XSS'), 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  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
> >> > ESAPIbut 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 un

[Lift] Re: security

[Oliver Lambert]

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. 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
alert('XSS'), 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  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
>> > ESAPIbut 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 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
-~--~~~~--~~--~--~---

[Lift] Re: security

[David Pollak]

On Tue, Jun 9, 2009 at 11:39 PM, marius d.  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.


>
>
> Br's,
> Marius
>
> On Jun 10, 5:43 am, Oliver Lambert  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
> > ESAPIbut 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 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
-~--~~~~--~~--~--~---

[Lift] Re: security

[marius d.]

Oh and about XSS Lift is safe by default.

Marius

On Jun 10, 9:39 am, "marius d."  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.
>
> Br's,
> Marius
>
> On Jun 10, 5:43 am, Oliver Lambert  wrote:
>
> > Looks like I might have a requirement for implementing OWASP secure coding
> > practices, as described by
>
> >http://www.sans.org/reading_room/whitepapers/application/rss/appsec_p...
>
> > 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
> > ESAPIbut 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Lift] Re: security

[marius d.]

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.

Br's,
Marius

On Jun 10, 5:43 am, Oliver Lambert  wrote:
> Looks like I might have a requirement for implementing OWASP secure coding
> practices, as described by
>
> http://www.sans.org/reading_room/whitepapers/application/rss/appsec_p...
>
> 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
> ESAPIbut 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---