[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.

 

--Jeff

 

 

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
values.

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
XSS!

I implore you to manually encode each variable per
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Che
at_Sheet
<http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Preventio
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,
Jim




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

You just create an HttpServletRequestWrapper that returns the encoded
values.

public class MyWrapper extends HttpServletRequestWrapper {
   @Override
   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
point. 

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. 

Thanks 

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
sessionFilter.

import java.io.CharArrayWriter;

        public void doFilter(ServletRequest request, ServletResponse
response,

                        FilterChain chain) throws ServletException,
IOException {

                HttpServletRequest httpRequest = (HttpServletRequest)
request;

                HttpServletResponse httpResponse = (HttpServletResponse)
response;

                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 {

                                caw.write(text);

 
response.getWriter().write(caw.toString());

                        } catch (java.lang.IllegalStateException ille) {

                        }

                }

       }

In my JSP I have the code as follows

Not working

<script>

function setUserName(){

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

}

</script>

Working

<%!

        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;

        }

%>

<script>

function setUserName(){

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

}

</script>

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
https://lists.owasp.org/mailman/listinfo/owasp-esapi
  
 
_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi
  






-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net
-------------- 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