Vulnerability Discovery Procedure
Introduction
Security is our top priority and in the core of our values. We value the input of the security researchers community to help us maintain a high standard for the security and privacy of our products, systems and users.
This procedure sets out our definition of finding and reporting process of security and privacy vulnerabilities, as well as what you can expect from weka.io in return for your effort, skill, and time.
Ground Rules
- Play by the rules. This includes following this procedure and the guideline below;
- Report any vulnerability you’ve discovered as soon as you can
- Avoid violating the privacy of our users, interrupting our systems, destroying data
- Handle any discovered vulnerabilities with confidentiality
- Perform testing only on in-scope systems, and respect systems, activities and processes which are out-of-scope
- If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept (POC);
- Cease testing and submit a report immediately if you encounter any sensitive user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or any other personal information or any commercial sensitive information
- You should only use accounts you own or account with explicit permission from the account holder
- Do not engage in extortion.
Guidelines
- Act in good faith to avoid privacy violations, degradation of our services, disruption to production systems, and destruction or manipulation of data during security testing (including denial of service)
- Once you’ve established that a vulnerability exists, or encountered any of the sensitive data outlined above, you must stop your test and notify us immediately
- Perform vulnerability research only within the scope set out below
- Be clear and concise, a short proof-of-concept link is invaluable
- Keep information about any vulnerabilities you’ve discovered confidential between us until we have had 60 days to resolve the issue or informed you on the vulnerability status.
- Not pursue or support any legal action related to your research;
- Work with you to understand and resolve the issue quickly (including an initial confirmation of your report within 48 hours of the vulnerability submission);
- Recognize your contribution on our Leader board, if you are the first to report the vulnerability and we make a code or configuration change based on the issue.
Expectations
- Work with you to understand and validate your report, including a timely initial response for your submission;
- Work to remediate discovered vulnerabilities in a timely manner;
- Recognize your contribution and effort to improving our security and privacy. If you are the first to report a unique vulnerability, and your report triggers a code or configuration change.
How to report a security vulnerability?
- Description of the location and potential impact of the vulnerability; and
- A detailed description of the steps required to reproduce the vulnerability (POC, scripts, screenshots, and compressed screen captures are all helpful); and
- Your name or a link for recognition in our Hall of Fame.
Scope
In Scope
https://*.weka.io
In-Scope Vulnerabilities
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
- Authentication or Authorization Flaws
- Server-Side Request Forgery (SSRF)
- Server-Side Template Injection (SSTI)
- SQL injection (SQLI)
- XML External Entity (XXE)
- Remote Code Execution (RCE)
- Local or Remote File Inclusions
While this list represents our primary focus for security research, we are interested in reports for all of our software and dependencies especially if it impacts sensitive user data.
This can include any open source libraries, software, or third-party components.
Outside Scope
- Network denial of service (DoS or DDoS) tests.
- Physical testing (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing.
- Findings from applications or systems not listed in the ‘Scope’ section
- Findings derived primarily from social engineering (e.g. phishing, vishing)
- UI and UX bugs and spelling mistakes
Things we do not want to receive:
- Personally identifiable information (PII)
- Confidential information from third-parties
- Credit card holder data
Compliance
If you comply with this procedure during your security research and do not compromise the security of our systems, or the safety or privacy of our users, we will work with you to understand and resolve the issue quickly, and will not initiate or recommend legal action related to your research.