[Esapi-user] Validation fields with JSF

John Melton jtmelton at gmail.com
Wed Feb 24 21:47:10 EST 2010


Jeff,
Just a thought ... this might depend on how you define your user group.
Your point may be true in some settings, but on many sites, you're bound to
have folks using the site w/ javascript disabled in the browser, which would
disable the client-side validation protections.  Since many applications
still have to function under these circumstances, and users that have
javascript disabled aren't bad per se, I wouldn't say that it's *always* an
indicator of illegitimate use.
-John

On Wed, Feb 24, 2010 at 9:34 PM, Jeff Williams <
jeff.williams at aspectsecurity.com> wrote:

>  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/5885bdb6/attachment.html 


More information about the Esapi-user mailing list