Security/Responses to common security reports: Difference between revisions
From Mahara Wiki
< Security
(Created page with "The Mahara project team receives reports of security vulnerabilities, particularly in the supporting project infrastructure, that after investigation we determine are not vali...") |
No edit summary |
||
| Line 34: | Line 34: | ||
Some tools identify Mahara as potentially vulnerable to BREACH style attacks. The important word here is 'potentially' because we are not aware of any tool that has confirmed we are vulnerable to a BREACH style attack. Of the standard mitigations available for protection against BREACH attacks, the Mahara application implements CSRF protection. This has the additional benefit of also protecting against CSRF attacks. | Some tools identify Mahara as potentially vulnerable to BREACH style attacks. The important word here is 'potentially' because we are not aware of any tool that has confirmed we are vulnerable to a BREACH style attack. Of the standard mitigations available for protection against BREACH attacks, the Mahara application implements CSRF protection. This has the additional benefit of also protecting against CSRF attacks. | ||
=Site is potentially vulnerable to LUCKY13 attack= | |||
Some security tools report that the site is potentially vulnerable due to the use of CBC ciphers but they do not confirm whether the site is vulnerable or not vulnerable. Patches were released in 2013 (see [http://www.isg.rhul.ac.uk/tls/Lucky13.html "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols"]) and our infrastructure was built after that date. Therefore, we are using software that is not vulnerable. | |||
=TLS certificate is valid for more than 30 days= | =TLS certificate is valid for more than 30 days= | ||
Revision as of 17:21, 27 Haziran 2018
The Mahara project team receives reports of security vulnerabilities, particularly in the supporting project infrastructure, that after investigation we determine are not valid or do not need to be fixed.
Here are common examples.
TLS 1.0 is weak
TLS 1.0 is weaker than TLS 1.2. However, the protocol itself is not weak and has not been deprecated, unlike SSL 3.0.
The Mahara project infrastructure supports TLS 1.0 to ensure that sites are accessible by all required web browsers.
The use of TLS 1.0, and thus HTTPS, has significant benefits over not using encryption. If support for TLS 1.0 were disabled, the sites would need to support non-encrypted connections for some of the required web browsers, which is not an option we are persuing.
The Mahara project plans to continue to support TLS 1.0 on project infrastructure whilst an assessment using SSL Labs produces a result of A or A+.
Implementors of Mahara instances for use within their organisations can choose the web browsers they want to support and can configure support for TLS accordingly.
Weak TLS ciphers
Some ciphers supported by the Mahara project infrastructure are weaker than others. The currently supported ciphers are reviewed periodically against the required web browsers to ensure that they can connect.
Note that users with modern web browsers will connect using the highest TLS protocol and cipher mutually agreed. Therefore, weak TLS ciphers will typically only affect users with old web browsers.
The Mahara project plans to continue to support TLS 1.0 on project infrastructure whilst an assessment using SSL Labs produces a result of A or A+.
The configured TLS ciphers are periodically reviewed.
Implementors of Mahara instances for use within their organisations can choose the web browsers they want to support and can configure support for TLS accordingly.
Site is vulnerable to Poodle, BEAST, DROWN, Heartbleed, etc. attacks
We primarily rely on the checks performed by SSL Labs to confirm that the websites are not vulnerable to these attacks. We are not a specialist in your tools, how they work, or how to interpret them. If your tool disagrees with the result from SSL Labs, please contact the providers of your tool and SSL Labs to discuss the discrepancy.
Site is potentially vulnerable to BREACH attack
Some tools identify Mahara as potentially vulnerable to BREACH style attacks. The important word here is 'potentially' because we are not aware of any tool that has confirmed we are vulnerable to a BREACH style attack. Of the standard mitigations available for protection against BREACH attacks, the Mahara application implements CSRF protection. This has the additional benefit of also protecting against CSRF attacks.
Site is potentially vulnerable to LUCKY13 attack
Some security tools report that the site is potentially vulnerable due to the use of CBC ciphers but they do not confirm whether the site is vulnerable or not vulnerable. Patches were released in 2013 (see "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols") and our infrastructure was built after that date. Therefore, we are using software that is not vulnerable.
TLS certificate is valid for more than 30 days
Certificates are obtained from the Let's Encrypt certificate authority which has a certificate expiry of 90 days. In contrast, non-automated certificates from traditional certificate authorities are valid for one or two years.
Certificates on the Mahara infrastructure are automatically renewed using the management infrastructure. Manual revocations and re-issuing of certificates is possible if a certificate compromise is detected.
The Mahara project does not consider it necessary to re-issue the certificate faster than the default for Let's Encrypt. Further information is available at "Why ninety-day lifetimes for certificates" from Let's Encrypt.
TLS certificate is not included in Certificate Transparency
All of the Mahara project certificates are issued by Let's Encrypt. These can be verified in their Certificate Transparency list using https://crt.sh/?q=mahara.org
If they appear not to be included in Certificate Transparency in your tool, then it is likely not including Let's Encrypt data.
Autocomplete not disabled on password field
The OWASP Testing Guide version 4 includes a check for form-based password authentication with autocomplete disabled. This page has not been updated since 2014 and the guidance should be updated.
The setting is now ignored in modern web browsers for password fields:
- Internet Explorer - version 11 and Edge (November 2013)
- Firefox - version 30+ (February 2014)
- Safari - version 7.02+ (February 2014)
- Chrome - version 34+ (April 2014)
Additionally, the HTML5 specification allows password managers to override the flag.
Administration service exposed to the Internet
The SSH service is publicly accessible on the Mahara Git server. This is a requirement to allow developers with access to the service to communicate securely with Git to upload from anywhere on the Internet.
All SSH access is secured through the use of SSH keys.
HSTS header does not contain the includeSubDomains attribute
The HSTS header on mahara.org does not contain the includeSubDomains directive. This cannot be enabled until all parts of the Mahara infrastructure using the domain mahara.org support and are configured with HSTS including all sub-domains. Additionally, there must be confidence that there will not be a future requirement for a sub-domain without HSTS.
HSTS does not include preload list
The Mahara project cannot add the domain mahara.org on any web browser preload list until the includeSubDomains directive can be safely enabled. Once that has been done, we will evaluate if we wish to add the domain to any preload list.
Information leakage about application workings or source code
Issues that reveal server side source code or details about how the application works are not applicable because Mahara is an open source application. Therefore, anybody can download the source code from public repositories and install a local copy to explore how it works.
Directory browsing allows discovery and reading of meeting minutes
The directory https://meetbot.mahara.org can be browsed publicly. This is by design as a mechanism for publishing minutes of development meetings. The minutes are also published in a Git repository.