Liferay Security

Background Statement

Liferay is committed to producing high quality and secure products.  The security of our products is very important to our customers and the wider Liferay community, and we have processes in place to ensure that any security-related issues are promptly addressed and that our customers' data is kept secure.  As a technology, Liferay is a valuable tool for building web sites, and uses industry standard security technology to minimize the chance of security issues. 

Liferay also recognizes the important role that independent security researchers play, and we encourage responsible reporting of vulnerabilities discovered in our products.  For more information about reporting, see the following sections.

Liferay Security Policy

Liferay has developed the following policy that applies to reported security issues in our products.

Initial Report

Liferay can receive reports of security vulnerabilities from various sources (e.g. JIRA tickets, social media, external blogs, and internal discoveries). Within 72 hours of discovering or being notified of a potential vulnerability, Liferay will attempt to reproduce the issue using the supplied information. If the vulnerability is reproducible, a private ticket is created if one does not already exist, the vulnerability is classified into one of the defined severity levels, and the details of the vulnerability are documented in this ticket.

Triage and Classification

Security vulnerabilities are classified by Liferay into different severity levels based on a number of factors, the most important of which is the perceived risk to Liferay deployments.

  • Severity Level 1 (SEV-1) - This includes situations where complete system access is possible, including access to the underlying system's resources, the potential for data corruption or compromise, or the ability to execute arbitrary code by an attacker. It also includes issues that do not allow complete system access, but can impact service levels and system reliability, or affect systems other than Liferay itself. This typically includes Denial-of-Service vulnerabilities and cross-site scripting and related vulnerabilities.
  • Severity Level 2 (SEV-2) - This level is used for minor vulnerabilities, including cross-site scripting, permission problems, and information leak.

Notification

Security vulnerabilities are particularly important to all users of Liferay, including users of its Community Edition (especially those reported to Liferay from its open source community!) As a Liferay user, it is important for you to be aware of and be notified when potential vulnerabilities are discovered.

Details of the vulnerability, any potential workarounds, and pointers to patches or other fixes will be made public via the Community Security Team and its Known Vulnerabilities page.

Patch Availability

Fixes for issues in the form of source code and/or binary patches will be made available to all users through the Liferay Community Security Team.  This team actively monitors Liferay's open source code commits and uses them to create patches for the latest CE release.  Members of the team are volunteer representatives from the Liferay community with a proven security-focused track record, and the team provides a valuable service to our open source community.  If you are interested in getting involved, visit the team's page and contact the maintainers.

 

 

Security Testing Policy for Independent Security Researchers 

Liferay recognizes the important role that independent security researchers play, and we encourage responsible reporting of vulnerabilities discovered in our products. For more information about reporting, see the following sections.

Reward

We do not offer any monetary reward, but we do publicly recognize new and unique submissions on our Hall of Fame.

In Scope

Application AlloyEditor
Application AlloyUI
Application Clay
Application Liferay Commerce
Application Liferay DXP
Application Liferay Faces
Application Liferay IDE
Application Liferay Mobile SDK
Application Liferay Portal
Application Liferay Screens
Application Liferay Sync
Application Metal.js
Application PortletMVC4Spring
Application Applications in Liferay Marketplace that are owned by Liferay
Website Liferay Analytics Cloud
Website Liferay DXP Cloud
Website *.alloyeditor.com
Website *.alloyui.com
Website *.clayui.com
Website *.liferay.cloud
Website *.liferay.com (except subdomains listed in the out of scope section below)
Website *.liferay.design
Website *.liferay.dev
Website *.sennajs.com

Out of Scope

Application Applications in Liferay Marketplace that are not owned by Liferay
Website *.lfr.cloud
Website help.liferay.com
Website login.liferay.com
Website Any website that is not owned by Liferay including, but not limited to, sites with a Liferay subdomain (e.g., liferay.example.com)
Website Any websites and/or services that Liferay DXP Cloud host on behalf of it’s customers.
Physical intrusions

Notes:

For applications:

  • We use the term “application” in this document to cover applications, frameworks and libraries.
  • Please reproduce the vulnerability in a supported version before submitting. (Note: Only the most recent release is supported for most community applications). We still welcome submissions for vulnerabilities against unsupported versions, however, it may take us longer to respond and the submission may not qualify for credit in our hall of fame.
  • Vulnerabilities in a third party library should be reported to the company/organization the developed/published the library.
  • We will give credit for reporting an application that uses a third party library with known vulnerabilities if we are unaware of the vulnerabilities in the library 30 days after the vulnerabilities has been published. We have our own monitoring in place for this so we want to give our monitoring tools a chance to do its job. However, if we missed the vulnerability, we’ll give you credit. In addition, please provide evidence/PoC that the vulnerability is exploitable from the application.
  • We do not review reports produced by automated scanners. Please test the issue on your own to ensure it is exploitable and provide a PoC with your submission.
  • We do not give credit for submissions related to best practices if there is no actual vulnerability.

