[Esapi-user] Validation fields with JSF

Sebastian smarichal at seciu.edu.uy
Thu Feb 25 15:04:56 EST 2010


Thanks you everybody, you really helped me giving very good and accurate 
answers.
Chris, i don't understand some of your layer separations.

* When you say that Business Layer validate against specific set of 
requerimients in the "Controller (Servlet/Filters)" layer, what do you 
mean? Validation of types like email inputs validated with regular 
expresions? Business shouldn't be in the EJB component?

* Which is the diference between Model (Service Layer to EJB) and EJB layer?


I tried to integrate ESAPI validator functions with JSF Validator, so I 
constructed my own JSF Validator (the class must impement the 
javax.faces.validator.Validator) and into the logic of the "validate" 
method i called ESAPI validator functions. It works perfectly, so i 
found a way to use ESAPI Validator and JSF Validator with an easy way to 
show error messages to the user. I was really simple!!

Thanks!!

Sebastián

Chris Schmidt wrote:
> 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 
> <mailto: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 <mailto: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>
>         > [mailto: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
>         <mailto: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 <mailto:Esapi-user at lists.owasp.org>
>         > https://lists.owasp.org/mailman/listinfo/esapi-user
>         >
>         >
>
>         _______________________________________________
>         Esapi-user mailing list
>         Esapi-user at lists.owasp.org <mailto:Esapi-user at lists.owasp.org>
>         https://lists.owasp.org/mailman/listinfo/esapi-user
>
>
>
>     _______________________________________________
>     Esapi-user mailing list
>     Esapi-user at lists.owasp.org <mailto: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
>



More information about the Esapi-user mailing list