MaheshBabu (Community Member) asked a question.
This call to mscorlib_dll.System.IO.FileStream.!newinit_0_3() contains a path manipulation flaw. The argument to the function is a filename constructed using untrusted input.
public static void HandleTranslatedExcel(string path, string fileName, ImportType importType, int columnCount, List<string> headers)
{
try
{
string filepath = string.Empty;
if (importType == ImportType.Testing1)
filepath = path + fileName;
else if (importType == ImportType.Testing2)
filepath = path + fileName;
else if (importType == ImportType.Testing3)
filepath = path + fileName;
HSSFWorkbook wb = null;
using (FileStream fs = new FileStream(filepath, FileMode.Open, FileAccess.Read))
{
wb = new HSSFWorkbook(fs);
ISheet sheet = wb.GetSheetAt(0);
IRow row = sheet.GetRow(0);
for (int i = 0; i < columnCount; i++)
{
row.GetCell(i).SetCellValue(headers[i]);
}
fs.Close();
}
using (FileStream fs1 = new FileStream(filepath, FileMode.Create, FileAccess.Write))
{
wb.Write(fs1);
fs1.Close();
}
}
catch (Exception ex)
{
Logger.LogManager.Application.ErrorLogFormat("Unable to tranlate file {0}. The exception {0} is cuaght ", path, ex.ToString());
}
}
The issue is this 2 code - using (FileStream fs = new FileStream(filepath, FileMode.Open, FileAccess.Read)) and using (FileStream fs1 = new FileStream(filepath, FileMode.Create, FileAccess.Write)) which is causing the directory traversal issue. Kindly let us know about this issue to fix this 2 flaws ASAP.
.png){kind=logo}
Hi @MaheshBabu (Community Member),
Veracode Static Analysis reports CWE 73 (External Control of File Name or Path) when it can detect that a file path being accessed is composed using data coming from outside the application (such as an HTTP request, a file, or even your database). The concern is that an attacker might be able to manipulate the file path and might be able to access arbitrary files.
The following great Knowledge article describes how to deal with CWE 73 in detail: https://community.veracode.com/s/article/how-do-i-fix-cwe-73-external-control-of-file-name-or-path-in-java . The article is mainly about Java, but the same concepts apply to .NET and it also contains a code snippet on how to do a canonicalized path check in .NET, which is a concept that can be applied for more complex validation use cases.
In your example, the flaw seems to be reported on the variable `filepath` which contains the inputs of the variables `path` and `fileName`. If the main `path` is a constant, then you would only have to validate `fileName`. If possible, I would recommend either hardcoding the file name or validating it against an allow-list. This would make the flaws automatically disappear.
If it is impossible for you to know beforehand what file names may be accessed, I would recommend applying dynamic validation in form of a regex. As an example, you may want to validate the file extensions against an allow-list and make sure that the file name is alphanumeric and consists of 1-255 characters. This could be done using the following regex: `^[a-zA-Z0-9]{1,255}$` (without the ticks).
If the whole file path can be controlled from outside the application, I would recommend applying a canonical path check to ensure that the directory being accessed is under your control. For this, please refer to the code snippet in the above Knowledge article (section "Canonicalise the input and validate the path").
Please note that the only remediation Veracode Static Analysis accepts for CWE 73 is a hardcoded path or validation against a strict allow-list. This means that, once proper validation is in place, you may need to propose a mitigation (https://help.veracode.com/r/improve_mitigation) and contact your security team for mitigation review.
Thank you,
Florian Walter