When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
More information
Hello @sraajaamani227142 (Community Member),
Thanks for your question. To understand how the Veracode static analysis engine reports on CWE-73 findings and strategies you can adopt to fix the issues, Veracode recommends that you check out our Veracode Community article all about his CWE posted at https://community.veracode.com/s/article/how-do-i-fix-cwe-73-external-control-of-file-name-or-path-in-java.
The static engine traces your Python code to look for viable Python function calls that operate on files, such as open(), os.chmod(), file.exists() etc. Then if the engine can see that there is a data path found where the filename input to any of these functions accepts tainted input values from outside the Python application. For example, from a web request, a database call, reading from a file, etc. If such a path is found, a flaw will get reported.
So long as the code continues to host a data path were tainted outside inputs arrive in the filename input value, the engine will continue to report on a CWE-73 flaw. The only fix the engine will be able to recognize during a re-scan is if you completely remove the taint from the filename by hardcoding the filename input entirely.
You can review the fix strategy sections "CWE73-HARDCODE" and "CWE73-ALLOWLIST" for how to refactor your code to achieve this. It is crucial that the final "path" variable placed in the open() sink (for example) references a hardcoded string value in your Python scanned submission rather than values originating from an external source at runtime. Note the Community guide link above only provides Java and .NET code examples, however it is possible to take and adopt the guidelines to apply across other languages.
If it is not possible for you to rewrite this code to replace the "path" variable with a hardcoded value because the use case for this application requires highly variable, dynamic input that cannot be anticipated and hardcoded in advance, then Veracode recommends you read and consider the CWE73-REGEX, CWE73-C14N, and CWE73-CONFIG (if the input to the filename originates from a configuration file) sections from the same guide. These sections highlight how you can adopt a custom filename validation strategy using a combination of regex allowlist input validation and a canonical absolute path check.
For a canonical path validation check in Python, you can incorporate the os.path.realpath() method, kindly reference this resource for more details -> https://www.geeksforgeeks.org/python/python-os-path-realpath-method/ . After running the tainted "path" filename input value through this function, you then want to check that the value returned back starts with an expected base path directory location this Python application should be opening files from. Here is brief Python code snippet you can refer to as an example demonstrating how this validation works:
```
from sys import argv
from os.path import realpath
def get_validated_path(known_base_path: str, untrusted_path: str) -> str:
absolute_path = realpath(untrusted_path)
if not absolute_path.startswith(realpath(known_base_path)):
raise ValueError('Unexpected path, potential Path Traversal filename control attack')
return absolute_path
def main():
known_base_path = 'C:\\Windows\\Temp\\'
untrusted_path = argv[1]
path = get_validated_path(known_base_path, untrusted_path)
print(path)
if __name__ == '__main__':
main()
```
Please note that with these custom filename validation approaches and methods that you add to your Python code, the Veracode static engine is not going to recognize and evaluate these bespoke validation methods during a re-scan attempt. Therefore, after you implement the filename validation checks and you've tested the checks defined do mitigate the risk of filename control for your use case, you will need to enter a "Mitigate by Design" proposal inside the Veracode Platform for these CWE-73 flaws to document how your filename controls work and how they prevent/mitigate the risk here.
To learn more about entering a mitigation proposal to resolve flaws the Veracode static engine identifies, please refer to https://docs.veracode.com/r/improve_mitigation and https://docs.veracode.com/r/Video_Mitigate_Static_Analysis_findings . You will need to contact and work with your organization's security team responsible for your Veracode usage and administration to apply and complete this process.
I hope this information helps. Should you still have any additional questions or concerns after reading through the Veracode Community CWE-73 guide above, please follow the instructions that are provided under the section "None of these strategies work for me, what now?" for how to request additional support from Veracode in addressing these flaws.
Best Regards,
Andrew