diff options
author | Shawn O. Pearce <spearce@spearce.org> | 2009-11-09 11:26:43 -0800 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2009-11-09 16:37:33 -0800 |
commit | 34b6cb8bb032bd16f3d1c93a8417beb75e51ed29 (patch) | |
tree | 7282c74a1fdea9b7bab4686b091c66e094eed091 /refs.h | |
parent | 92815b3363c6cf317337437a986bdf2e8f1aa3a0 (diff) | |
download | git-34b6cb8bb032bd16f3d1c93a8417beb75e51ed29.tar.gz git-34b6cb8bb032bd16f3d1c93a8417beb75e51ed29.tar.xz |
http-backend: Protect GIT_PROJECT_ROOT from /../ requests
Eons ago HPA taught git-daemon how to protect itself from /../
attacks, which Junio brought back into service in d79374c7b58d
("daemon.c and path.enter_repo(): revamp path validation").
I did not carry this into git-http-backend as originally we relied
only upon PATH_TRANSLATED, and assumed the HTTP server had done
its access control checks to validate the resolved path was within
a directory permitting access from the remote client. This would
usually be sufficient to protect a server from requests for its
/etc/passwd file by http://host/smart/../etc/passwd sorts of URLs.
However in 917adc036086 Mark Lodato added GIT_PROJECT_ROOT as an
additional method of configuring the CGI. When this environment
variable is used the web server does not generate the final access
path and therefore may blindly pass through "/../etc/passwd"
in PATH_INFO under the assumption that "/../" might have special
meaning to the invoked CGI.
Instead of permitting these sorts of malformed path requests, we
now reject them back at the client, with an error message for the
server log. This matches git-daemon behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'refs.h')
0 files changed, 0 insertions, 0 deletions