Is this filter safe enough to mitigate XSS?

Question

I have an application that escapes the following special characters.

& < > " '

The application heavily displays HTTP request parameters throughout the application. The request parameters are used in the HTML body, div tags, even within the Javascript <script> tags. The only defense right now is escaping these 5 special characters.

What have I tried so far?

1. Read the OWASP XSS Prevention cheat sheet and OWASP Filter Bypass cheatsheet.
2. Tried replicating the application on my local system and tried fuzzing the application with the XSS payloads.

My questions

1. The OWASP cheat sheet recommends escaping & < > " ' / if used within the HTML tags. My application's filter is missing escaping only the / character. I believe / is needed only if the HTML attribute is not quoted. Am I correct in understanding this?

2. Say, we have the following HTML code within a JSP page. Can this be bypassed when & < > " ' / are escaped?
   a. <input type="hidden" name="choice" value="<%= encode(req.getParameter("choice")) %>">
   b. <div> <%= encode(req.getParameter("choice")) %> </div>
   c. <script> document.write("<%= encode(req.getParameter("choice")) %>") </script>

I am very well aware that this is not enough, but I have tried an extensive list of XSS payloads and was not able to bypass this. Escaping these 5 characters within an HTML context seems enough to me.

I would greatly appreciate if you guys could put forward your thoughts on this. I would really love to see this filter getting bypassed.

Answer 1

I would really love to see this filter getting bypassed.

Let me be the first to fulfill your wish with the so underevaluated and forgotten %0d%0apayload :

Your code :

<script> 
// TODO
// document.write("<%= encode(req.getParameter("choice")) %>")
</script>

Request : http://supersecure.com/?choice=%0d%0aalert(1);//

Resulting code :

<script> 
// TODO
// document.write("
alert(1);//")
</script>

While you may think you wouldn't comment such code, keep in mind some others devs could do it (for testing/debugging/temporaly disabling feature purpose) without thinking about the security hole it may create. For <script> you should encode %0d%0a into \r\n. Howewer, you don't need this encoding for html element.

Answer 2

Why not rely on proper encoding? A simple example of breaking out of a string could be:

<script>var a = "<%=encode(a)%>", b="<%=encode(b)%>";</script>

With a payload of a=\ the first string will extend to the beginning of the second and the value of b will be outside the string. So we can use b=-alert(1));//

Also you are relying on not having any quoteless html attributes (but from 1. I guess you know this).

Answer 3

I'd suggest to follow best-practices (instead of escaping some specific characters yourself, and using scriptlets which are a thing from the past).

In your case, since you are using JSP, you can simply use the <c:out /> tag which would make your code more readeable, standard, and safer by removing any custom whitelisting logic that you might have implemented (since you are currently escaping 5 chosen characters as you explain).