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 https://mangerbouger.fr, you can create accounts with @yeswehack.ninja

For the health prevention platform https://www.tabac-info-service.fr/, you can create accounts with @yeswehack.ninja

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-by-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()

Please note that if a vulnerability affects a third party (e.g. TrustCommander, or other), that is plugged into all our websites, only the two first reports submitted on the subject will get rewarded.

Additional reports on the same subject will no longer be rewarded.

Reward

Systemic issues

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 policy.

Scopes

Out of scopes

• Domains not listed in scope are by default all out of scope

Vulnerability types

Qualifying vulnerabilities

• SQL Injection (SQLi)
• Cross-Site Scripting (XSS)
• Remote Code Execution (RCE)
• Insecure Direct Object Reference (IDOR)
• Horizontal and vertical privilege escalation
• Authentication bypass & broken authentication
• Business Logic Errors vulnerability with real security impact
• Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
• Cross-Origin Resource Sharing (CORS) with real security impact
• Cross-site Request Forgery (CSRF) with real security impact
• Open Redirect
• Exposed secrets, credentials or sensitive information on an asset under our control and affecting at least one of our scopes.

Non-qualifying vulnerabilities

• Broken Link/Social media Hijacking
• Tabnabbing
• Missing cookie flags
• Content/Text injections
• Clickjacking/UI redressing
• Denial of Service (DoS) attacks
• Recently disclosed CVEs (less than 30 days sinces patch release)
• CVEs without exploitable vulnerabilities and PoC
• Open ports or services without exploitable vulnerabilities and PoC
• Social engineering of staff or contractors
• Presence of autocomplete attribute on web forms
• Vulnerabilities affecting outdated browsers or platforms
• Self-XSS or XSS that cannot be used to impact other users
• Any hypothetical flaw or best practices without exploitable vulnerabilities and PoC
• SSL/TLS issues (e.g. expired certificates, best practices)
• Unexploitable vulnerabilities (e.g. Self-XSS, XSS or Open Redirect through HTTP headers...)
• Reports with attack scenarios requiring MITM or physical access to victim's device
• Missing security-related HTTP headers which do not lead directly to an exploitable vulnerability and PoC
• Low severity Cross-Site Request Forgery (CSRF) (e.g. Unauthenticated / Logout / Login / Products cart updates...)
• Invalid or missing email security records (e.g. SPF, DKIM, DMARC)
• Session management issues (e.g. lack of expiration, no logout on password change, concurrent sessions)
• Disclosure of information without exploitable vulnerabilities and PoC (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets, EXIF Metadata, Origin IP)
• CSV injection
• Malicious file upload (e.g. EICAR files, .EXE)
• HTTP Strict Transport Security Header (HSTS)
• Subdomain takeover without a full exploitable vulnerability and PoC or not applicable to the scope
• Blind SSRF without exploitable vulnerabilities and PoC (e.g. DNS & HTTP pingback, Wordpress XMLRPC)
• Lack or bypass of rate-limiting, brute-forcing or captcha issues
• User enumeration (e.g. email, alias, GUID, phone number, common CMS endpoints)
• Weak password policies (e.g. length, complexity, reuse)
• Ability to spam users (email / SMS / direct messages flooding)
• Disclosed or misconfigured public API keys (e.g. Google Maps, Firebase, analytics tools...)
• Password reset token sent via HTTP referer to external services (e.g. analytics / ads platforms)
• Stolen secrets, credentials or information gathered from a third-party asset that we have no control over
• Exposed secrets, credentials or information on an asset under our control that are not applicable to the program's scope
• Pre-account takeover (e.g. account creation via oAuth)
• GraphQL Introspection is enabled
• DOM XSS via postMessage on TrustCommander Privacy Center

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 policy.

Hunting requirements

User agent

Please append to your user-agent header the following value: YWHSPF

Hunters collaboration

When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.