Potential fix for code scanning alert no. 9: Uncontrolled data used in path expression

[LendaVadym]

Potential fix for https://github.com/LendaVadym/durga/security/code-scanning/9

To fix this path traversal vulnerability, we must ensure that fileName is a safe file name and cannot be used to escape the /app/files directory. There are two robust approaches:

1. Single path component only: If the intent is to allow only file names (not paths), check for any path separator characters (/, \) or sequences like .., and reject the input if found.
2. Contained within base directory: If fileName might be a relative path within /app/files but must never escape that base directory, resolve the full path and ensure it starts with the trusted base directory.

The safest option here is to use the second approach, as it handles both single file names and safe subdirectories. We'll use Path.GetFullPath on Path.Combine(basePath, fileName) and compare against the base directory's full path (with a trailing separator for robust prefix checking). If the resolved file path starts with the base directory, we accept it; otherwise, we reject the request with a 400 Bad Request.

Additionally, we should handle errors gracefully if the path is rejected.

The required changes are as follows:

• In ReadFile(), validate fileName before using it to construct the path.
• Add the necessary file path validation logic in ReadFile.
• No extra imports are required beyond the already imported System.IO.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[LendaVadym]

test review comment