Develop Reference

How to fix CWE 73 External Control of File Name or Path

During veracode scan i got CWE 73 issue in my result. Can someone suggest me how to fix this solution for the below coding scenario?
The existing solutions provide is not working,also i would like to know any ESAPI properties can be used to get rid of this issue?
try
{
String serviceFile = System.getProperty("PROP", "");
logger.info("service A", "Loading service file [" + serviceFile+ "].");//Security Issue CWE 73 Occurs in this line
}

There are several solutions for it:
Validate with a whitelist but use the input from the entry point As
we mentioned at Use a list of hardcoded values.
Validate with a simple regular expression whitelist
Canonicalise the input and validate the path
I used the first and second solutions and work fine.
More info at: https://community.veracode.com/s/article/how-do-i-fix-cwe-73-external-control-of-file-name-or-path-in-java

this document provides detailed information on recommended remedies any explicit custom solution. In my case, I tried whitelisting or blacklisting patterns in the provided method parameters however that still did not resolve CWE-73 risk. I think thats expected and the document does state this:
A static engine is limited in what it can detect. It can only scan your code, it won’t actually run your code (unlike Dynamic Scanning). So it won’t pick up any custom validation (if conditions, regular expressions, etc.). But that doesn’t mean that this is not a perfectly valid solution that removes the risk!
I tried my custom blacklisted pattern based solution and annotated the method with FilePathCleanser as documented in here and it resolved CWE-73 and veracode no longer shows that as a risk.

Try to validate this PROP string with Recommended OWASP ESAPI Validator methods, like below.
Example:
String PropParam= ESAPI.validator().getValidInput("",System.getProperty("PROP", ""),"FileRegex",false);
FileRegex is the Regular Expression against which PROP string i.e. path of the file is getting validated.
Define FileRegex = ^(.+)\/([^\/]+)$ in Validator.properties.

ESAPI not passing file validation

