1

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.

6

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.

  • 1
    After seeing your comment, I was thinking this would not work because i already tried using \x0d and \x0a within the text field and they were getting properly escaped. But then i realized how stupid I am. All this while i was trying to pass the XSS payloads in the HTML textbox without realizing that the browser URL encodes the request parameters thereby making %0D to %250D. I tried passing them in the URL and I get an alert. Thank you so much for your answer. – Haunted Jun 27 '17 at 14:13
  • Can you also please let me know if there is a way to break out of scenario's 2.a and 2.b which is within the <input> and <div> tags. %0d and %0a for these tags but how do i break out of the attribute when " ' < > & are escaped? – Haunted Jun 27 '17 at 14:17
  • You can't escape html tags with %0d%0a. It will only work in javascript. eg <input value="<%= req.getParameter("choice") %>"/> with the following request : supersecure.com/?choice=%0d%0aonclick=alert(1); will not work. By encoding, " ' < > & I don't see anyway to break out from html tags. – Xavier59 Jun 27 '17 at 17:56
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).

  • I never thought of the second variable, b in this case. I am aware that `` will break the javascript syntax, but never gave a thought to the possibility of having a second or third variable. Thank you for your answer. Also, answering your second part, at this point of time, yes, we are relying on not having any quoteless attributes to minimize the risk as much as we can. – Haunted Jun 27 '17 at 14:22
0

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

  • hmmmm if your goal is not to protect the page but to exploit it, then forget about my answer. – niilzon Jun 27 '17 at 7:53
  • My goal is protect the page, but you see, this is a fairly huge application built using an ancient technology. Any huge changes will cause an increase in time and money. – Haunted Jun 27 '17 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.