[Esapi-user] encoding request.getContextPath()

David Ostiguy david.ostiguy at jadsoft.com
Tue Sep 11 14:15:50 UTC 2012


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

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>
or
<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
    window.open("<%=request.getContextPath()%>/jsp/move.jsp");

Thanks in advance,

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


More information about the Esapi-user mailing list