[Esapi-user] encoding request.getContextPath()

Jeff Williams jeff.williams at aspectsecurity.com
Tue Sep 11 23:11:49 UTC 2012

Hi David,


This is an excellent question.  The first question should be: what are
the allowed values of the context path returned. It really could contain
anything between the third and fourth / characters in a URL.   But it
can only reach the vulnerable code if it matches the context of an
actual application.  This is a sort of weird form of validation since
the context names on the server are under your control.


What characters would you need for an attack in the examples you list?





" onerror=alert(1)



There are lots more, but as long as you don't name your apps any of
these you are probably safe.  Quoting your attributes makes all the
difference here.  If you had unquoted attributes, an exploit is still
almost impossible because of validation, but there are a lot more


Of course, there's always the possibility that a server container has a
screwy context parsing algorithm, or an overlong UTF-8 error, or some
other Gareth Hayes heisenbug.  So I would, in priniciple, prefer to see
things like this encoded.  encodeForURL() should be fine for this.




Jeff Williams

Aspect Security


From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of David Ostiguy
Sent: Tuesday, September 11, 2012 10:16 AM
To: esapi-user at lists.owasp.org
Subject: [Esapi-user] encoding request.getContextPath()


Hi all,

Like many people I'm sure, I'm currently working on fixing a couple of
issues regarding XSS on a legacy java web portal system, which means I
have to find ways of fixing the maximum number of holes with minimum
impact. This isn't a public portal so it at least reduce the risk.

For now I'm concentrating my effort on encoding the output. My
understanding is that this should theoretically fulfill the goal.

I have multiple proprietary jsp tags and a couple of scripplet using
request.getParameter()/getAttribute() to adjust. However, there are also
several request.getContextPath() accessed through scripplet to build

First I'm wondering if they are actually at risk for XSS ? My guess is
yes. I suppose someone can tamper with almost anything in a
request/response so getContextPath() should be consider also. However,
I'm not finding much on the net or esapi or in the swingset example
showing that.

If they are at risk, because they are all used to construct a URL, would
Encoder.encodeForURL be enough? Or do I need to consider where/or how
the URL is constructed. Most of them are
<script src="<%= request.getContextPath() %>/js/utils.js"></script>
<img src="<%= request.getContextPath() %>/img/arrow.jpg"></script>

To minimize dev impact, would wrapping the request to override the
getContextPath method to return ESAPI.encoder().encodeForURL(path) be a
good idea?
This could cover most of them. Maybe I could double-encode for
javascript for exceptions like

Thanks in advance,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20120911/dd5f3da4/attachment.html>

More information about the Esapi-user mailing list