I am working with ESAPI to try and validate windows directory paths. For some reason, the part of my directory path named \14\ is getting converted into a CRLF. The error I am receiving is below, what am I not understanding correctly? I feel like my regex should be working.
WARN IntrusionDetector [SECURITY FAILURE Anonymous:null#unknown -> /project-test/IntrusionDetector] Invalid input: context=directoryPath, type(DirectoryName)=^[a-zA-Z0-9:/\\!##$%^&{}\[\]()_+\-=,.~'` ]{1,255}$, input=C:\UsersTESTUS~1AppDataLocalTempTestCase8002TempWorkSpace, orig=C:\Users\TESTUS~1\AppData\Local\Temp\14\TestCase8002TempWorkSpace
As you can see, I am using the regex:
^[a-zA-Z0-9:/\!##$%^&{}[]()_+-=,.~'` ]$
My input is:
C:\Users\TESTUS~1\AppData\Local\Temp\14\TestCase8002TempWorkSpace
Ouput, after ESAPI does canonicalization and validation:
C:\UsersTESTUS~1AppDataLocalTempTestCase8002TempWorkSpace
Here is the line of code that causes me to receive the error;
String validatedSourcePath = ESAPI.validator().getValidInput("directoryUnzip", directory, "DirectoryName", 255, false);
File validFile = new File(validatedSourcePath);

#C.Williams: I was about 30 minutes into writing up a detailed reply in an editor and accidentally excited my editor window. I'm too ticked off at my stupidity of not saving it to write it again, especially since I was only about 75% done.
However, if you want to email me I can arrange to talk to you via Google Hangouts or Signal to tell you want your problem is and how you can fix it. But it's long and complicated and partially related to a bug the ESAPI team just fixed but is not in any official release yet. But I am not going to take another 45 minutes or more trying to reply with any written text. My email address should be easy enough to find. Just google for my name and ESAPI. I am one of the project co-leaders on ESAPI.
-kevin wall

Cross Site History Manipulation(Checkmarx)

Does anyone know how to fix the Checkmarx vulnerability -- Cross Site History Manipulation for java based applcations?
Here is the description provided by Checkmarx scan -- "the method may leak server-side conditional values, enabling user tracking from another website. This may constitute a Privacy Violation."
Here is the related code :
if(user is logged in) {
response.sendRedirect(url);
} else {
response.sendRedirect(url)
}
Upon googling I found some Checkmarx documentation which to suggest to add a random number to the redirect url. Here is the link to the document : https://www.checkmarx.com/wp-content/uploads/2012/07/XSHM-Cross-site-history-manipulation.pdf
For e.g :
If ( !isAuthenticated)
Redirect(„Login.aspx?r=‟ + Random())
I tried this approach but the Checkmarx scan still show the same vulnerability.Not sure why.

XSHM could be a CWE-203 (http://cwe.mitre.org/data/definitions/203.html) from CX documentation.
The problem could be complex or simple. With just your 5 lines we can not said exactly what the good solution is.

Checkmarx is check if your redirect url include some random value. Here are some random methods checking by Java/Cx/General/Find_Cross_Site_History_Manipulation_Random:
Random.Next
Math.random
Randomizer.*
Random.nextBytes

How to hit the rest endpoint that has `:.*` as a part of the path param field

I am using the Stash's REST API in my project. My task is to get the tag details for a specific tag. After checking the Stash's REST API documentation, I found the correct endpoint that I should be using. It is
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/tags/{name:.*}
Please see this link for the Stash's REST API documentation.
There is one more endpoint /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/tags
With this endpoint I am able to retrieve all the tags. The StashTag object looks something like this.
{
"id": "refs/tags/v4.0.0",
"displayId": "v4.0.0",
"latestChangeset": "234dadf41742cfc2a10cadc7c2364438bd8891c5",
"latestCommit": "234dadf41742cfc2a10cadc7c2278658bd8891c5"
"hash" : "null"
}
My first problem is, I don't know which field to use as the parameter for {name:.*}. Should it be the displayId or Id or anything else.
The second problem is, I don't understand what it means to have : (colon) followed by a . (dot) in the endpoint /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/tags/{name:.*}.
Can someone explain me what is the purpose of :. in the path param and how to hit this kind of an endpoint. Also an example of the complete endpoint would be nice.
So far I have tried hitting
https://stashtest.abc.com/rest/api/1.0/projects/KARTIK/repos/kartiks-test-repository/tags/v4.0.0
https://stashtest.abc.com/rest/api/1.0/projects/KARTIK/repos/kartiks-test-repository/tags/refs/tags/v4.0.0
None of these endpoints work.
Any help is appreciated.

The {name:.*} is really just saying that the field name can be anything. Chalk this one up to poor documentation on their part. Think of it like Regex field, because that's exactly what it is. I'm sure at one point they had something like ^[0-9] then went back and changed it when they realized using only tag numbers would omit anyone using their lightweight tag features.
Remove the v from your tag version and see if that helps. If it does not, I would also recommend creating a lightweight tag (something like mytag) and seeing if you can hit it that way (i.e., /kartiks-test-repository/tags/mytag).
But looking at that documentation is telling me that your v in your tag name is throwing off the REST call.

OCPsoft Rewrite Rule no longer works after Update from 1.0.5 to 1.1.0

When updating OCPsoft Rewrite from Version 1.0.5.Final to 1.1.0.Final the following Rule no longer works and I don't know how to fix it:
.addRule(
Join.path("/{i}/{d}")
.where("i").matches("[-_a-zA-Z0-9~*]{8}")
.where("d").matches("[-_a-zA-Z0-9~*]{32}")
.to("/resources/html/user/doSomething.html?i={i}&d={d}")
)
In the Rewrite changelog there is one point that could help you help me:
Configuration strings are now literal. Regular expressions must be configured through a >parameter such as: .defineRule().when(Path.matches("/{*}").where("*").matches(".*"))
The exception I get is the following one:
Exception starting filter OCPsoft Rewrite Filter
java.lang.NullPointerException
at org.ocpsoft.rewrite.servlet.config.rule.Join.where(Join.java:199)
at org.ocpsoft.rewrite.servlet.config.rule.Join.where(Join.java:47)
at com.myapp.util.RewriteConfigurationProvider.getConfiguration(RewriteConfigurationProvider.java:39)
...

The following did the trick, I just had to reorder the join clauses:
.addRule(
Join.path("/{i}/{d}")
.to("/resources/html/user/doSomething.html")
.where("i").matches("[-_a-zA-Z0-9~*]{8}")
.where("d").matches("[-_a-zA-Z0-9~*]{32}")
.withRequestBinding();
)
Thanks to Lincoln, who figured this out and answered my question on the Rewrite support forums.

Hmm.. that does look like a bug, I'll try to reproduce this, but you shouldn't need to re-define {i} and {d} in the target URL. Join will handle that for you automatically if you use request binding, like so:
.addRule(
Join.path("/{i}/{d}")
.where("i").matches("[-_a-zA-Z0-9~*]{8}")
.where("d").matches("[-_a-zA-Z0-9~*]{32}")
.to("/resources/html/user/doSomething.html").withRequestBinding();
)
I'm guessing if you do that, your problem will go away. You can also use .withInboundCorrection() if you'd like to redirect requests for the old .html URL to the new URL.
If you still have a problem with this, please post on the support forums and we'll get it figured out :)
Sorry you had trouble, hopefully it won't be trouble any more :)