Centene_vdp

The scope for Centene’s Vulnerability Disclosure Program is defined on the Scope page. Please review the program’s Scope page and Out of Scope section and all other policies before submitting a report. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.

Your participation in our Vulnerability Disclosure Program is voluntary. Before finding and reporting any vulnerabilities, you are required to read and agree to the Vulnerability Disclosure Program Terms (the "Program Terms"). In these terms, references to "you" or "researcher" refer to a researcher that submits a high quality report in accordance with the Centene Vulnerability Disclosure. Program Terms and "we" or "us" refers to Centene.

---

Table of Contents

I. Program Terms

1. Safe Harbor
2. Program Eligibility
3. Program Rules
4. Disclosure Policy and Confidentiality
5. Legal

II. Submitting Reports

1. Report Quality
2. Out of Scope

III. Additional Info

1. SSRF Sheriff
2. Asset Recon
3. FAQ

---

I. Program Terms

1. Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Centene reserves all legal rights in the event of noncompliance with this policy.

2. Program Eligibility

To be eligible to participate in our Vulnerability Disclosure Program, you must:

• Be at least 18 years of age if you test using an Centene account.
• Not be employed by Centene or any of its affiliates or an immediate family member of a person employed by Centene or any of its affiliates.
• Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Vulnerability Disclosure Program.
• Not be using duplicate HackerOne accounts.

If (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Centene or its affiliates; or (iii) we determine that your participation in the Vulnerability Disclosure Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Vulnerability Disclosure Program

3. Program Rules

Do:

• Do abide by these Centene Vulnerability Disclosure Program Terms.
• Do respect privacy & make a good faith effort not to access, process or destroy personal data.
• Do be patient & make a good faith effort to provide clarifications to any questions we may have about your report.
• Do be respectful when interacting with our team, and our team will do the same.
• Do exercise caution when testing to avoid negative impact to customers and the services they depend on.
• Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.
• Do test for common mobile app vulnerabilities such as insecure data storage, insufficient transport layer protection, insecure authentication mechanisms, and improper session management.
• Do test for API vulnerabilities including insecure direct object references, improper input validation, insecure deserialization, and excessive data exposure.
• Do consider the security of third-party libraries and frameworks used within the mobile app or API.
• Do test for potential vulnerabilities arising from interactions between the mobile app and backend APIs.
• Do verify that user authentication and authorization mechanisms are implemented securely.
• Do test for insecure data transmission between the mobile app and backend servers.
• Do check for proper error handling to prevent sensitive information disclosure.

Do NOT:

• Do not leave any system in a more vulnerable state than you found it.
• Do not create any accounts on production sites for testing purposes. This is due to HIPPA regulations.
• Do not brute force credentials or guess credentials to gain access to systems.
• Do not participate in denial of service attacks.
• Do not upload shells or create a backdoor of any kind.
• Do not publicly disclose a Vulnerability without our explicit review and consent.
• Do not engage in any form of social engineering of Centene employees, customers, or partners.
• Do not engage or target any Centene employee, customer, or partner during your testing.
• Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.
• Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.
• Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.
• Do not interact with accounts you do not own.
• Do not use automated tools or scripts without prior approval, especially if they could lead to excessive traffic or potential disruption of service.
• Do not perform actions that could lead to unauthorized access to user data or compromise user privacy.
• Do not store sensitive information such as credentials or authentication tokens insecurely within the mobile app or transmitted over the network in plaintext.
• Do not tamper with the integrity of data exchanged between the mobile app and backend servers.
• Do not engage in any activities that could lead to the manipulation or alteration of user data without proper authorization.
• Do not neglect to obtain explicit consent from the organization before conducting security testing on their mobile apps or APIs.
• Do not overlook the importance of testing both the frontend (mobile app) and backend (API) components for vulnerabilities.
• Do not forget to report any vulnerabilities discovered during testing promptly and responsibly.

4. Disclosure Policy and Confidentiality

Any data you receive, obtain access to or collect about Centene, Centene affiliates or any Centene users, customers, employees or agents in connection with the Vulnerability Disclosure Program is considered Centene’s confidential information ("Confidential Information").

Confidential Information must be kept confidential and only used: (i) to make the disclosure to Centene under the Centene Vulnerability Disclosure Program; or (ii) to provide any additional information that may be required by Centene in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Centene 's request, you will permanently erase all Confidential Information for any systems and devices.

You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Vulnerability Disclosure submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.

Any unauthorized public disclosure will result in a program ban.

Please review HackerOne's disclosure guidelines for general best practices. For any reports submitted to Centene, this policy supersedes any conflicting HackerOne policies.

5. Legal

Centene reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms.

By making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.

By making a Submission, you give us the right to use your Submission for any purpose.

Please check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can subscribe to receive email notifications when this policy is updated.

II. Submitting Reports

1. Report Quality

High quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.

• Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.
• Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).
• Please include your understanding of the security impact of the issue.
• In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.
• Video only proof-of-concepts (PoCs) will not be considered.
• A vulnerability must be verifiable and reproducible for us to be considered in-scope.

