[Esapi-user] Validation fields with JSF

Jeff Williams jeff.williams at aspectsecurity.com
Wed Feb 24 21:34:45 EST 2010


One quick thought about client-side validation.  If you validate on the
client, then legitimate users should *never* generate validation errors
on the server.  So if you get one, you can be much harsher with your
response.

 

--Jeff

 

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Jeff Williams
Sent: Wednesday, February 24, 2010 12:10 PM
To: Chris Schmidt; John Melton
Cc: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] Validation fields with JSF

 

Ideally, developers could stick with the security controls that are part
of the framework they are using, in this case, JSF validators.  The
problem arises when those features aren't as good as they could be.
None of the validation frameworks out there (that I'm familiar with)
perform canonicalization before they validate.

 

So now we're left with a choice - use JSF validators (fill in your
framework here) without canonicalization and give up the intrusion
detection benefit.  Or, use ESAPI and suffer through a less convenient
mechanism.

 

The long-term solution is to integrate the ESAPI controls into the
frameworks, such as wrapping the ESAPI validators in JSF validators so
they can be used easily.  We're looking for help doing this if anyone
has time and wants to get involved.

 

Thanks!

 

--Jeff

 

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Wednesday, February 24, 2010 11:56 AM
To: John Melton
Cc: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] Validation fields with JSF

 

Well put John - mirrors most of what I was going to say. 

 

It should be noted however, that within your Webapp you should and
likely will have different validations in different layers of the
application. For instance:

 

View (JSF/JSP)

- Client-side validation already discussed

 

Controller (Servlets/Filters)

- Controllers verify that no "dangerous" data has been sent on the
request (Validate no XSS, HTML, etc.)

- Business Layer (Facades, Helpers, Commands, etc) validate against
specific set of requirements and validate against runtime attributes.

- Verifies that authentication and access for the requested actions

 

Model (Service Layer to EJB)

- Validates that all required information is submitted for a service
call

- Validates that it is being called from an authenticated source
(SecurityManager)

EJB

- Validates that all required information is submitted for a service
call

- Validates that it is being called from an authenticated source
(SecurityManager)

 

As you can see the Service Layer to the EJB and the EJB have the same
types of validation, however, the context of that validation can be
different for each, therefore you will generally not want to rely on one
or the other. 

 

Basic philosophy is to always validate in the context of the current
layer of the application, don't validate the entire flow of an operation
and it's data at any one level as you will likely run into a situation
where that same block of code needs to execute in a different context
and your validation logic is either broken or has to be hacked to accept
the new context.

 

 

 

On Wed, Feb 24, 2010 at 9:45 AM, John Melton <jtmelton at gmail.com> wrote:

Sebastian, 
As I see it, you're talking specifically about validation here, which is
but one of ESAPI's features.  JSF has a number of built in validators
that work perfectly well if that's the route you choose.  Namely, the
required, length and range validators are simple validations and the JSF
versions work fine and provide similar security to the equivalent
validators in ESAPI, so pick whichever you like.  However, as you get
into more complex validations (such as banned character/word, and
business specific data validations) , there are good reasons to use
ESAPI including the fact that JSF does not have those types of
validation out of the box.  One important point to note about JSF
specifically is that it's built-in validators already do the work of
detecting a problem and then placing the error messages in the right
scope for display to the user.  If you choose to use ESAPI, you'll have
to do some of that work yourself.
Also, we're specifically talking about input validation in this example,
but as you get into other common issues such as output encoding, ESAPI
does a more thorough job than most any other framework, including JSF.  
As for whether to put the validation in your web-app vs. EJB, that's up
to your business.  The general rule of thumb I follow is to put the
validations as early as I can in the process where security is still
ensured.  In other words, if you are sure your webapp is the only one
accessing the EJB, then I would put the validations in the webapp,
otherwise they need to go in the EJB.  Another point to note is that
your programming should be defensive, meaning you should validate that
the EJB has the appropriate inputs to perform it's job whether or not
you do full validation there.  One reason I suggest validating in the
webapp is that most web frameworks (including JSF) already have
mechanisms to support validation and error reporting to the end user,
whereas EJB does not.
Hope this helps.
-jm

 

On Wed, Feb 24, 2010 at 11:24 AM, Sebastian <smarichal at seciu.edu.uy>
wrote:

David:

I've been investigating this for a month and i've read a lot of
ESAPI-OWASP documents, what is more, actually im using CSRFGuard in
order to prevent CSRF attacks. I know about the existance of encoders
and validators provided by ESAPI. In the document "OWASP Top Ten For
JAVAEE" says this:

Use JSF validation server-side:
o f:validateLength for the allowed length of input
<f:validateLength minimum="2" maximum="10"/>
o <h:inputText required="true"> if an input field is required

So you recomend no to use this? You recomend call ESAPI functions in the
backing bean code ?
I think that ESAPI validators has a good point because it is capable to
detect attacks too...



David Sklarew wrote:
> Sebastian,

>
>
>>> " I'll apreciate it you can tell me if it is
>>>
> better validate the fields using <f:validate> or <h:inputText
> required='true'>
>

> This is the ESAPI mailing list and hopefully most members would agree
that
> you could use the EASPI Java library (the latest 2.X version is
recommended
> over the 1.x verion) to validate input and to encode all variable
output
> included in your webpages ( to prevent Cross Site Scripting Attacks).
The
> OWASP website has a good wiki page on preventing cross site scripting
> attacks..
>
> David

>
>
>
> -----Original Message-----
> From: esapi-user-bounces at lists.owasp.org
> [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Sebastian
> Sent: Wednesday, February 24, 2010 10:05 AM
> To: esapi-user at lists.owasp.org
> Subject: [Esapi-user] Validation fields with JSF
>
> Hi everybody, im new in the esapi-user list.
>
> Actually im investigating security configurations for a JavaEE + JSF
> application.
> The system has 2 components, a EJB Proyect called "Logica" and a
> presentation component called "WebComponent".
> So, the validations in the pages of WebComponent are done with
> JavaScript. And when the data arrives to "Logica" then it is validated
> again (server side).
> I would like to ask you if it is necesary validate fields in the
> "WebComponent" on server side, not only JavaScript. Why?
> And if the answer is "Yes" I'll apreciate it you can tell me if it is
> better validate the fields using <f:validate> or <h:inputText
> required='true'> or just validate in the code of the BackingBean ??
>
> Thanks you very much!
>
> Sebastian
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>
>

_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user

 


_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user




-- 
Chris Schmidt

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/

Yet Another Developers Blog
http://yet-another-dev.blogspot.com

Bio and Resume
http://www.digital-ritual.net/resume.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100224/1851d7be/attachment.html 


More information about the Esapi-user mailing list