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

Jeff Williams jeff.williams at owasp.org
Mon May 17 00:34:20 EDT 2010


In principle this approach achieves even *better* separation of code and
data than can be achieved with escaping.

In practice, you need to be careful about exactly how the data is to be
transmitted and integrated into the HTML. You might inadvertently put user
data into an existing script context where it could run.

--Jeff


-----Original Message-----
From: owasp-esapi-bounces at lists.owasp.org
[mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Ashish Mishra
Sent: Saturday, May 15, 2010 9:29 AM
To: Jim Manico
Cc: Kesavanarayanan, Ramesh; esapi-user at lists.owasp.org;
owasp-esapi at lists.owasp.org
Subject: Re: [OWASP-ESAPI] [Esapi-user] Implementation of Global Output
Encoder with ESAPI

Guys, I understand that securing legacy apps against XSS attacks is
the most difficult thing. There is no "big hammer" way to perfect
that. But if you test the existing screens thoroughly and no further
development is being done on legacy app then the the "one place to
encode the data" approach might work.

But I think there should be some consensus on what approach should be
taken to safeguard new applications.

What about bringing UI template and data separately on the client and
populating that data on the UI with JavaScript. Most of the browsers
these days are anyway capable of executing big scripts in no time. And
since we are using the data only in scripts, encoding for JavaScript
is enough.
There are many existing JavaScript UI libraries out there (or can be
written) which provide APIs to populate the data once the UI is
rendered.

Any issues in this approach I might have overlooked.

Thanks
Ashish


On Fri, May 14, 2010 at 10:53 PM, Jim Manico <jim.manico at owasp.org> wrote:
> 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übeck
> 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_S
heet
>>>> - 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
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>
>
_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi



More information about the Esapi-user mailing list