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 :

In the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program’s scope and identified outside of our program’s scope, such as:

• Exposed credentials in/from an out-of-scope asset/source
• Sensitive information exposed in/from an out-of-scope asset/source

Also, 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 behaviour (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.

This excludes, but is not limited to:

• Stolen credentials gathered from unidentified sources
• Exposed credentials that are not applicable on the program’s scope
• Exposed GitHub/GitLab (or similar) instance with no direct relation with our program’s scope
• Exposed secrets (e.g. API tokens/keys or other technical credentials) that are not directly related to the program’s scope
• Exposed PII on an out-of-scope asset

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