Systems
Any system or service that handles sensitive data belonging to Celtra or Celtra clients is in the scope of the program. The vast majority of the sensitive content can be found on the following domains:
Examples:
Main products:
Support pages:
Authentication Service:
Additionally, Celtra stores sensitive data on thi3rd- party services such as Google Workspace, Atlassian Jira, GitHub, etc. Any flaws that can lead to sensitive data exposure or cause serious business interruption on systems not owned by Celtra that contain Celtra or Celtra customers' data, will also qualify (for example, Publicly shared employee calendars).
Types of vulnerabilities
In general, any design or implementation issue that substantially affects the confidentiality or integrity of user or customer data is in the program's scope.
Examples include:
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF), except exclusions listed under the out-of-scope section
Authentication or Authorization Flaws (Broken Access Control)
Sensitive Data Exposure
Security Misconfiguration
Server-Side Request Forgery (SSRF)
Server-Side Template Injection (SSTI)
SQL injection (SQLI)
Remote Code Execution (RCE)
Local or Remote File Inclusions
While the above list represents our primary focus for security research, we are interested in reports for all vulnerabilities that can lead to sensitive data disclosure or can cause serious business disruption.
Out-of-scope vulnerabilities & accepted risks
Approximately 90% of the submissions we receive through our vulnerability reporting program are ultimately deemed to have little or no practical significance to product security. The experience of reporting an issue and not qualifying for a reward can be disappointing to less experienced researchers – and the high volume of submissions makes it harder for us to spot valid, high-impact reports.
In the spirit of openness, we decided to publish examples of some of the most common non-qualifying report types, with a brief explanation of our reasoning behind not treating them as a security risk or otherwise not paying out rewards.
Invalid attack scenarios
Any physical attack against the user's device, Celtra property or its data host providers;
Social engineering of Celtra staff or contractors;
Configuration issues on end-users machines. (for example, password storage or cache settings);
Attacks requiring a Man-in-the-Middle, with no other possible exploitation;
Attacks affecting only the users of outdated browsers, plugins or OS.
When you sign up for a Celtra account and create a profile, we display the email in multiple places and generally allow it to be discovered by others who already know your email address.
In this spirit, we do not treat reports of locations that allow you to discover email addresses, for example, login or commenting capabilities, as a security vulnerability.
Open redirectors
Open redirectors take you from a Celtra URL to another website chosen by whoever constructed the link. Some members of the security community argue that the redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.
Our take on this is that tooltips are not a reliable security indicator, and can be tampered with in many ways, so we generally hold that a small number of properly implemented redirectors offers fairly clear benefits and poses minimal practical risk.
Reflected file download
A so-called "Reflected File Download" (RFD) is a technique that allows the attacker to force the browser to initiate a file download from a given origin with partially-controlled content. That might be used to create a social engineering attack, in which users trust that the file is, for example, a legitimate software installer coming from a website users trust.
We understand this attack technique, but at the same time believe it's not a very practical one. When deciding whether to execute a file, users rely on the context in which the file download was initiated, not on where the file was actually hosted. In some browsers, this information is not even displayed by default, and one can see it only on a Downloads page. RFD can be used to create a social engineering attack, but there are other, more practical ways to achieve the same.
Occasionally, we get reports describing Excel formula injection into CSV files. Specifically, the reports mention that one of our products with an 'export to CSV' feature can be abused to inject Excel formulas into a generated file downloaded by the user. The attack scenario mentions that, under certain circumstances, those formulas could be executed by the application opening the CSV file (Microsoft Excel is commonly mentioned). The consequence is not just running arithmetic operations on a victim's machine (though we all like =1338-1), but may amount even to running arbitrary commands.
CSV files are just text files (the format is defined in RFC 4180), and evaluating formulas is a behavior of only a subset of the applications opening them - it's rather a side effect of the CSV format and not a vulnerability in our products which can export user-created CSVs. The application should mitigate this issue by importing/interpreting data from an external source, as, for example, Microsoft Excel does by showing a warning. In other words, the proper fix should be applied when opening the CSV files rather than when creating them.
In conclusion, we don't think the risk introduced by this behavior is significant enough to warrant a change in our product.
Lack of HTML sanitization where data is not intended to be rendered as HTML
Sometimes, we get reports that the API does not perform appropriate validation of user-supplied input, which is reflected back to the user. When such information is rendered as HTML content, it can be used to execute a cross-site scripting attack. In such cases, we take this as a severe security vulnerability that needs to be resolved as soon as possible. However, when input is rendered as a JSON or text file, it is not considered a security issue, because the browser will not execute any JavaScript.
Campaign preview is accessible if Campaign ID is known
This is an intentional design decision aimed at allowing easy sharing of preview links.
Logout CSRF
For better or worse, the design of HTTP cookies means that no single website can prevent its users from being logged out; consequently, application-specific ways of achieving this goal will likely not qualify.
Clickjacking
When evaluating reports of cross-site request forgery (CSRF) or clickjacking vulnerabilities, we always try to understand their impact when actually exploited. If a successful attack does not change the state of Celtra accounts in any way, or if the change is very inconsequential, the report will usually not qualify for a reward.
Similarly, cross-site request forgery for actions that do not require authentication, or can only be performed using other unpredictable values (passwords, secret invitation codes, etc.) are often also deemed to be non-issues.
Issues that result in Denial of Service (DoS)
We are aware that any issue resulting in Denial of Service is unpleasant and such scenarios should be prevented. However, any issue that could result in Denial of Service of Celtra webpages, servers at the network or application layer, or in any other system Celtra uses is unlikely to cause sensitive data disclosure. Therefore, reports addressing DoS will not qualify for a reward.
Commonly reported SSL/TLS vulnerabilities
Bug hunters sometimes report that the SSL/TLS configuration of one of our services is vulnerable to some of the SSL/TLS vulnerabilities disclosed in recent years. In this context, CRIME, BEAST, and POODLE are often mentioned, together with the usage of the RC4 cipher.
We always carefully validate each report, and the issues mentioned above often turn out to be invalid.
SPF softfail (~all) policy
We take email security seriously and work to ensure nobody can impersonate @celtra.com or @celtra.io email addresses. Our goal is that all DMARC-compatible email services reject illegitimate spoofed emails or mark them as spam.
The softfail (~all) policy achieves this goal and is a deliberately chosen trade-off.
We are more than happy to be notified that any of the software, services or protocol we may use are vulnerable. However, we cannot reward you for anything not under our control.
Vulnerabilities found in systems offered by Celtra vendors where Celtra doesn’t have control, should additionally be reported directly to the vendor according to their disclosure policy (if any).
Issues without clearly identified security impact
Although we wanted to give you an overview of what kind of reports on vulnerabilities will most likely not qualify for a reward, we cannot list them all here. In general, any reported issue that cannot lead to sensitive data disclosure will probably be ruled out for any reward. Examples of such reports are usually issues identified by automated scanners, such as patches for security updates without known or practical exploits.