Skip to main content
deleted 51 characters in body
Source Link
Anders
  • 65.8k
  • 25
  • 185
  • 226

Hello folks of Security Stackexchange,

I have an application that escapes the following special characters. & < > " ' The

& < > " '

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

-Haunted.

Hello folks of Security Stackexchange,

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

-Haunted.

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.

Source Link
Haunted
  • 143
  • 4

Is this filter safe enough to mitigate XSS?

Hello folks of Security Stackexchange,

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

-Haunted.