Security/Responses to common security reports

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.

We also note that BEAST is only a client-side vulnerability as explained by SSL Labs. It requires a way for client code in the browser (hostile Java or hostile Javascript) to emit cross-domain requests with a high level of control at the bit level. The two known ways to do that (a draft version of WebSockets, and a vulnerability in the Java VM implementation) have been fixed. Additionally, browsers and operating systems have added workarounds, namely the 1/n-1 split: whenever a TLS record is to be emitted, two records are sent, the first one containing only one byte of application data. This workaround prevents BEAST from being applied. See also Stack Exchange.

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.

X-Frame-Options HTTP header on the wiki

The MediaWiki configuration setting for the X-Frame-Options HTTP header has been configured to 'DENY'. In MediaWiki, this header is only activated for special pages, such as the login page and edit pages. It is not set for others that are browsed passively as they don't need the protection.

Missing Content Security Policy (CSP)

Having a CSP set is a security enhancement. It is on the roadmap for Mahara.