Introduction
OceanBase is deeply aware of the significance of security and consistently prioritizes it as an indispensable element of our corporate agenda. OceanBase's dedicated security personnel are committed to the fortification of our applications and products. In pursuit of this objective, we extend a formal invitation to the security community at large to engage in the scrutiny and examination of OceanBase's applications and products.
Should any individual, during the course of such testing, identify a security vulnerability, we kindly ask you to contact us through responsible information disclosure. OceanBase pledges to engage in a prompt and diligent response to such communications and to implement necessary remediations to rectify reported concerns, thereby ensuring the resilience of our infrastructure and honoring our security obligations to our clients.
In addition, we shall persist with the extant OceanBase Community Security Group (SIG Security) program, proffering commensurate rewards to parties who contribute valid reports of security breaches.
Contact Information
Should any individual identify a security vulnerability or possess security-related recommendations, please initiate correspondence with us via security@oceanbase.com.
Scope of Attention
● OceanBase Database as listed on OceanBase Products
● Projects on OceanBase GitHub
● OceanBase Cloud Services
● Excluding components or products that have reached the end of their lifecycle
Guidelines for Information Disclosure
For Reporters:
● Prior to submission, please verify against our vulnerability database to confirm that the issue has not been previously reported.
● The environment or system information used for reproducing the issue (e.g., product version, operating system version, and other relevant information);
● The type of vulnerability (e.g., authentication bypass, buffer overflow, horizontal privilege escalation, denial of service, etc.);
● Step-by-step instructions for reproducing the vulnerability;
● Proof of concept code;
● Potential impact of the vulnerability;
● Recommendations for remediation of the vulnerability;
● Contact details of the individual reporting the vulnerability;
● Indicate whether there are any plans for public disclosure of the vulnerability.
For OceanBase:
● We will expedite the assessment of your submission and endeavor to establish contact within 2 business days.
● Our objective is to collaboratively establish a reasonable timetable for the remediation of the vulnerability with the affected parties.
● We will compose security advisories and public statements, urging users to update their systems accordingly.
● We commit to implementing preventative strategies, such as root cause analysis, the creation of test suites, and the proactive search for similar vulnerabilities through our continuous integration and testing platforms.
Code of Conduct for Security Researchers
● OceanBase advocates for responsible collaborative disclosure and advises vulnerability reporters to maintain confidentiality of vulnerability information prior to formal disclosure, ensuring that when vulnerabilities are revealed, we can concurrently offer our clients remedial solutions or mitigation measures.
● When reporting vulnerabilities associated with OceanBase, please endeavor to minimize access to confidential or non-public information, including third-party data, personal data, or any information marked as "Internal Use" by OceanBase. Apart from the submission to OceanBase, do not store, transfer, utilize, retain, disclose, or replicate such information.
● Unless expressly permitted, refrain from conducting any activities that could potentially impact the integrity or availability of OceanBase systems. Should service performance deterioration or inadvertent non-compliance or service interruption occur during the course of research, cease the use of any automation tools and report the incident immediately.
Response Process
Assessment Criteria
Vulnerability rating is based on the standards of CVSS 4.0, maintained by the international security organization FIRST, which provides a quantitative scoring mechanism for vulnerabilities through multiple dimensions and classifies the severity of vulnerabilities into categories (Critical, High, Medium, Low) according to the scores.
Assessment Principles
● When assessing the risk of vulnerabilities, it is imperative to consider specific attack scenarios and evaluate the impact of the vulnerability exploitation on the system's confidentiality, integrity, and availability within that scenario.
● If a vulnerability has multiple attack scenarios, the attack scenario with the greatest impact, that is, the highest CVSS score, should be used as the baseline.
● Vulnerabilities introduced by third-party components must be assessed based on the usage of the component within the product and the attack scenarios identified for the vulnerability.
OUT OF SCOP
Reports on non-security related or outdated best practices are generally not accepted, such as (non-exhaustive list):
○ Subdomain takeovers for out of scope domains
○ Clickjacking on pages with no sensitive actions
○ CSRF on unauthenticated forms or forms with no sensitive actions
○ Attacks requiring MITM or physical access to a user's device
○ Previously known vulnerable libraries without a working PoC
○ Missing best practices in SSL/TLS configuration
○ Any activity that could lead to the disruption of the service
○ Rate limitation or bruteforce issues on non-authentication endpoints
○ Missing HttpOnly or Secure flags on cookies
○ Missing DNS/email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
○ Vulnerabilities only affecting users of outdated or unpatched browsers
○ Software version disclosure, banner identification issues, or descriptive error messages
○ CSP uses unsafe-inline
○ Missing certificate authority
○ Missing HSTS
○ Missing security headers
○ No X-Frame Options header
○ Open redirect using host header
Known false positives are also not accepted, such as (non-exhaustive list):
○ Content injection
○ Error messages
○ Server version disclosure
○ CSRF with minor security risks, e.g. CSRF on logout
○ CSRF token leak
○ JavaScript errors
Reward Standard
OceanBase shall issue rewards for each new valid security vulnerability report. The range of the reward amount will be based on factors such as the level of the vulnerability, the scope of impact, the CVSS score, etc. We will also extend our gratitude to the vulnerability reporters in each security announcement.
List of Abbreviations：
CSRF - Cross-Site Request Forgery
DNS - Domain Name System
MITM - Man-In-The-Middle attack
PoC - Proof of Concept
SSL/TLS - Secure Sockets Layer/Transport Layer Security
SPF - Sender Policy Framework
DKIM - DomainKeys Identified Mail
DMARC - Domain-based Message Authentication, Reporting & Conformance
CSP- Content Security Policy
HSTS - HTTP Strict Transport Security
