diff --git a/java/ql/src/Security/CWE/CWE-079/XSS.java b/java/ql/src/Security/CWE/CWE-079/XSS.Bad.java similarity index 100% rename from java/ql/src/Security/CWE/CWE-079/XSS.java rename to java/ql/src/Security/CWE/CWE-079/XSS.Bad.java diff --git a/java/ql/src/Security/CWE/CWE-079/XSS.Good.java b/java/ql/src/Security/CWE/CWE-079/XSS.Good.java new file mode 100644 index 000000000000..2bef24407ae7 --- /dev/null +++ b/java/ql/src/Security/CWE/CWE-079/XSS.Good.java @@ -0,0 +1,11 @@ +public class XSS extends HttpServlet { + protected void doGet(HttpServletRequest request, HttpServletResponse response) + throws ServletException, IOException { + String unsafeInput = request.getParameter("page"); + String safeInput = StringEscapeUtils.escapeHtml4(unsafeInput); + // GOOD: the untrusted request parameter is html encoded for special characters before being written into the response string. + response.getWriter().print( + "The page \"" + safeInput + "\" was not found."); + + } +} \ No newline at end of file diff --git a/java/ql/src/Security/CWE/CWE-079/XSS.qhelp b/java/ql/src/Security/CWE/CWE-079/XSS.qhelp index 05b0f2680022..2fda89b558a0 100644 --- a/java/ql/src/Security/CWE/CWE-079/XSS.qhelp +++ b/java/ql/src/Security/CWE/CWE-079/XSS.qhelp @@ -1,41 +1,69 @@ - + - -

Directly writing user input (for example, an HTTP request parameter) to a web page, -without properly sanitizing the input first, allows for a cross-site scripting vulnerability.

+ +

Directly writing user input (for example, an HTTP request parameter) to a web page, + without properly sanitizing the input first, allows for a cross-site scripting vulnerability.

-
- +
+ -

To guard against cross-site scripting, consider using contextual output encoding/escaping before -writing user input to the page, or one of the other solutions that are mentioned in the -reference.

+

To guard against reflected cross-site scripting in your backend java service, consider using + an appropriate HTML escaping library for your framework to sanitize the special HTML + characters. +

-
- +

For Android applications where an untrusted input is reflected into the WebView component + via risky methods such as evaluateJavascript, loadData or + loadDataWithBaseURL that execute javascript, use the following best practices:

-

The following example shows the page parameter being written directly to the page, -leaving the website vulnerable to cross-site scripting.

+ +

- +

If the above solutions do not work for your use-case, please consult your security assurance + team.

-
- + + -
  • -OWASP: -XSS -(Cross Site Scripting) Prevention Cheat Sheet. -
  • -
  • -Wikipedia: Cross-site scripting. -
  • +

    The following example shows the page parameter being written directly to the + page, leaving the website vulnerable to cross-site scripting.

    + -
    -
    +

    Use an HTML encoding API such as org.apache.commons.text.StringEscapeUtils.escapeHtml4to + sanitize the untrusted page parameter before inserting it into the HTTP response.

    + + + + + + +
  • OWASP: XSS + (Cross Site Scripting) Prevention Cheat Sheet.
  • +
  • Wikipedia: Cross-site scripting + .
  • +
  • WebView - Native bridges + Risks +
  • + + +
    + \ No newline at end of file