[Esapi-user] Validation fields with JSF

Sebastian smarichal at seciu.edu.uy
Fri Feb 26 12:10:10 EST 2010


ok, thanks you very much!
Chris Schmidt wrote:
> 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 
> <mailto: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>
>         <mailto: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>
>         <mailto: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>>
>                > [mailto: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>
>                <mailto: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>
>         <mailto: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>
>         <mailto: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>
>         <mailto: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
>



More information about the Esapi-user mailing list