
Hari (Community Member) asked a question.
flaws) - How to fix this and is there a way to mitigate this?
if (protocolType.equalsIgnoreCase(HTTPS)) {
LOG.debug("Connection protocol is https");
// Installing SSL Certificates
applySSL();
// Establishing Connection
urlConnHttps = (HttpsURLConnection) url.openConnection();
// Setting Header Method type to POST
urlConnHttps.setRequestMethod(POST);
// Setting Header Content-Type to application/JSON
urlConnHttps.setRequestProperty(CONTENT_TYPE, CONTENT_TYPE_APP_JSON);
urlConnHttps.setDoOutput(true);
// Getting OutputStream
dtOpStrm = new DataOutputStream(urlConnHttps.getOutputStream());
// Writing request to the output stream
//dtOpStrm.write(Encode.forHtmlContent(requestString).getBytes());
dtOpStrm.write(StringEscapeUtils.unescapeHtml4(Encode.forHtmlContent(requestString)).getBytes());
// Getting Response Code and Resposne Status Message
responseCode = urlConnHttps.getResponseCode();
responseMessage = urlConnHttps.getResponseMessage();
} else {
LOG.debug("Connection protocol is http");
urlConnHttp = (HttpURLConnection) url.openConnection();
// Setting Header Method type to POST
urlConnHttp.setRequestMethod(POST);
// Setting Header Content-Type to application/JSON
urlConnHttp.setRequestProperty(CONTENT_TYPE, CONTENT_TYPE_APP_JSON);
urlConnHttp.setDoOutput(true);
// Getting OutputStream
dtOpStrm = new DataOutputStream(urlConnHttp.getOutputStream());
// Writing request to the ourestput stream
//dtOpStrm.write(Encode.forHtmlContent(requestString).getBytes());
dtOpStrm.write(StringEscapeUtils.unescapeHtml4(Encode.forHtmlContent(requestString)).getBytes());
// Getting Response Code and Resposne Status Message
responseCode = urlConnHttp.getResponseCode();
responseMessage = urlConnHttp.getResponseMessage();
}
The lines which are underlined are showing high vulnerability.Is there a way that this can be mitigated or please guide with the solution to be used
.png)
Hi @Hari,
Thanks for your post. For CWE-80 issues reported in Java apps, Veracode static analyzer is able to detect proper cleaning and encoding of tainted, untrusted inputs that are vulnerable to XSS whenever the code is written to make use of one of our supported cleansing functions from this list: https://docs.veracode.com/r/Supported_Java_Cleansing_Functions. Looking at your code sample, it seems you already are making use of one of these supported XSS cleansing functions, namely the `org.owasp.encoder.Encode.forHtmlContent` cleanser function when you apply it against the tainted, untrusted requestString variable.
The problem however is that in your code sample, you are first applying the proper HTML cleanser function against the tainted requestString variable which is great -- but then you undo that encoding protection by applying a reverse decode operation. This makes the code once again vulnerable to XSS. This encode-then-decode approach does nothing to fix the XSS issue for this reason, so that is why Veracode static analyzer keeps the flaw open.
To properly resolve this in a way that Veracode static analyzer can recognize, you just want to update this code to drop mention of the decode `unescapeHtml4` function and only mention the `Encode.forHtmlCleanser` cleanser method. In fact, it looks like you have a line of code that encodes the `requestString` variable properly commented out on the line right above the line of code you underlined. So what you can do is remove the current underlined code and uncomment that line. Then when you perform a re-scan, the analyzer should see the encoding fix and resolve the issues from your report.
If for some reason your team is not willing to apply this kind of code change to resolve the issue, then you may consider applying other XSS mitigation approaches either in your code or as part of your application runtime. I see @SNichols779436 has raised some good callouts in his earlier comment already highlighting input validation and CSP headers, both of which can help. Veracode provides a resource on how to address CWE-80 issues in this blog article as well -> https://www.veracode.com/security/java/cwe-80 . The OWASP site also has a great resource on ways you can mitigate the risk of XSS in your app at https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html. However, please be aware that Veracode static analyzer most likely is not going to be able to recognize any other mitigation strategy mentioned in these resources that does not make explicit use of a cleanser function from https://docs.veracode.com/r/Supported_Java_Cleansing_Functions.
If you decide to mitigate the XSS issue using these other approaches, you will have to submit a mitigation proposal comment for these flaws and then work with an appsec minded team member at your organization to discuss, review and approve your mitigation approach. For more details about the mitigation proposal process inside Veracode and how to apply it, please consult the below resources:
I hope this helps. Please do let us know if you have any further questions or concerns.
Best Regards,
Andrew Bell
Thanks @Andrew Bell (Veracode, Inc.)