What happened?
The vulnerability scanner thinks that it found a possible reflective XSS or HTML injection vulnerability in the page.
When it injected Oui"sTYLe='acu:Expre/**/SSion(Afih(9717))'bad=" as a GET request parameter, the page rendered with the following element in it:
<a href="https://trojanmart.com/SSionAfih9717" title="Français " class=" ">...</a>
Part of the content (SSionAfih9717) matched the injected data.
Should you be concerned?
It depends. Tests like this may often be a false positive, as there are many different scenarios where user-input text may be reflected in the page in a non-harmful way.
It looks like the test was trying to inject a HTML attribute named bad into whatever element contained the data, but the word "bad" doesn't appear anywhere in the resultant HTML. I believe a successful attempt may have looked something like this:
<a href="https://trojanmart.com/SSionAfih9717" bad= title="Français " class=" ">...</a>
Note how the attribute bad appears after href. This could be used by an attacker to inject arbitrary JavaScript or manipulate the page in other ways.
In your particular case, you don't seem to be affected by the test, and it can likely be considered a false positive. That said, there may be other scenarios you are vulnerable to, as this is just one test of many possible. That said, if the request could completely replace the href value instead of being added at the end, it could be used to target javascript: URIs or other domains in the attacker's control.
How to fix it?
If you were really vulnerable to this, you would want to follow best practices outlined in the OWASP XSS Prevention Cheat Sheet Rule #5:
RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL
Parameter Values
Rule #5 is for when you want to put untrusted data into HTTP GET
parameter value.
<a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >
Except for alphanumeric characters, escape
all characters with ASCII values less than 256 with the %HH escaping
format. Including untrusted data in data: URLs should not be allowed
as there is no good way to disable attacks with escaping to prevent
switching out of the URL.
All attributes should be quoted. Unquoted attributes can be broken out
of with many characters including [space] % * + , - / ; < = > ^ and |.
Note that entity encoding is useless in this context.
WARNING: Do not encode complete or relative URL's with URL encoding!
If untrusted input is meant to be placed into href, src or other
URL-based attributes, it should be validated to make sure it does not
point to an unexpected protocol, especially javascript links. URL's
should then be encoded based on the context of display like any other
piece of data. For example, user driven URL's in HREF links should be
attribute encoded.
For example:
String userURL = request.getParameter( "userURL" )
boolean isValidURL = Validator.IsValidURL(userURL, 255);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}
