[Esapi-user] Validation fields with JSF

Mike Boberski mike.boberski at gmail.com
Wed Feb 24 22:04:19 EST 2010


I'd thought the value of client-side validation was when the client was
acting as a server...

Mike


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

> 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
>>
>
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100224/ed948520/attachment.html 


More information about the Esapi-user mailing list