Important note!
PLEASE confine all testing to our sandbox environment (check the scope!), and include a custom header (as mentioned below) in requests wherever possible so we can deconflict testing activity from real threats in our log review.
- “X-HackerOne-Research: [H1 username]”
There are BApps that can help with this, and certain versions of Burpsuite natively support it in the scanner. For other tools please make an effort to see if you can add the testing header!
Who We Are
TimelyCare is a telehealth platform providing virtual medical and counseling services to college students and faculty across the United States. Data confidentiality and integrity are paramount when it comes to handling personal health information, and we provide a highly available service that aims to be there for students at any time, especially in times of crisis. To that end, TimelyCare is committed to upholding the cybersecurity of our systems and continuing to improve over time... with your help! This Responsible Vulnerability Disclosure Program is intended to provide clear guidance on how to report security vulnerabilities to our team.
We look forward to working with the security community to find security vulnerabilities in order to keep our members safe!
Response Targets
TimelyCare will make a best effort to meet the following response targets for hackers participating in our program:
| Type of Response | Target in business days |
|---|
| First Response | 2 days |
| Time to Triage | 10 days |
| Time to Resolution | depends on severity and complexity |
We’ll try to keep you informed about our progress throughout the process.
Disclosure Policy
- Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
- Follow HackerOne's disclosure guidelines.
#Scope Leniency
- This program will accept submissions for assets that are not listed as explicitly in scope.
- Please do not actively pursue testing on assets we have marked out of scope, but if you incidentally discover something wrong please let us know about it.
- It is possible for all organizations to have public assets they are not aware of. If you find something (e.g. a public AWS bucket) that doesn't look quite right and which you think belongs to us, please let us know about it even if it's not listed in our scope.
Program Rules
- If you come across or gain access to personally identifiable information (PII) or protected health information (PHI), stop your testing and do not pursue further exploitation of the finding in question! Report it immediately, and always redact any such data in screenshots.
- Make good faith efforts to avoid privacy violations. DO NOT download, transfer, or otherwise exfiltrate member records, PII, or PHI, even to demonstrate finding impact. Trust us to triage appropriately, and simply mention in your report that you believe it is possible to leak sensitive information so we can verify.
- Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue may not be marked as triaged.
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
- When duplicates occur, we only triage the first report that was received (provided that it can be fully reproduced).
- Multiple vulnerabilities caused by one underlying issue will be treated as one valid report.
- Social engineering (e.g. phishing, vishing, smishing) is prohibited.
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.
Session Layer: HTTP Headers
Researchers should add headers to requests such as:
- “X-HackerOne-Research: [H1 username]”
Out of scope vulnerabilities
When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered irrelevant/out of scope:
- Exposed Firebase API keys (see documentation here, these are not secret)
- Exposed Pusher App Key Variable - App Keys are used for project identification and not authenication.
- Clickjacking on pages with no sensitive actions
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Attacks requiring MITM or physical access to a user's device.
- Previously known vulnerable libraries without a working Proof of Concept.
- Missing best practices in SSL/TLS configuration.
- Any activity that could lead to the disruption of our service (DoS).
- Rate limiting or bruteforce issues on non-authentication endpoints
- Missing best practices in Content Security Policy.
- Missing HttpOnly or Secure flags on cookies
- Configuration of or missing security headers.
- Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
- Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
- Tabnabbing
- Issues that require unlikely user interaction
- Improper logout functionality and improper session timeout.
- CORS misconfiguration without an exploitation scenario
- Broken link hijacking
- Lack of jailbreak detection in mobile apps.
- Lack of SSL Pinning
Thank you for helping keep TimelyCare and our members safe!