Vulnerability Discovery Procedure

Introduction

Security is our top priority and at 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 in return for your effort, skill, and time.

Ground Rules

To encourage vulnerability research and to avoid any confusion between legitimate research and malicious attack, we ask that you attempt, in good faith, to:

• 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

All security researchers are required to:

• 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 inform you on the vulnerability status.

If you follow these guidelines when reporting a vulnerability to us, we commit to:

• 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 three business days of the vulnerability submission);

Expectations

When working with WEKA you can expect us to:

• 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 improve 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?

If you believe you’ve found a security or privacy vulnerability at one of our products or platforms please click on the report a vulnerability button at the bottom of the page.

Key screenshots and an MP4 file proving the ability to attack must be provided.

Scope

https://*.weka.io

In-Scope Vulnerabilities

The vulnerabilities listed here are explicitly qualified for our vulnerability security and privacy program. Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

• 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 Attack (XXE)
• Remote Code Execution (RCE)
• Access Control Issues (Insecure Direct Object Reference issues, etc.)
• Known vulns in unpatched software (usually third party)
• Local File Disclosure (LFD)
• 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.

Out of Scope

Things we do not want to receive:

• Network denial of service (DoS or DDoS) tests.
• Information leakage that cannot be used to make a direct attack, like server IP, server version, path, error message, internal IP, etc.
• PII – do not collect any personally identifiable information – including credit card information, addresses and phone numbers from other customers.
• Reports from automated tools or scans.
• Attacks against the company infrastructure
• Social engineering and physical attacks (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing.
• 0-day vulnerabilities less than 90 days from patch release are ineligible for bounty.
• Violations of licence or other restrictions applicable to any vendor’s product.
• “Self” XSS
• Session fixation
• Content Spoofing
• Missing cookie flags
• SSL/TLS best practices
• Mixed content warnings
• Clickjacking/UI redressing
• Flash-based vulnerabilities
• Local denial of service of Mobile APP
• Reflected file download attacks (RFD)
• Findings derived primarily from social engineering (e.g. phishing, vishing)
• Credit card holder data
• Confidential information from third-parties
• SMS/Email flooding for some of our business
• CSRF/XSS with long or unpredictable parameter
• Login/logout/unauthenticated/low-impact CSRF
• Unverified Results of automated tools or scanners
• No SPF/DMARC in non-email domains/subdomains
• Attacks requiring MITM or physical access to a user’s device
• Issues related to networking protocols or industry standards
• Error information disclosure that cannot be used to make a direct attack
• Missing security-related HTTP headers which do not lead directly to a vulnerability
• Feedback, comment, message, etc. flooding

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.