Santé Publique France Bug Bounty Program

Santé publique France

Santé publique France is the national public health agency.

Created in May 2016 by ordinance and decree, it is a public administrative establishment under the supervision of the Ministry of Health. Our mission: to improve and protect the health of populations. This mission revolves around three major axes: anticipate, understand and act.

This program concerns all the public sites of Santé publique France with a strong image risk.

The scopes of our programs are detailed further below, but here is a quick explanation of the services available on the urls listed :

• institutional web sites
• health prevention web sites

Program Rules

For the health prevention platform Mangerbouger, you can create accounts with @yeswehack.ninja https://yeswehack.com/user/tools/email-alias

For the health prevention platform TabacInfoService, you can create accounts with @yeswehack.ninja https://yeswehack.com/user/tools/email-alias

We believe that no technology is perfect and that working with skilled security researchers is crucial in identifying weaknesses in our technology.
If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.
Any type of denial-of-service attacks is strictly forbidden, as well as any interference with network equipment and our infrastructure.

Reward Eligibility and Testing precautions

We are happy to thank everyone who submits valid reports which help us improve the security of Santé publique France however, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability (see below)
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through yeswehack.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must avoid tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about requests per second).
• You must not leak, manipulate, or destroy any user data.
• You must not be a former or current employee of Santé publique France or one of its contractors. Reports about vulnerabilities are examined by our security analysts.
• Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay. No vulnerability disclosure, including partial is allowed for the moment.
• Do not modify the data of our production environment. Restrict your tests to the PPROD environment when testing data integrity.

Notes on Vulnerabilities (for tests on the production environment)

• You must avoid tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about 30 requests per second).
• To demonstrate impact on RCE/SQLi/SSRF, please only use the permitted commands listed here below in your PoC. If we would like you to go further, we will mention it directly on your report
• RCE : id / whoami / hostname / ifconfig
• SQLi : send us the version and/or the database diagram
• SSRF : content page or specific behavior
• Subdomain takeover without interaction on a production environment will be considered as max CVSS High
  Example: A subdomain takeover can be used to perform an external resource hijacking (JavaScript file for example) which will be loaded on another domain, no interaction is needed by victim user to execute this malicious JS.
• Subdomain takeover with interaction on a production environment will be considered as max CVSS Medium
  Example: A subdomain takeover can be performed but it's only visible if a victim user visits this domain.
• Subdomain takeover, DNS dangling, Cache Poisoning...: If you find multiple similar issues across multiple scopes at the same time, we recommend submitting all the affected assets in a single report. We will, on a case-to-case basis, consider increasing the bounty amount accordingly.
• Discovered vulnerabilities must not have any impact on other users' activities, or modify the application. E.g.: stored XSS should use console.log() instead of the usual alert(), confirm(), prompt()

Reports of leaks and exposed credentials

We are open to some types of reports related to exposed secrets, credentials or information.
Please pay attention to our list of Qualifying/Non-Qualifying vulnerabilities, as well as our Scope and the following rules.

In order not to encourage dark and grey economies, in particular the purchase, resale and trade of identifiers or stolen information, as well as all types of dangerous behavior (e.g. social engineering, ...), we will not accept or reward any report based on information whose source is not the result of failure on the part of our organization or one of our employees/service providers

Eligible reports

Reports of exposed secrets, credentials and sensitive information will be considered eligible if it complies with the following:

• The source of exposure/leak is under MyCompany’s control, directly or indirectly.

e.g. stolen information or bundled information from a random source is not eligible.

• The exposed information has been verified (or tested) and confirmed

If you identify a source (under our control) that is leaking multiple data, we kindly ask you to report it in a single report and we will consider the impact based on the nature and depth of the exposed data.

To summarize our policy, you may refer to this table :

Important precautions and limitations

As a complement to the Program’s rules and testing policy :

• DO NOT alter compromised accounts by creating, deleting or modifying any data
• DO NOT use compromised accounts to search for post-auth vulnerabilities (they won’t be eligible anyway)
• DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your PoC (screenshot, server response, JSON file, etc.) as much as possible.

In case of exposed credentials or secrets, limit yourself to verifying the credentials validity
In case of sensitive information leak, DO NOT extract/copy every document or data that is exposed and limit yourself to describe and list what is exposed.