For websites:

  • Rate-limit automated scanning to a maximum of one (1) request per second.
  • No testing for denial of service (DoS). If you suspect there is a DoS vulnerability, please let us know why you think there is a DoS vulnerability and we can work with you to determine if there is a vulnerability. We implement rate limiting and you may be blocked if you perform an excessive number of requests.
  • Do not test against another user’s account or any account you do not have explicit permission to access.
  • Do not access, destroy or negatively impact another user or another user’s data.
  • We will give credit for reporting a website running software from a third party vendor (e.g., Jira) with known vulnerabilities if we are unaware of the vulnerabilities 30 days after the vulnerability has been published (or 14 days for critical vulnerabilities with a .CVSS score of 9.0+). We have our own monitoring in place for this so we want to give our monitoring tools a chance to do its job. However, if we missed the vulnerability, we’ll give you credit.
  • We do not give credit for submissions related to best practices if there is no actual vulnerability.

Liferay Analytics Cloud / Liferay DXP Cloud:

  • We do not provide credentials or test accounts for testing purposes. However, you’re free to test the part of the service that is publicly accessible.

Applications in Liferay Marketplace:

  • We appreciate submissions for all applications that are owned by Liferay, but we do not give credit for applications that are labeled as “Labs”.

web.liferay.com:

  • We currently only accept reports for critical vulnerabilities (e.g., server compromise, authentication bypass, complete service unavailability)

Common Exclusions

The following are common submissions we receive that we consider as acceptable risk, false-positive, and/or out-of-scope.

  • Limited content reflection: We do not consider all instances of reflected content to be a security vulnerability. Reflecting some parameter value in the response is often expected as long as the value has been properly escaped or sanitized.
  • Logout CSRF: We are aware of this issue and believe that this is an acceptable risk.
  • Tabnabbing: We are aware of this issue and believe that this is an acceptable risk.
  • CSV command injection in generated CSV files: CSV files are just plain text files that we generate. If an application that opens CSV files treats the text in the CSV files as commands, we believe that application opening the CSV file should be responsible for fixing this problem.
  • Email address plus (+) aliasing is not recognized and these email addresses are treated as different email addresses: Although some email providers support plus aliasing, plus aliasing is not a standard. Some email providers do not support plus aliasing and will treat these email addresses as different accounts. We don’t believe that maintaining a list of email providers that support plus aliasing is a good use of our development effort at this time.
  • A period in an email address is ignored but these email addresses are treated as different email addresses: Although some email providers ignore periods, this is not a standard. Some email providers do not ignore the period and will treat these email addresses as different accounts. We don’t believe that maintaining a list of email providers that ignore periods is a good use of our development effort at this time.
  • Jira filter disclosures: We do not accept submissions that only informs us that we have publicly accessible Jira filters. As an open source project, many of the filters are public on purpose. To receive credit, you must identify a specific filter that exposes private/sensitive data.
  • Log files in Jira: Logs files are often attached to Jira tickets in order to assist with bug fixing so an attached log file is not automatically considered a vulnerability. To receive credit, you must identify the private/sensitive data in the log file.
  • OS command injection in Gogo shell and the script console in Liferay DXP & Liferay Portal: The ability to execute OS commands is a known feature and is limited to users with the portal administrator role.
  • Liferay DXP & Liferay Portal is bundled with a version of Apache Tomcat with known vulnerabilities: The Tomcat bundles are provided as a convenient starting point and we do not consider it an integral part of the Liferay DXP/Portal application. Apache Tomcat can be upgraded to a newer version independent of the Liferay DXP/Portal.
  • Directory listing enabled on docs.liferay.com: Directory listing is enabled on purpose

Submission

Submissions via email can be sent to [email protected]. For secure communication, our PGP key can be found here (or here).

The key fingerprint is: 9325 A69B 681E EFA7 DA94 1233 D2B5 73D2 8A47 A0FF
The key ID is: 0xD2B573D28A47A0FF

You may also report vulnerabilities via Jira - be sure to follow the guidelines in the Jira reporting page (in particular, select the Secure privacy option when creating the ticket).

Please do not submit vulnerabilities on any public chancel, including but not limited to, Liferay community forums, blogs comment pages and social media.

Please attach all images and videos supporting your submission directly to your submission. Do not use third party sites to host the files.

If the vulnerability involves unauthorized access to data on a Website, please provide all IP addresses you used for testing.

Disclosure

Liferay believes in Responsible Disclosure. This means that when you are reporting new bugs related to security vulnerabilities, you give Liferay a chance to respond (evaluate, resolve) security bugs before its details are publicly and fully disclosed.

Please be aware that vulnerabilities within an application may take longer to resolve than what you may be used to. Except in the case of a critical vulnerability, an application vulnerability will most likely be included in the next regular release of the application.

Safe Harbor

We appreciate ethical security research and want to encourage it. Therefore we will consider all activities conducted in accordance with this policy as authorized conduct ( in accordance with the Computer Fraud and Abuse Act (CFAA) and any similar laws) and exempt from the Digital Millennium Copyright Act (DMCA) and any restrictions set forth in the terms applicable to the concerned applications or services. We will not bring any legal action against security researchers acting in accordance with this policy or accidentally violating this policy acting in good faith.

Except as explicitly permitted above, you are expected to conduct in accordance with all applicable laws. Please note that while we can authorize security research on our own applications and services, any third party applications or services on which Liferay’s applications and services may rely are not covered by this policy and we cannot and do not authorize security research on such third party applications and services.

If you are not sure whether your planned activities are in line with this policy, please reach out to us via [email protected] prior to conducting such activities.