Well put John - mirrors most of what I was going to say. <div><br></div><div>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:</div>
<div><br></div><div>View (JSF/JSP)</div><div>- Client-side validation already discussed</div><div><br></div><div>Controller (Servlets/Filters)</div><div>- Controllers verify that no &quot;dangerous&quot; data has been sent on the request (Validate no XSS, HTML, etc.)</div>
<div>- Business Layer (Facades, Helpers, Commands, etc) validate against specific set of requirements and validate against runtime attributes.</div><div>- Verifies that authentication and access for the requested actions</div>
<div><br></div><div>Model (Service Layer to EJB)</div><div>- Validates that all required information is submitted for a service call</div><div>- Validates that it is being called from an authenticated source (SecurityManager)<br>
<br></div><div>EJB</div><div>- Validates that all required information is submitted for a service call</div><div>- Validates that it is being called from an authenticated source (SecurityManager)</div><div><br></div><div>
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. </div>
<div><br></div><div>Basic philosophy is to always validate in the context of the current layer of the application, don&#39;t validate the entire flow of an operation and it&#39;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.</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On Wed, Feb 24, 2010 at 9:45 AM, John Melton <span dir="ltr">&lt;<a href="mailto:jtmelton@gmail.com">jtmelton@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sebastian, <br>As I see it, you&#39;re talking specifically about validation here, which is but one of ESAPI&#39;s features.  JSF has a number of built in validators that work perfectly well if that&#39;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&#39;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&#39;ll have to do some of that work yourself.<br>



Also, we&#39;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.  <br>


As for whether to put the validation in your web-app vs. EJB, that&#39;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&#39;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.<br>


Hope this helps.<br><font color="#888888">
-jm</font><div><div></div><div class="h5"><br><div class="gmail_quote">On Wed, Feb 24, 2010 at 11:24 AM, Sebastian <span dir="ltr">&lt;<a href="mailto:smarichal@seciu.edu.uy" target="_blank">smarichal@seciu.edu.uy</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">


David:<br>
<br>
I&#39;ve been investigating this for a month and i&#39;ve read a lot of<br>
ESAPI-OWASP documents, what is more, actually im using CSRFGuard in<br>
order to prevent CSRF attacks. I know about the existance of encoders<br>
and validators provided by ESAPI. In the document &quot;OWASP Top Ten For<br>
JAVAEE&quot; says this:<br>
<br>
Use JSF validation server-side:<br>
o f:validateLength for the allowed length of input<br>
&lt;f:validateLength minimum=&quot;2&quot; maximum=&quot;10&quot;/&gt;<br>
o &lt;h:inputText required=”true”&gt; if an input field is required<br>
<br>
So you recomend no to use this? You recomend call ESAPI functions in the<br>
backing bean code ?<br>
I think that ESAPI validators has a good point because it is capable to<br>
detect attacks too...<br>
<br>
<br>
<br>
David Sklarew wrote:<br>
&gt; Sebastian,<br>
<div>&gt;<br>
&gt;<br>
&gt;&gt;&gt; &quot; I&#39;ll apreciate it you can tell me if it is<br>
&gt;&gt;&gt;<br>
&gt; better validate the fields using &lt;f:validate&gt; or &lt;h:inputText<br>
&gt; required=&#39;true&#39;&gt;<br>
&gt;<br>
</div>&gt; This is the ESAPI mailing list and hopefully most members would agree that<br>
&gt; you could use the EASPI Java library (the latest 2.X version is recommended<br>
&gt; over the 1.x verion) to validate input and to encode all variable output<br>
&gt; included in your webpages ( to prevent Cross Site Scripting Attacks).  The<br>
&gt; OWASP website has a good wiki page on preventing cross site scripting<br>
&gt; attacks..<br>
&gt;<br>
&gt; David<br>
<div><div></div><div>&gt;<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:esapi-user-bounces@lists.owasp.org" target="_blank">esapi-user-bounces@lists.owasp.org</a><br>
&gt; [mailto:<a href="mailto:esapi-user-bounces@lists.owasp.org" target="_blank">esapi-user-bounces@lists.owasp.org</a>] On Behalf Of Sebastian<br>
&gt; Sent: Wednesday, February 24, 2010 10:05 AM<br>
&gt; To: <a href="mailto:esapi-user@lists.owasp.org" target="_blank">esapi-user@lists.owasp.org</a><br>
&gt; Subject: [Esapi-user] Validation fields with JSF<br>
&gt;<br>
&gt; Hi everybody, im new in the esapi-user list.<br>
&gt;<br>
&gt; Actually im investigating security configurations for a JavaEE + JSF<br>
&gt; application.<br>
&gt; The system has 2 components, a EJB Proyect called &quot;Logica&quot; and a<br>
&gt; presentation component called &quot;WebComponent&quot;.<br>
&gt; So, the validations in the pages of WebComponent are done with<br>
&gt; JavaScript. And when the data arrives to &quot;Logica&quot; then it is validated<br>
&gt; again (server side).<br>
&gt; I would like to ask you if it is necesary validate fields in the<br>
&gt; &quot;WebComponent&quot; on server side, not only JavaScript. Why?<br>
&gt; And if the answer is &quot;Yes&quot; I&#39;ll apreciate it you can tell me if it is<br>
&gt; better validate the fields using &lt;f:validate&gt; or &lt;h:inputText<br>
&gt; required=&#39;true&#39;&gt; or just validate in the code of the BackingBean ??<br>
&gt;<br>
&gt; Thanks you very much!<br>
&gt;<br>
&gt; Sebastian<br>
&gt; _______________________________________________<br>
&gt; Esapi-user mailing list<br>
&gt; <a href="mailto:Esapi-user@lists.owasp.org" target="_blank">Esapi-user@lists.owasp.org</a><br>
&gt; <a href="https://lists.owasp.org/mailman/listinfo/esapi-user" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-user</a><br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
Esapi-user mailing list<br>
<a href="mailto:Esapi-user@lists.owasp.org" target="_blank">Esapi-user@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/esapi-user" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-user</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Esapi-user mailing list<br>
<a href="mailto:Esapi-user@lists.owasp.org">Esapi-user@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/esapi-user" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-user</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Chris Schmidt<br><br>OWASP ESAPI Developer<br><a href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API">http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API</a><br>
<br>Check out OWASP ESAPI for Java<br><a href="http://code.google.com/p/owasp-esapi-java/">http://code.google.com/p/owasp-esapi-java/</a><br><br>OWASP ESAPI for JavaScript<br><a href="http://code.google.com/p/owasp-esapi-js/">http://code.google.com/p/owasp-esapi-js/</a><br>
<br>Yet Another Developers Blog<br><a href="http://yet-another-dev.blogspot.com">http://yet-another-dev.blogspot.com</a><br><br>Bio and Resume<br><a href="http://www.digital-ritual.net/resume.html">http://www.digital-ritual.net/resume.html</a><br>
<br>
</div>