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

Jim Manico jim.manico at owasp.org
Mon May 17 01:07:44 EDT 2010


Well said Jeff. To add to that - all auto-escape template technologies  
mentioned provide a way to over-ride and disable the escaping rules.  
Functionality win! Security fail.

Jim Manico

On May 16, 2010, at 7:03 PM, "Jeff Williams" <jeff.williams at aspectsecurity.com 
 > wrote:

> I think Jim is on the right track here, I would just say it a little  
> differently in order to be completely clear.
>
>
>
> Today, you have to manually escape all untrusted data before  
> including it in HTML. That means directly calling escape methods  
> from your HTML generation code, wherever that might be.
>
>
>
> Tomorrow, though, we may get to the point where direct HTML  
> generation is not necessary. I’ve been waiting for this for a decade 
> , and I’m still optimistic. If you are disciplined enough, you can c 
> ertainly already do this today with components, tags, templates, or  
> whatever you decide to call them.  All you have to do is use the pro 
> per escape methods as you’re writing out HTML content within the tag 
> .  Oh, and you need a rule that says developers can’t generate HTML  
> by hand.  In my experience, this last rule is where we fall down…  a 
>  lot.
>
>
>
> --Jeff
>
>
>
>
>
> From: esapi-user-bounces at lists.owasp.org [mailto:esapi-user- 
> bounces at lists.owasp.org] On Behalf Of Jim Manico
> Sent: Friday, May 14, 2010 1:24 PM
> To: Kesavanarayanan, Ramesh
> Cc: owasp-esapi at lists.owasp.org; esapi-user at lists.owasp.org;  
> Sebastian Kübeck
> Subject: Re: [Esapi-user] [OWASP-ESAPI] Implementation of Global  
> OutputEncoder with ESAPI
>
>
>
> Manually encoding all UI inputs is the best we can do today to catch  
> all display contexts in HTML. But this is only today. The future  
> involves frameworks that use auto-escaping template technology - but  
> few do it right.
>
> The best I have seen are from Google.
>
> 1) http://googleonlinesecurity.blogspot.com/2009_03_01_archive.html  
> (C++ web dev world only)
>
> 2) GPX (Text from a Google AppSec resource I'm in contact with)
>
>
> GXP : http://code.google.com/p/gxp/ .  It's another,
> older, Google offering on that front that is much closer structurally
> to JSP and so possibly a better option for someone who has a bunch of
> broken JSPs and wants to migrate piecemeal to a better system.
> If someone wants to work around the auto-escaping they can use
> http://gxp.googlecode.com/svn/trunk/javadoc/com/google/gxp/html/HtmlClosure.html
> but such exceptions are captured in the java type system which makes
> auditing them and focusing logging and assertions around them fairly
> easy.
> They've done a really bad job documenting and advocating GXP but I've
> used it and it is really well thought out, easy to use, and feature
> complete.  https://docs.google.com/a/google.com/present/view?id=dcbpz3ck_8gphq8bdt
>
>
>
>
>
>
> Thanks for the input folks. But overall it seems that there is no  
> much we can do for the output encoding but to change UI level. But  
> again if we decide do so there are multiple ways to represent data  
> into the UI for example using struts2.0
>
> 1) We can use JSTL <c:out
> 2) we can simply use ${formname.variablename}
> 3) we can use display tag
>
>
> So my question is that is there a way we can capture the pageContext  
> and do something over the print writer? I always feel that with sop  
> many choices there should be a centralized way to implement these  
> rather than just preventing it in certain pieces of areas.
>
> HTH.
>
>
> -----Original Message-----
> From: owasp-esapi-bounces at lists.owasp.org on behalf of Sebastian Küb 
> eck
> Sent: Sat 5/8/2010 2:57 AM
> To: Jim Manico
> Cc: owasp-esapi at lists.owasp.org; esapi-user at lists.owasp.org
> Subject: Re: [OWASP-ESAPI] Implementation of Global Output Encoder  
> with ESAPI
>
> +1
>
> I once watched an experienced pen tester confronted with mod_security.
> It added probably half an hour to his work. That was it.
> There are just so many ways to trick those filters.
>
> @Ramesh: Unfortunately, there is really no shortcut that makes your  
> code
> safe. The only thing you can do is to escape output context specific  
> in
> every JSP page, servlet etc..
>
> Sebastian Kübeck
>
> Am 08.05.2010 01:37, schrieb Jim Manico:
> >> 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*
> >
> > <soapbox>
> > Comon boys - Risk Management is often used to justify NOT doing the
> > right thing. Around these parts we OUTPUT ENCODE CONTEXTUALLY FOR  
> ALL
> > OUTPUT. NOTHING ELSE STOPS XSS.
> > </soapbox>
> >
> > Cheers,
> > - Jim
> >
> >
> >> 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_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
> >
> >
> > --
> > Jim Manico
> > OWASP Podcast Host/Producer
> > OWASP ESAPI Project Manager
> > http://www.manico.net
> >
> >
> >
> > _______________________________________________
> > 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/20100516/59334ed0/attachment.html 


More information about the Esapi-user mailing list