TSamui201170 (Community Member) asked a question.
CWE 73 for Android App
I have the following code (where the customFolderName can only contain number and alphabets), still it is giving error..
- User will define the customFolderName, so that can not be hard coded
- How this can be vulnerability when I am verifying the custom folder name can not contain anything apart alphabet and numbers ?
void createFile(String customFolderName){
if(!verifyCustomFolder(customFolderName)){ //basically the customFolderName can only contain number and alphabets
return;
}
path = context.getExternalFilesDir() + "/myfolder/" + "customFolderName" + "myfile.txt"
File file = new File(path)
...
}
public static boolean verifyCustomFolder(String text) {
Pattern r = Pattern.compile("[a-zA-Z0-9]*");
return r.matcher(text).matches();
}
.png){kind=logo}
Hello @TSamui201170 (Community Member),
Thanks for your question.
Is it possible another component within your application is calling createFile() without performing the validation you describe? if there are multiple routes into createFile() it may be an idea to perform the validation here also as part of a defence in depth approach.
The allow-list regular expression you have included is a suitable mitigation if you wish to propose that, but only if you can be sure all code paths into createFile() also first pass the customFolderName parameter through verifyCustomFolder(). You could potentially make use of a regex replace within the createFile() method.
The scanner will not automatically remove the flaw as the customFolderName is considered to be tainted and the use of the regular expression will not remove that taint. This is by design and you will need to propose a mitigation. To have the scanner remove the flaw you would need to set customFolderName to a non-user-supplied value, such as an application-generated value e.g. UUID. If any element of customFolderName contains user-supplied input then the variable will be considered tainted and the flaw will be raised. I hope that explains this for you.
Kind regards,
Anthony Fielding
Thanks @Anthony Fielding (Veracode) for your reply. for your question:
//Is it possible another component within your application is calling createFile() without performing the validation you describe?//
No, no other method is doing so. Moreover veracode is pointing to createFile() specifically even after the validations added.
And it is a business requirement that customer will provide the folder name. Which can not be randomly generated or hardcoded. In real world scenarios it is not always possible to generate something randomly always either.
In worst case my file will be created in a different folder (but inside the same base folder) when any attacker trying to manipulate something. How that can be a vulnerability ?
Hi @TSamui201170 (Community Member),
I understand the business requirement around this mechanism, therefore you would need to propose a mitigation for your security team to review. The mitigation is that you are using an allow-list regular expression to prevent untrusted input from potentially overwriting or otherwise interfering with the contents of your application's sandbox.
Thanks,
Anthony
Thank you @Anthony Fielding (Veracode)