4

We're using fortify to scan java source code & it is complaining below error:

Method abc() sends unvalidated data to a web browser on line 200, which can result in the browser executing malicious code.

We've below code on line 200:

<a href="<%= Util.getProduct(request) %>">Product</a>

And Util.java hsa below code in getProduct method:

String prod = request.getParameter("prod");

Can any one tell me how to fix this XSS vulnerability?

Thanks!

Douglas Held
  • 1,452
  • 11
  • 25
Mike
  • 7,606
  • 25
  • 65
  • 82

2 Answers2

2

You need to escape the output of Util.getProduct(request). Typically this is done using JSTL and a <c:out> tag and EL:

<a href="<c:out value="${Util.getProduct(request)}"/>" class="left_nav_link">Product</a>

N.B. you'll have to use a fairly up-to-date implementation of EL (as per JSTL or JSP 2.0 EL for getter with argument and Parameters in EL methods) in order to pass an argument to the getter method.


Since the code in your question contains scriptlets, I will strongly suggest that you read How to avoid Java code in JSP files? This question covers reasons to use JSTL+EL instead of scriptlets, as well as a bit of information about what those two acronyms actually refer to.

Community
  • 1
  • 1
Matt Ball
  • 354,903
  • 100
  • 647
  • 710
  • is there a type after request)} extra closing angle bracket? – Mike Nov 10 '11 at 02:24
  • Ah no sorry - I was actually missing an open `<`, see the edit. – Matt Ball Nov 10 '11 at 02:26
  • When I added %@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> at the top, I'm getting lot of errors which says "acordong to tld or attribute directive in tag file, attribute value does not accept any expressions"....any clue? – Mike Nov 10 '11 at 03:09
  • 1
    `c:out` does not help prevent XSS for `href` values; it escapes the certain special characters in XML into predefined entities. [You need a combination of URL escaping and verification to prevent XSS via href values](https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values) – Vineet Reynolds Nov 10 '11 at 03:45
  • @Vineet you're totally right, I really wasn't thinking when I answered last night. You should post your own answer, or at least edit mine (if the former, I'll just delete mine). – Matt Ball Nov 10 '11 at 11:41
  • @MДΓΓ БДLL, this does not actually solve the problem that the attacker can enter something malicious as the product string in the URL, and that Mike's code will reflect it back to the browser. It's true Mike's coding style in unsophisticated in terms of encapsulation, but the real problem is Cross Site Scripting, a security vulnerability. c:out is probably going to HTML encode the string into an HTML attribute, which is likely not even correct. – Douglas Held Jan 20 '12 at 16:16
1

In case you don't have JSTL for this website, you can fix the problem by making sure you only print valid products:

public String getProduct( String prod ) throws InputValidationException {
    if (   prod.equals( "myProduct1" )
        || prod.equals( "myProduct2" )
        || prod.equals( "myProduct3" )
        // etc.           
    ) {
        return "/foo/page.jsp?product=" + safeProduct;
    }
    else {
        throw new InputValidationException( "Invalid product key provided." );
    }
}
Douglas Held
  • 1,452
  • 11
  • 25