[Esapi-user] [OWASP-ESAPI] Implementation of Global Output Encoder with ESAPI

Chris Schmidt chrisisbeef at gmail.com
Fri May 7 22:24:47 EDT 2010

I fight UFC Style.. *g*

Comments inline

On Fri, May 7, 2010 at 7:12 PM, Kevin W. Wall <kevin.w.wall at gmail.com>wrote:

> Jim Manico wrote:
> >> Jim you are absolutely right - but there are some cases where you need
> > the *big hammer* approach.
> >
> > You are starting to sound like a WAF vendor. I think Imperva is hiring
> > for sales....
> >
> > *ducks*
> Ouch! Let's keep this a clean fight. No more hitting below the belt. :)
> > <soapbox>
> > Comon boys - Risk Management is often used to justify NOT doing the
> > right thing. Around these parts we OUTPUT ENCODE CONTEXTUALLY FOR ALL
> > </soapbox>
> Jim is right. Remember the 4th point of the Rugged Software Manifesto:
>        I recognize that my code will e used in ways I cannot anticipate,
>        in ways it was not designed, and for longer than it was ever
>        intended.
One of the thing about manifesto'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 "right way"

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.

> That means that even if a filter will work _today_ in your code, there is
> no guarantee that it will work in the future. As soon as someone starts
> putting user input in some other context such as a CSS, then your filter
> will not work and your XSS problems are back.
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 "right way" and give
the framework the opportunity to prove itself in terms of effectiveness,
ease of implementation, and reward.

> It takes a lot of effort to do write the code right...but not nearly as
> much effort as it does if you write the code wrong.
That is one of the differences I think, I don'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.

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

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.

At the end of the day, we all have our own visions of "The Perfect Codebase"
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.

> -kevin
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

Chris Schmidt


Check out OWASP ESAPI for Java

OWASP ESAPI for JavaScript

Yet Another Developers Blog

Bio and Resume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100507/6ca74472/attachment.html 

More information about the Esapi-user mailing list