OneDoc
OneDoc redefines digital health in Switzerland by simplifying the lives of patients and practitioners
Reward
Program
Hacktivity
Important
⚠️⚠️ Using a real doctor for your test is strictly forbidden ⚠️⚠️
Please use the fake doctor - Dr Bug Bounty to do your tests.
About
Welcome to the OneDoc Bug Bounty program! We're excited to offer a way for the security community to help us find and fix vulnerabilities on our platform.
Our mission, as a leading healthcare service provider in Switzerland, is to ensure the confidentiality, integrity, and availability of our users' (patients and healthcare professionals) data.
We believe that no technology is perfect and that working with skilled security researchers is crucial in identifying weaknesses in our technology.
If 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.
Program Rules
We ask that you conduct your bug bounty activities in a way that does not impact the experience of our platform. If you are interested in testing something that may be considered dangerous, please contact us through the Yes We Hack platform to provide the necessary testing conditions.
Testing Policy and Responsible Disclosure
Please adhere to the following rules while performing research on this program:
- Denial of service (DoS) attacks on our applications, servers, networks or infrastructure are strictly forbidden.
- Do not perform tests that could cause degradation or interruption of our services.
- Avoid using automated tools, or use them the gentle way (max 5 requests per second).
- Do not leak, manipulate, or destroy any user data or files in any of our applications/servers.
- Do not copy any files from our applications/servers and disclose them.
- No vulnerability disclosure, full, partial or otherwise, is allowed.
- All testing made under the OneDoc Bug Bounty program must not have any negative impact on the care team or patients, in accordance with the “Hunting Requirements” below.
- Only trigger notifications targeting email addresses and phone numbers you own and do not trigger large amounts (>30) of notifications (sms/emails).
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 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.
This excludes, but is not limited to:
- Stolen credentials gathered from unidentified sources (e.g. …)
- 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 :
Source of leak is in-scope | Source of leak belongs to our organization but is out-of-scope | Source of leak does not belong to our organization and is out-of-scope | |
---|---|---|---|
Impact is in-scope (e.g. valid credentials on an in-scope asset) | Eligible | Eligible | Not Eligible |
Impact is out-of-scope (e.g. valid credentials for an out-of-scope asset) | Eligible | Not Eligible | Not Eligible |
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 sensitivie information leak, DO NOT extract/copy every document or data that is exposed and limit yourself to describe and list what is exposed.
Reward Eligibility
We are happy to thank everyone who submits valid reports which help us improve the security of OneDoc, 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).
- The report must contain the following elements:
- Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and OneDoc, and remediation advice on fixing the vulnerability
- Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
- Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc.
- You must not break any of the testing policy rules listed above
- You must not be a former or current employee of OneDoc or one of its contractors.
Reward amounts are based on:
- Reward grid of the report's scope
- CVSS scoring and actual business impact of the vulnerability upon performing risk analysis
Complements about our scopes
onedoc.ch
Our public application, which allows patients to:
- Look for a healthcare professional
- View the profile of a healthcare professional
- Book and manage appointments with a healthcare professional
- Create an account on OneDoc (at the time of the booking)
telehealth.onedoc.ch
Our video consultation application, accessible through a link sent to the patient by email so they can remotely consult their doctor. Patients should not be able to access a video room that is not created for them.
pro.onedoc.ch
Our professional application, only accessible to registered and verified healthcare professionals. Patients should not be able to login.
Reward
Asset value | CVSS | CVSS | CVSS | CVSS |
---|---|---|---|---|
€100 | €500 | €2,500 | €5,000 | |
€100 | €250 | €1,000 | €2,500 |
Scopes
Scope | Type | Asset value | Expand rewards grid |
---|---|---|---|
https://www.onedoc.ch | Web application | ||
Low Medium High Critical | |||
https://pro.onedoc.ch | Web application | ||
Low Medium High Critical | |||
https://api.onedoc.ch | API | ||
Low Medium High Critical | |||
https://telehealth.onedoc.ch | Web application | ||
Low Medium High Critical |
Out of scopes
- All domains or subdomains not listed in the above list of 'Scopes'
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 15 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
Hunting requirements
Account access
-
To test appointment booking : Do not use your real OneDoc patient account or book with a real healthcare professional listed on onedoc.ch. You must:
- Create a test patient account using your YesWeHack email aliases which are available here. Our security researchers will be able to access account details from the fake doctor database.
- Make an appointment with our fake doctor.
-
To test our telehealth (video consultation) application
- you can book a "remote" appointment with our test doctor (selecting "Type of consultation" -> "remote").
-
To create a patient test account:
- You need to make an appointment with our fake doctor. As part of the appointment booking, you will be able to create a free patient account with OneDoc.
User agent
Please append to your user-agent header the following value: ' -BugBounty-onedoc-31337 '.
Hunters collaboration
When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.
For more information, see help center.
Note: For reports that have already been rewarded, it is not possible to redistribute the rewards.