[Esapi-user] Validation fields with JSF

Chris Schmidt chrisisbeef at gmail.com
Thu Feb 25 23:25:10 EST 2010


1) Sorry - I misplaced that one, that should have been in the EJB or Service
Layer.

2) A service layer goes between your application and it's model - it makes
it possible to do things like "hot-swap" what the model is without
disturbing the application logic at all. This would be where you would have
things like a Facade or Factory that actually delegates the work of whatever
you are actually trying to do (store or retrieve data usually)  So you would
have something like this:

/* Application Code */
...
CarDataService cds = CarDataServiceFactory.getInstance().getService();
Car car = cds.getCar( "2002", "Audi", "A4" );

/** Service Layer */
public class CarDataServiceFactory implements ServiceFactory<CarDataService>
{
   public CarDataService getService() {
      return new EJBCarDataService();
   }
}

This is a really bare minimum example, but it allows a lot of flexibility in
the application itself. This probably isn't seen much in smaller
applications, but is something you might (or iMHO should) see in larger
enterprisey projects.

On Thu, Feb 25, 2010 at 1:04 PM, Sebastian <smarichal at seciu.edu.uy> wrote:

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


-- 
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/20100225/a8cf87a1/attachment.html 


More information about the Esapi-user mailing list