In my project, the resource injection issue is coming at creating a new URL(resource) (fortiy static scan). how to fix this?
String username = "james";
String resource = "https://someWebsite.com/api"+username;
URL url = new URL(resource); //here it is giving resource injection issue in fortify scan
System.setProperty("https.proxySet", "true");
System.setProperty("https.proxyHost", "11.09.11.111");
System.setProperty("https.proxyPort", "90");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
Immediately I see this line:
String resource = "https://someWebsite.com/api"+username;I know we're in trouble.
Why? I prompted you with a comment because you need to ask yourself "what am I doing here?"
Your initial reaction will probably be, "I'm concatenating the username to the URI string. This is a REST-based web service, so what's the big deal?"
This is getting flagged because you haven't conducted--in order of importance:
What did avgvstvs do here though? Why is he talking output when this is clearly input?
As a programmer you have a responsibility that they never taught you about in school. When working on an application you have to understand the data flow of your variables you use. You need to separate all inputs into 2 categories:
You need to think about users whose intent to use your system is evil; this isn't to make you think that all users are the enemy--though some veterans here might argue with that--but that when you're writing secure code, you need to think about how an adversary will abuse your code.
Once you understand that external context, this should start to look more clear for you now.
Any user of your website can hit "f12" and call up tools that allow them to easily bypass any client-side protections that might exist: Any input from any user should be treated as potentially malicious. The main defenses against abuse are what I stated above: escaping for the correct context, and validating input.
Before any value should be used, it should be validated. As currently written, I can impersonate any user registered with that API url. Several input checks make sense here:
Some of these questions are probably already answered by the construction and use of your web framework, but I'd suggest you understand how your framework protects the application for all of these questions. With experience, 1, 3, and 4 are almost always managed by other parts of the application, but until you know that, always ask those questions.
Why output encoding/escaping? Isn't this input?
When you decide to concatenate the username to the URI, and then proceed to make a request, ask yourself, "what am I really doing here?"
Obviously the intent is to take the username, concatenate it to the value that will be used...
Any time you use a variable--you need ask yourself all of those questions over again, plus one more:
In this case, you're passing the value into a data context that indicates it will be used in a URI. That means that the data will have to be properly encoded and escaped for use in the URI so that we don't introduce errors and possibly further vulnerabilities downstream in our stack.
To resolve this finding:
Answer all 7 questions for the username variable, then select the appropriate methods available to you from your application stack. It's true that you tagged esapi, but esapi can't help with all 7 questions here for you, just the input validation and the output encoding... which your application's security framework might already make available to you.