summaryrefslogtreecommitdiff
path: root/t/t9502-gitweb-standalone-parse-output.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-11-18gitweb: escape URLs generated by href()Libravatar Jeff King1-1/+2
There's a cross-site scripting problem in gitweb, where it will print URLs generated by its href() helper without further quoting. This allows an attacker to point a victim to a specially crafted gitweb URL and inject arbitrary HTML into the resulting page (which the victim sees as coming from gitweb). The base of the URL comes from evaluate_uri(), which pulls the value of $REQUEST_URI via the CGI module. It tries to strip off $PATH_INFO, but fails to do so in some cases (including ones that contain special characters, like "+"). Most of the uses of the URL end up being passed to "$cgi->a(-href = href())", which will get quoted properly by the CGI module. But in a few places, we output them ourselves as part of manually-generated HTML, and whatever was in the original URL will appear unquoted in the output. Given that all of the nearby variables placed into this manual HTML _are_ quoted, it seems like the authors assumed that these URLs would not need quoting. So it's possible that the bug is actually in evaluate_uri(), which should be doing a more careful job of stripping $PATH_INFO. There's some discussion in a comment in that function, as well as the commit message in 81d3fe9f48 (gitweb: fix wrong base URL when non-root DirectoryIndex, 2009-02-15). But I'm not sure I understand it. Regardless, it's a good idea to quote these values at the point of insertion into the HTML output: 1. Even if there is a bug in evaluate_uri(), this would give us belt-and-suspenders protection. 2. evaluate_uri() is only handling the base. Some generated URLs will also mention arbitrary refs or filenames in the repositories, and these should be quoted anyway. 3. It should never _hurt_ to quote (and that's what all of the $cgi->a() calls are doing already). So there may be further work here, but this patch at least prevents the XSS vulnerability, and shouldn't make anything worse. The test here covers the calls in print_feed_meta(), but I manually audited every call to href() to see how its output was used, and quoted appropriately. Most of them are esc_attr(), as they're used in tag attributes, but I used esc_html() when the URLs were printed bare. The distinction is largely academic, as one is implemented as a wrapper for the other. Reported-by: NAKAYAMA DAISUKE <nakyamad@icloud.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18t9502: pass along all arguments in xss helperLibravatar Jeff King1-2/+2
This function is just a thin wrapper around gitweb_run(), which takes multiple arguments. But we only pass along "$1". Let's pass everything we get, which will let a future patch add an XSS test that affects PATH_INFO (which gitweb_run() takes as $2). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t9502: fix &&-chain breakageLibravatar Jeff King1-4/+6
This script misses a trivial &&-chain in one of its tests, but it also has a weird reverse: it includes an &&-chain outside of any test_expect block! This "cat" should never fail, but if it did, we would not notice, as it would cause us to skip the follow-on test entirely (which does not appear intentional; there are many later tests which rely on this cat). Let's instead move the setup into its own test_expect_success block, which is the standard practice nowadays. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19t9502: do not assume GNU tarLibravatar Junio C Hamano1-1/+1
The check_snapshot function makes sure that no cruft outside the repository hierarchy is added to the tar archive. The output from "tar tf" on the resulting archive is inspected to see if there is anything that does not begin with "$prefix/". There are two issues with this implementation: - Traditional tar implemenations that do not understand pax_global_header will write it out as if it is a plain file at the top-level; - Some implementations of tar do not add trailing slash when showing a directory entry (i.e. the output line for the entire archive will show "$prefix", not "$prefix/"). Fix them so that what we want to validate can be tested with traditional tar implementations. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-12gitweb: escape html in rss titleLibravatar Jeff King1-0/+15
The title of an RSS feed is generated from many components, including the filename provided as a query parameter, but we failed to quote it. Besides showing the wrong output, this is a vector for XSS attacks. Signed-off-by: Jeff King <peff@peff.net>
2011-04-29gitweb: Restructure projects list generationLibravatar Jakub Narebski1-0/+74
Extract filtering out forks (which is done if 'forks' feature is enabled) into filter_forks_from_projects_list subroutine, and searching projects (via projects search form, or via content tags) into search_projects_list subroutine. Both are now run _before_ displaying projects, and not while printing; this allow to know upfront if there were any found projects. Gitweb now can and do print 'No such projects found' if user searches for phrase which does not correspond to any project (any repository). This also would allow splitting projects list into pages, if we so desire. Filtering out forks and marking repository (project) as having forks is now consolidated into one subroutine (special case of handling forks in git_get_projects_list only for $projects_list being file is now removed). Forks handling is also cleaned up and simplified. $pr->{'forks'} now contains un-filled list of forks; we can now also detect situation where the way for having forks is prepared, but there are no forks yet. Sorting projects got also refactored in a very straight way (just moving code) into sort_projects_list subroutine. The interaction between forks, content tags and searching is now made more explicit: searching whether by tag, or via search form turns off fork filtering (gitweb searches also forks, and will show all results). If 'ctags' feature is disabled, then searching by tag is too. The t9500 test now includes some basic test for 'forks' and 'ctags' features; the t9502 includes test checking if gitweb correctly filters out forks. Generating list of projects by scanning given directory is now also a bit simplified wrt. handling filtering; it is byproduct of extracting filtering forks to separate subroutine. While at it we now detect that there are no projects and respond with "404 No projects found" also for 'project_index' and 'opml' actions. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-08gitweb: Smarter snapshot namesLibravatar Mark Rada1-5/+33
Teach gitweb how to produce nicer snapshot names by only using the short hash id. If clients make requests using a tree-ish that is not a partial or full SHA-1 hash, then the short hash will also be appended to whatever they asked for. If clients request snapshot of a tag (which means that $hash ('h') parameter has 'refs/tags/' prefix), use only tag name. Update tests cases in t9502-gitweb-standalone-parse-output. Gitweb uses the following format for snapshot filenames: <sanitized project name>-<version info>.<snapshot suffix> where <sanitized project name> is project name with '.git' or '/.git' suffix stripped, unless '.git' is the whole project name. For snapshot prefix it uses: <sanitized project name>-<version info>/ as compared to <sanitized project name>/ before (without version info). Current rules for <version info>: * if 'h' / $hash parameter is SHA-1 or shortened SHA-1, use SHA-1 shortened to to 7 characters * otherwise if 'h' / $hash parameter is tag name (it begins with 'refs/tags/' prefix, use tag name (with 'refs/tags/' stripped * otherwise if 'h' / $hash parameter starts with 'refs/heads/' prefix, strip this prefix, convert '/' into '.', and append shortened SHA-1 after '-', i.e. use <sanitized hash>-<shortened sha1> Signed-off-by: Mark Rada <marada@uwaterloo.ca> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-08gitweb: Document current snapshot rules via new testsLibravatar Jakub Narebski1-0/+87
Add t9502-gitweb-standalone-parse-output test script, which runs gitweb as a CGI script from the commandline and checks that it produces the correct output. Currently this test script contains only tests of snapshot naming (proposed name of snapshot file) and snapshot prefix (prefix of files in the archive / snapshot). It defines and uses 'tar' snapshot format, without compression, for easy checking of snapshot prefix. Testing is done using check_snapshot function. Gitweb uses the following format for snapshot filenames: <sanitized project name>-<hash parameter><snapshot suffix> where <sanitized project name> is project name with '.git' or '/.git' suffix stripped, unless '.git' is the whole project name. For snapshot prefix it uses simply: <sanitized project name>/ Disadvantages of current snapshot rules: * There exists convention that <basename>.<suffix> archive unpacks to <basename>/ directory (<basename>/ is prefix of archive). Gitweb does not respect it * Snapshot links generated by gitweb use full SHA-1 id as a value of 'h' / $hash parameter. With current rules it leads to long file names like e.g. repo-1005c80cc11c531d327b12195027cbbb4ff9e3cb.tgz * For handcrafted URLs, where 'h' / $hash parameter is a symbolic 'volatile' revision name such as "HEAD" or "next" snapshot name doesn't tell us what exact version it was created from * Proposed filename in Content-Disposition header should not contain any directory path information, which means that it should not contain '/' (see RFC2183)... which means that snapshot naming is broken for $hash being e.g. hirearchical branch name such as 'xx/test' This would be improved in next commit. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>