608e46b17b501a42b7ca533aa95b0db15d93eb3e jcasper Fri Aug 9 00:38:51 2024 -0700 A few small changes to the mirror manual security section, refs #34166 diff --git src/product/mirrorManual.txt src/product/mirrorManual.txt index e5128fa..271685e 100644 --- src/product/mirrorManual.txt +++ src/product/mirrorManual.txt @@ -1348,71 +1348,76 @@ FireFox, so after debugging hgTables, you will probably want to add &formMethod=POST to an URL (or clear cart, load session etc). One thing that does not work with GET is "upload file" inputs. # HTTPS Certificate Check for Verification Settings are: abort warn log none # currently the default is log httpsCertCheck=log # domains to whitelist, skip cert checking, space-separated list httpsCertCheckDomainExceptions=somedomain1.com somedomain2.edu # Notes on security -The Genome Browser is a complicated piece of software of more than 2 million -lines of code that have been developed over 20 years. When running security -scanners on it, false positives are likely. At UCSC, we run a security scan -on the Genome Browser ourselves once a month and it is easy to see why the scanners -find problems in the Genome Browser that are not actual problems: +The Genome Browser is a complicated piece of software of more than 2 million lines of +code that have been developed over 20 years. There is a risk of bugs and security issues, +and we take that seriously. At UCSC, we run a security scan on the Genome Browser once a +month and play close attention to the results. Frequently, however, the scanners complain +about things in the Genome Browser that are not actually problems. The Browser is designed +for significant flexibility when accessing and sharing data. As a result, security +scanners often complain about potential vulnerabilities that are actually intentional +features: * The Genome Browser draws remote genome annotation files that are streamed on the fly through https. This means that parts of these files appear in our user interface. Various features of custom tracks and track hubs specifically reference external - file via URLs that the user can define and we place no restrictions on these URLs + file via URLs that the user can define, and we place no restrictions on these URLs for various reasons. These features predate the introduction of CORS to the internet protocols by at least five years, and the servers from where these files are loaded by the Genome Browser do not need to specifically allow the requests. As a result, this is not a security exploit but an intentional feature, similar to a webservice that checks files entered via a - URL (e.g. a robots.txt analyzer) that then show the content of the URLs on their web pages. + URL (e.g. a robots.txt analyzer) and then shows the content of the URLs on their web pages. Security scanners will find these features and flag them as SSRF exploits - (Server-side request forgery), but they are a result of our features and not - a problem of our software and not a problem in the context of our public web servers. + (Server-side request forgery), but they are a result of our features, not + a problem in our software, and not a problem in the context of our public web servers. * Conversely, when running a local Genome Browser at your institution, do not assume that the Genome Browser web server can be granted access to internal files that should not be shared with the outside world. The Genome Browser is not a secure gateway, and anything that the Genome Browser can access may be displayable by any Genome Browser user. For example, if you restrict internal files to access from only the Genome Browser IP address, as with most other servers without dedicated security layers, - assume that these can be accessed by anyone who is using the browser. + assume that these can be accessed by anyone who is using the browser. We strongly advise + you to constrain access to and from your local mirror of the Browser if this is a concern + for you. * On our webservers at UCSC and your own internal mirror, even though the data from external URLs is shown, and even though the HTML tags are interpreted, Javascript in these pages is not executed, so an XSS exploit is not possible through these. - We use CSP and a nounce to block Javascript in these pages. CSP/nounce is a system that many + We use CSP and a nonce to block Javascript injection in these pages. CSP/nonce is a system that many security scanners do not recognize. You can disregard XSS warnings from the security scanners, and refer your IT department to our CSP declarations in the HTML headers, unless you can think that you found a case where it is possible to get - through the CSP/nounce system. Feel free to send us the security report from + through the CSP/nonce system. Feel free to send us the security report from your scanner when in doubt. -* Our CSP/nounce system also secures the Javascript libraries. We use customized jquery libraries - from the mid-2000s, some of them are outdated, so some security scanners deem - these as unsafe. But CSP and the nounce means that possible XSS problems cannot be exploited. The - security scanners also cannot detect that. To reduce these warnings, are are in the process of upgrading our - Javascript dependencies, where possible. +* Our CSP/nonce system also secures the Javascript libraries. We use customized jquery libraries + from the mid-2000s. Some of these are outdated, so some security scanners deem + them unsafe, but our use of CSP and a nonce means that possible XSS problems cannot be exploited. The + security scanners also cannot detect that. To reduce these warnings, we are in the process of upgrading our + Javascript dependencies where possible. # Proxy support net.c now has support for http(s) proxy servers which may be required by some installations to get through the firewall to external resources such as (but not limited to) for example bigWig or bigBed data via custom track bigDataUrl. One must add the setting "httpProxy", "httpsProxy", "ftpProxy" to hg.conf httpProxy=http://someProxyServer:3128 httpsProxy=http://someProxyServer:3128 ftpProxy=ftp://127.0.0.1:2121