I fight UFC Style.. *g*<br><br>Comments inline<br><br><div class="gmail_quote">On Fri, May 7, 2010 at 7:12 PM, Kevin W. Wall <span dir="ltr">&lt;<a href="mailto:kevin.w.wall@gmail.com">kevin.w.wall@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">Jim Manico wrote:<br>
&gt;&gt; Jim you are absolutely right - but there are some cases where you need<br>
&gt; the *big hammer* approach.<br>
&gt;<br>
&gt; You are starting to sound like a WAF vendor. I think Imperva is hiring<br>
&gt; for sales....<br>
&gt;<br>
&gt; *ducks*<br>
<br>
</div>Ouch! Let&#39;s keep this a clean fight. No more hitting below the belt. :)<br>
<div class="im"><br>
&gt; &lt;soapbox&gt;<br>
&gt; Comon boys - Risk Management is often used to justify NOT doing the<br>
&gt; right thing. Around these parts we OUTPUT ENCODE CONTEXTUALLY FOR ALL<br>
&gt; OUTPUT. NOTHING ELSE STOPS XSS.<br>
&gt; &lt;/soapbox&gt;<br>
<br>
</div>Jim is right. Remember the 4th point of the Rugged Software Manifesto:<br>
        I recognize that my code will e used in ways I cannot anticipate,<br>
        in ways it was not designed, and for longer than it was ever<br>
        intended.<br>
<br></blockquote><div><br>One of the thing about manifesto&#39;s, philosophies, and coding paradigms is that they are fantastic out the gate, but if you are working with an established enterprise application, in a relatively agile environment, for a conversion based corp - it is very difficult to justify the risk vs. reward for changing a lot of existing *working* code that is making money to fully integrate a security framework that is *unproven* in your environment. This is the very situation that I am basing a good deal of my ESAPI training on, because while I know we *all* dream of having the luxury of creating an application from the ground up, the reality is that more often than not you come into an existing project, with a ton of legacy code, and a lot of policies and procedures that limit your ability to do things the &quot;right way&quot;<br>
<br>In these situations, I have found that doing something that provides short-term gain with very little risk is an effective strategy for opening the door to further changes. <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

That means that even if a filter will work _today_ in your code, there is<br>
no guarantee that it will work in the future. As soon as someone starts<br>
putting user input in some other context such as a CSS, then your filter<br>
will not work and your XSS problems are back.<br>
<br></blockquote><div><br>You are absolutely correct, and in most applications, those places where it absolutely does not work, and in some cases makes things worse are the places that you will get your opportunity to do it the &quot;right way&quot; and give the framework the opportunity to prove itself in terms of effectiveness, ease of implementation, and reward. <br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It takes a lot of effort to do write the code right...but not nearly as<br>
much effort as it does if you write the code wrong.<br>
<br></blockquote><div><br>That is one of the differences I think, I don&#39;t really consider the big hammer approach to be *wrong* per se. I consider it to be a starting point and a point to build off of. The filter that I use in our application does indeed use a filter, that started out as the basics of what was above. As the filtered was mapped over various components of our application we extended the filter itself to provide additional functionality and consider the context and state of the request when encoding. What we ended up with was a filter that wrapped our request with a powerful and extendable wrapper that in the end was used by tags to render the encoded information in the correct context. <br>
<br>The tags are now the defacto way that information on the request and session is accessed, and intelligent enough to use the request wrapper if it is present, consider the state of the request itself (as well as the source of the request - ie AJAX, jsp:include, GET/POST, etc.) that we now have a correctly implemented encoding strategy in place that is tuned to our application.<br>
<br>Now, while this may not be the answer for *everyone* it was the answer for me - and it works well, and more importantly it proved itself iteratively which was important to management. <br><br>At the end of the day, we all have our own visions of &quot;The Perfect Codebase&quot; and anyone who has been an engineer for any length of time knows that the perfect codebase is a unicorn. We constantly have to adapt and make decisions and sometimes we have to write shortcuts to make sure that something more important gets completed. These are just the realities of the job, and it is just as important to make sure that your application security practices can fit the bill for *any* application, not just the great ones. :)<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
-kevin<br>
<font color="#888888">--<br>
Kevin W. Wall<br>
&quot;The most likely way for the world to be destroyed, most experts agree,<br>
is by accident. That&#39;s where we come in; we&#39;re computer professionals.<br>
We cause accidents.&quot;        -- Nathaniel Borenstein, co-creator of MIME<br>
</font></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>