2. Out-of-Scope

In addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:

• Physical or social engineering attempts (this includes phishing attacks against Centene employees)
• Ability to send push notifications/SMS messages/emails without the ability to change content
• Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)
• Negligible security impact
• Unchained open redirects
• HTTP Request Smuggling is a known-issue and is considered informative
• Reports that state that software is out of date/vulnerable without a proof-of-concept
• Highly speculative reports about theoretical damage
• Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue
• Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated
• SSL/TLS scan reports (this means output from sites such as SSL Labs)
• Open ports without an accompanying proof-of-concept demonstrating vulnerability
• CSV injection
• Best practices concerns
• Protocol mismatch
• Rate limiting
• Exposed login panels
• Dangling IPs
• Vulnerabilities that cannot be used to exploit other users or Centene -- e.g. self-xss or having a user paste JavaScript into the browser console
• Content injection issues
• Missing cookie flags on non-authentication cookies
• Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)
• Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores
• Issues that require physical access to a victim’s computer/device
• Stack traces
• Path disclosure
• Directory listings
• Banner grabbing issues (figuring out what web server we use, etc.)
• If a site is abiding by the privacy policy, there is no vulnerability.
• Enumeration/account oracles
• UUID enumeration of any kind
• Invite/Promo code enumeration
• Gift card enumeration
• Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Centene account exists
• Distributed denial of service attacks (DDOS)
• Clickjacking on pages with no sensitive actions.
• Clickjacking, unless an effective exploit can be demonstrated.
• Client browser vulnerabilities.
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Limited content reflection or content spoofing.
• Missing best practices This includes reports revealing vulnerabilities and exploits disclosed within a standard 30-day patching window.
• Password and account recovery policies.
• Password policies, i.e., complexity.
• Phishing or spear phishing attacks.
• POST-Based reports requiring a victim to request files hosted on out-of-scope assets.
• Previously known vulnerable libraries without a working Proof of Concept.
• Rate-limiting issues on endpoints that do not disclose PII or other relevant information.
• Self-exploitation.
• Software version disclosure.
• SSL / TLS best practices.
• Unauthenticated/logout/login CSRF.
• Vulnerabilities that cannot be reproduced.
• Zero-day vulnerabilities and exploits in vendor software.

Including following items also are out-of-scope for mobile applications:

• Vulnerabilities that require rooting/jailbreaking the device.
• Reports related to the presence of debug flags or developer mode without evidence of exploitation risk.
• Issues specific to outdated or unsupported operating systems or devices.
• Vulnerabilities that only affect users with specific device configurations or settings.
• Reports of sensitive data stored in device logs or crash reports without evidence of unauthorized access.
• Vulnerabilities requiring physical access to the device for exploitation.
• Reports related to app store policies or review processes.
• User interface inconsistencies or design flaws without clear security implications.
• Reports of excessive battery or data usage without evidence of malicious intent.
• Issues that only affect non-standard or custom ROMs.
• Vulnerabilities in third-party SDKs or libraries that are not directly integrated into the app's functionality.

SQL Injection Policy

• Do not alter any data.
• Do not change or interrupt server or database functionality.
• Do not destroy any data.
• Do not read or save sensitive
• Blindly counting rows and columns of databases is permissible.
• Generating outbound DNS requests is permissible.
• Listing database names and columns is permissible.
• Logic responses are permissible.

XSS Policy

• Stored XSS is classified as Medium-severity.
• Reflected XSS is classified as Low-severity.
• XSS on IE only is classified as Informational.
• Post-based XSS is classified as Not Applicable.

Critical Impact Critical Impact findings present a direct and immediate risk to Centene or most of our users. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:

• Server Side Injections (RCE, Command Injections)
• Improper Access Control/ Information Leakage of Highly Sensitive data (PHI/PII)
• SQL injection
• Unrestricted File upload
• Stored XSS on an authenticated member site

High Impact High impact findings usually materially impact several users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:

• Server-Side Request Forgery (SSRF)
• Path Traversal
• Stored XSS
• Significant Authentication Bypasses

Medium Impact Medium impact findings typically materially impact a small number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:

• HTTP Request Smuggling
• Misconfiguration
• IDOR (Insecure Direct Object References)

Low Impact Based on how our apps are setup, low impact findings usually only affect a very small number of users or have a limited security impact. These might include issues that require interaction or significant prerequisites to trigger.

• Reflected XSS
• Open Redirects

III. Additional Info

1. FAQ

Can I get Centene swag?

Centene does not currently offer swag.

Can Centene provide me with a pre-configured test account?

If credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.

What is required when submitting a report?

https://docs.hackerone.com/hackers/submitting-reports.html

How do I make my report great?

https://docs.hackerone.com/hackers/quality-reports.html

I submitted a report. Now what? I have questions.

https://www.hackerone.com/blog/how-bug-bounty-reports-work

What causes a report to be closed as Informative, Duplicate, N/A, or Spam?

https://docs.hackerone.com/hackers/report-states.html

What is an example of an accepted vulnerability?

Valid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.