[Esapi-user] [OWASP-ESAPI] Implementation of Global OutputEncoder with ESAPI

Jeff Williams jeff.williams at aspectsecurity.com
Sat May 8 22:00:45 EDT 2010

Obviously the best way to do things would be to validate near where the
data comes in and escape near where the data goes out. And  I can
imagine some applications where this would be difficult to make happen.


Nevertheless, I don't think that that the suggested approach is really a
*big hammer* - it's more like a wet blanket.  And it's not likely to
make anyone happy.  Here's what's going to happen.


*        You're going to mess up your database, because now all the data
will be escaped, and queries and sort order will be screwy.


*        You're going to mess up your HTML, since anywhere that already
escaped properly will now "double escape" and will show up as visible
HTML code.


*        You're NOT going to solve XSS, since HTML entity escaping won't
stop XSS attacks for any data that falls outside normal HTML, such as
Javascript, CSS, or URLs.





From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Friday, May 07, 2010 7:25 PM
To: Jim Manico
Cc: owasp-esapi at lists.owasp.org; esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] [OWASP-ESAPI] Implementation of Global
OutputEncoder with ESAPI


Jim you are absolutely right - but there are some cases where you need
the *big hammer* approach... I can vouch for that - especially as a
means of getting ESAPI into the door and implemented in a bloated and
ever evolving enterprise codebase. 

I am not saying this is the *right* way to do things, and I pointed out
in the last part of my reply that while this works for a big hammer
approach it is *not* 100% reliable and it is not quite so daunting to
carve out sections of a site and implement the tags or scriptlet to do
it correctly.. :)

Sometimes you gotta prove that something helps when it is used in not
quite the 100% quite correct way just to get it in so you can do things
correctly... You've worked with stubborn managers before.. *g*

On 5/7/2010 5:17 PM, Jim Manico wrote: 

>  You just create an HttpServletRequestWrapper that returns the encoded

Beef... Noooooo!

I can't agree with that. This filter method only encodes data in the
HTML body context - leaving all other display contexts vulnerable to

I implore you to manually encode each variable per
n_Cheat_Sheet>  - you can even come up with a few regular expressions to
do mass search-and-replace for some cases.

My 2 cents,

Ramesh - (Please use the ESAPI-USER list - this list is deprecated.)

You just create an HttpServletRequestWrapper that returns the encoded

public class MyWrapper extends HttpServletRequestWrapper {
   public String getParameter(String key) {
      try {
         return ESAPI.encoder().encodeForHTML( super.getParameter( key )
      } catch ( Exception e ) {
         ESAPI.getLogger( "MyWrapper" ).error(
org.owasp.esapi.Logger.EVENT_FAILURE, "Unable to encode value", e );
      return null;

Obviously, this is a overly simplified version, but it conveys the

I am curious what you are going for by re-encoding for HTML,
HTMLAttribute, CSS, and JS?

I understand the desire to not have to make changes to a *ton* of jsps
to get this going quickly, and the above works as a good *big hammer*
solution to solve most problems quickly, but ultimately you are going to
want to make sure that you start implementing the encoding correctly in
your view code as you go. It is pretty easy to carve out sections of a
site and go through that section using the ESAPI tablibs or scriptlet to
call the correct one. 

Hope this has been helpful. 


On 5/7/2010 2:28 PM, Kesavanarayanan, Ramesh wrote: 

I have a question on the output encoding using the ESAPI.

In my application I tried to implement the ESAPI for the response output
encoding in a centralized manner so that I do not need to change every
JSP page in my application.

The following is the piece of code I have written using my

import java.io.CharArrayWriter;

        public void doFilter(ServletRequest request, ServletResponse

                        FilterChain chain) throws ServletException,
IOException {

                HttpServletRequest httpRequest = (HttpServletRequest)

                HttpServletResponse httpResponse = (HttpServletResponse)

                HttpSession session = httpRequest.getSession();

                ServletResponse newResponse = null;

                if (request instanceof HttpServletRequest) {

                        newResponse = new CharResponseWrapper(

                                        (HttpServletResponse) response);


                chain.doFilter(request, response);

                String text = newResponse.toString();

                text = text.toUpperCase();

                text = ESAPI.encoder().encodeForHTML(text);

                text = ESAPI.encoder().encodeForHTMLAttribute(text);

                text = ESAPI.encoder().encodeForJavaScript(text);

                text = ESAPI.encoder().encodeForCSS(text);

                CharArrayWriter caw = new CharArrayWriter();

                if (text != null) {

                        try {



                        } catch (java.lang.IllegalStateException ille) {




In my JSP I have the code as follows

Not working


function setUserName(){

         document.getElementById("login").value ='<%=
(String)request.getAttribute("username")  %>';





        String cleanXSS(String value) {

                value = ESAPI.encoder().encodeForHTML(value);

                value = ESAPI.encoder().encodeForHTMLAttribute(value);

                value = ESAPI.encoder().encodeForJavaScript(value);

                value = ESAPI.encoder().encodeForCSS(value);

                return value;




function setUserName(){

         document.getElementById("login").value ='<%= cleanXSS(
(String)request.getAttribute("username")  ) %>';



As you can see I expect the response to be updated with the ESAPI
functions, but somewhere I loose the ESAPI. The idea for me is to
centralize the output encoding so that it saves me time and effort.

Appreciate if you have any pointers on the same.

Regards |  Ramesh Kesavanarayanan  |    319-354-9200 ext 215785 / 215972
(O) |  /  319-621-7641 (M)   | ramesh.kesavanarayanan at pearson.com
<mailto:ramesh.kesavanarayanan at pearson.com> 

OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org

Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100508/00ccd5be/attachment.html 

More information about the Esapi-user mailing list