|
Note
|
The following is general security advice that may be relevant to a website or application using {productname}. |
{companyname} values the work of security researchers in improving the security of technology products worldwide. We welcome researchers who wish to responsibly disclose vulnerabilities in our products or systems.
Note that we do not offer any “bug bounty” program or any form of payment for disclosed vulnerabilities.
To report a potential security vulnerability, contact our Security team at infosec@tiny.cloud.
In line with the United States National Infrastructure Advisory Council (NIAC) Vulnerability Disclosure Framework (PDF link), Tiny requests community members reporting potential security vulnerabilities maintain the confidentiality of their report and discovery until Tiny has investigated the issue and taken action to fix it.
Tiny will communicate with you regarding the status of your report and will, with your permission, publicly attribute the security issue’s discovery to you after the issue has been fixed and disclosed.
To protect {productname} users, {companyname}:
-
Patches Cross-Site Scripting (XSS) vulnerabilities,
-
Keeps {productname} dependencies up to date, and
-
Provides recommendations about enforcing HTTPS with HSTS, and
-
Provides information about how to configure a Content Security Policy that works with {productname}.
{productname} filters content such as scripts from the editor content, however, client-side applications can be by-passed by attackers. {companyname} recommends processing received editor content through server-side filters.
SVGs (Scalable Vector Graphics) are not supported in {productname} to protect our users and their end-users. SVGs can be used to perform both client-side and server-side attacks.
From the 1st of January 2020, Security Advisories for patched XSS vulnerabilities will be published on the {productname} GitHub repository Security page.
The {companyname} security team strongly recommends that customers embedding {productname} configure their web servers to include the HTTP Strict Transport Security (HSTS) header for websites served over HTTPS. This can be achieved by updating the server configurations to enable HSTS.
HSTS ensures that encrypted communications are exclusively used, mitigates downgrade attacks, and enhances the protection of user data. While integrating HSTS is optional for {productname}, adopting this best practice significantly reduces the risk of vulnerabilities in projects utilizing {productname}.
|
Important
|
Without HSTS, users accessing a website may be vulnerable to man-in-the-middle (MITM) attacks. Attackers can exploit this vulnerability by intercepting unencrypted HTTP traffic, redirecting users to malicious sites, or executing downgrade attacks to force connections over HTTP instead of HTTPS. This lack of encryption jeopardizes sensitive user data, including credentials, session cookies, and personal information. By enabling HSTS, these risks are effectively mitigated, as the browser enforces secure HTTPS connections for all future interactions with the site. |
For comprehensive guidance on implementing HSTS, refer to the following resources:
The following security risks are not {productname} specific, but are the main security risks associated with websites or applications which allow user inputs. Protecting your services and users from these risks requires server-side handling. Note that attackers will likely bypass any editor and attack the server directly, rather than use the text editor as a vector.
For information on mitigating these risks, see the provided links in each section.
Cross-Site Scripting (XSS) involves using website or application inputs to inject malicious, client-side code. This code can then be used to attack your users.
Although {productname} filters content such as scripts from the editor content, precautions should be taken to protect your users, such as enabling a Content Security Policy (CSP) and server-side filtering.
For information on Cross-Site Scripting and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Cross-Site Scripting (XSS).
Injection attacks involve attackers using website or application inputs to run server-side code, such as SQL, NoSQL, or LDAP scripts.
If user inputs are not properly sanitized server-side, host devices and user data can be compromised.
For information on Injection-related security issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Injection.
The transmission or storage of data without strong cryptographic protection leaves this content exposed to attackers.
Loading insecure content into the editor, or submitting content from the editor over an insecure connection exposes the user and the host server to attack.
For information on Sensitive Data Exposure issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Sensitive Data Exposure.
Broken or incorrectly implemented authentication and session management exposes both user data and the server to attackers, allowing them to impersonate users, including administrators.
Broken Authentication or session management may allow attackers to change or submit data through the editor, or any input field, as the compromised user account.
For information on Broken Authentication issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Broken Authentication.
Using outdated components on your website or application allows attackers to exploit known vulnerabilities.
{productname} is patched when vulnerabilities are discovered. Keeping {productname} and your other dependencies up to date will protect you and your users from known vulnerabilities.
For information on issues related to using components with known issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Using Components with Known Vulnerabilities.
For general security advice about securing your website or application, visit the Open Web Application Security Project (OWASP).