6426a655644fe5e06de5cebdc4f01c7b0deb2686 max Thu Aug 8 06:47:16 2024 -0700 adding note about security problems, refs #34166 diff --git src/product/mirrorManual.txt src/product/mirrorManual.txt index e8c01ca..a11e0dc 100644 --- src/product/mirrorManual.txt +++ src/product/mirrorManual.txt @@ -1346,30 +1346,73 @@ The hg18 hgTracks config page generates a GET URL that is too long for 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 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 html + 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 specifcally allow the requests. As a result, this is not a security + exploit but an intentional feature, similar to a webservice that check files entered via a + URL (e.g. a robots.txt analyzer) that then show 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. +* 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. +* On both our webservers at UCSC and your own internal mirror, even though the + data from external URLs is shown, and even HTML tags are interpreted, Javascript in them is not executed. + We use CSP and a nounce to this end. CSP/nounce 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 + 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. + # 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 If the proxy server requires BASIC authentication @@ -1888,15 +1931,16 @@ By default, your browser mirror only comes with our public hubs. You may want to remove these and replace them with the hubs in your institution. One idea could be to have one hub per research group or department and users connect to them on My Data > Track Hubs. Use hubPublicCheck to create the SQL command to add the hub: hubPublicCheck hubPublic -addHub=https://genome.ucsc.edu/goldenPath/help/examples/hubDirectory/hub.txt Output is: insert into hubPublic (hubUrl,descriptionUrl,shortLabel,longLabel,registrationTime,dbCount,dbList) values ("https://genome.ucsc.edu/goldenPath/help/examples/hubDirectory/hub.txt","", "My Hub's Name", "Name up to 80 characters versus shortLabel limited to 17 characters", now(),1, "hg19,"); Then we run hubCrawl to get the searches to work (most mirrors do not need this). See for more details. +