You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A week ago I stumbled across this project on Hackernews and had a brief look at the code. I particular I noticed the spartan API which provides direct config file access:
This code basically relies on the Flask router to filter out possibly malicious name values. The Flask router is obviously not designed for that, but it incidentally works fine for name values such as ../../../../etc/passwd as the route fails to match in this case. However, this is not always the case and more importantly it is dangerous to rely on this. I don't know if you officially support Windows as a platform but I want to use Windows paths as an example for this:
Imagine the NGINX_PATH is set to C:\\path\to\config\ and someone could do the following request:
This is a Path Traversal vulnerability which means your API would allow users to read and write arbitrary files. Even if you do not support Windows, the only protection in place on Linux is the router which is meant to be a protection. If someone clever would be able to get the name../../../../etc/passwd passed through the router to this API endpoint you end in the same situation.
Possible Solution
As a solution I would suggest using os.path.basename on name first or if you want to support subdirectories of NGINX_PATH you could use os.path.join, then normalize the path with os.path.normpath or os.path.realpath and then check if the resulting path still starts with NGINX_PATH. For more information about path traversal vulnerabilities, see https://owasp.org/www-community/attacks/Path_Traversal.
The text was updated successfully, but these errors were encountered:
Hey @erikgeiser, thank you for taking the time to examine the code for possible points of attack. Although I believe the possibility of this attack to be unlikely, we will of course take care to fix this vulnerability. I would be happy if you keep an eye on the project and continue to support us.
You are right to assume it is unlikely, especially if the config directory is mounted into a docker container, which seems to be your primary usecase. If this was a serious vulnerability I would not have posted it as a public issue.
However, given the large amount of stars this project has, I assume that many user run it in vastly different circumstances and environments which may not be as forgiving as docker containers. Also I think it's always good to practice defense in depth and to make others aware of such issues.
I've also left some comments at the pull request ;-)
A week ago I stumbled across this project on Hackernews and had a brief look at the code. I particular I noticed the spartan API which provides direct config file access:
The Problem
This code basically relies on the Flask router to filter out possibly malicious
name
values. The Flask router is obviously not designed for that, but it incidentally works fine forname
values such as../../../../etc/passwd
as the route fails to match in this case. However, this is not always the case and more importantly it is dangerous to rely on this. I don't know if you officially support Windows as a platform but I want to use Windows paths as an example for this:Imagine the
NGINX_PATH
is set toC:\\path\to\config\
and someone could do the following request:curl 'http://localhost/api/config/D:\\some\unrelated\file'
Then the
os.path.join
call would work as follows:This is a Path Traversal vulnerability which means your API would allow users to read and write arbitrary files. Even if you do not support Windows, the only protection in place on Linux is the router which is meant to be a protection. If someone clever would be able to get the
name
../../../../etc/passwd
passed through the router to this API endpoint you end in the same situation.Possible Solution
As a solution I would suggest using
os.path.basename
onname
first or if you want to support subdirectories ofNGINX_PATH
you could useos.path.join
, then normalize the path withos.path.normpath
oros.path.realpath
and then check if the resulting path still starts withNGINX_PATH
. For more information about path traversal vulnerabilities, see https://owasp.org/www-community/attacks/Path_Traversal.The text was updated successfully, but these errors were encountered: