This topic provides guidelines for running security scans and penetration tests against your LabKey Server installation.
Overview
Server security is a top priority for LabKey and we regularly improve protection against security vulnerabilities.
LabKey Server is regularly tested by security scans and penetration tests, both by our clients and by the LabKey test team. When the server is configured correctly (following the guidance in
Site Structure: Best Practices and the recommendations below), these scans regularly result in reports free of Critical or High Risk concerns.
Review and Troubleshooting
We are happy to review the reports generated from your security scans to help you interpret the results and analyze any flagged concerns. Please contact your account manager.
Some commonly reported findings are discussed below.
[Possible] Cross-site Scripting Warnings
Cross-site scripting (XSS) is a serious and common vulnerability on the web. It occurs when a web application mistakenly adds malicious content to a page’s DOM without properly encoding it, causing the browser to run malicious script.
API responses of Content-Type "application/json", may be shown in a security scan as warnings of "[Possible] Cross-site Scripting". These warnings are benign.
Many LabKey Server APIs return JSON. These responses can contain reflected content (user-supplied GET parameters, for example) or persisted content (a row of data from a table, for example). LabKey Server uses Jackson and other well-tested libraries to create the JSON, and properly encodes/escapes the values in the response per the JSON standard and specifies that its Content-Type is "application/json". It does not HTML-encode the values, because JSON is not HTML. There are two primary concerns for how the client will handle this content:
First, some old versions of Internet Explorer (no longer
supported for use with LabKey Server) will sometimes ignore the response's Content-Type and make a guess, potentially interpreting it as HTML, which could then be subject to XSS. To protect against this, LabKey Server includes the “X-Content-Type-Options” HTTP header to instruct IE to not guess its type.
Second, the client that is receiving the JSON response must handle it appropriately. It must not, for example, take the string from the JSON response and inject it directly into the page's DOM. This is true of any content that is being added dynamically to the page. However, as the client code is not simply plugging the server's response into the local page, it is not appropriate to pre-HTML encode it in the JSON.
We will immediately address any real instances of XSS, however, per our best security practices, we will continue to include legitimately encoded JSON content in API responses.
JQuery Version
JQuery UI version 1.12.1 included a vulnerability in the DatePicker component that was used only by the mass spectrometry viewer. Older versions of LabKey Server used this version of JQuery, so this may raise scan warnings. We have upgraded to JQuery UI 1.13.0 and have also created a minimal build of JQuery UI that contains only the single component we use to limit future issues.
Unfamiliar Email Accounts
If you notice numerous logged errors similar to "Password reset attempted for an email that doesn't match an existing account:..." these are not always malicious. They could be user errors or potentially part of a contracted vendor's process. Check to see if your organization uses an outside organization and unfamiliar email addresses as part of the scanning process.
@labkey/components Dependency on moment.js
When building with @labkey/components, you may see a vulnerability report related to this advisory about the moment.js package:
The @labkey/components package does require moment.js as a dependency, but this vulnerability does
NOT apply to LabKey usages. We use the moment.js library in NPM, but not in a server context. The advisory clarifies that "This vulnerability impacts npm (server) users of moment.js..." so does not apply to LabKey.
X-LK-NONCE header
LabKey injects an "X-LK-NONCE" header into every response. Its value is randomly generated and random length. This is standard practice to protect against potential BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) attacks.
https://en.wikipedia.org/wiki/BREACH
Recommendations
LabKey Server Settings
- Strong Password Settings. If you are using LabKey's built-in database authentication, configure your server to require strong user passwords. If you are using external authentication mechanisms, such as LDAP, configure those providers in a similar way.
- Run Scans as a Non-Admin User. When running security scans against LabKey Server, use the following sequence of scans:
- First scan the server as a Reader (i.e., scan as a user with the Reader role).
- Perform a second scan as an Editor.
- If an "administrator" level scan is required, use the Folder Admin role at most. Never run a security scan as Site Administrator. Site Administrators are granted special privileges, such as the ability to change security settings. They are also allowed to post content that includes JavaScript, which some scanners might interpret as a security vulnerability.
- Limit Login Attempts. Professional Edition administrators should consider limiting login attempts. (Some scanners look for an explicit lockout after a certain number of attempts.)
- Virus Checking. Enable virus checking for file uploads.
- Block Malicious Clients. Ensure that you run security scans with this experimental feature disabled. Consider enabling this feature during normal use. See Experimental Features.
Infrastructure
- Update 3rd Party Software. Ensure that your server is deployed against the latest supported versions of Tomcat, Java, and your database. For details on the latest supported technologies see Supported Technologies.
- Compare Firewall vs. No Firewall If you are running LabKey behind a WAF (Web Application Firewall), compare security scans with the WAF disabled versus enabled, in order to evaluate how this tool contributes to your security posture. For details on running the server behind a WAF see Deploying an AWS Windows Application Firewall.
- Adjust Tomcat Error Reporting: One source of 'false positives' can be Java exceptions raised when Tomcat (correctly) rejects badly formed URLs. These warnings are benign, and no security or implementation details are exposed, but they may be alarming. To have Tomcat more gracefully manage error reporting, add an ErrorReportValve element to the <Host> section of Tomcat's server.xml file as described in this installation section.
- Remove Tomcat Example Webapps: The default Tomcat webapps (e.g., examples, docs, manager, and host-manager) do not belong on a production deployment and security scanners will often flag these webapps and their content. LabKey displays an administrator warning banner if it detects these webapps running on a production deployment.
More Information
Related Topics
