Responsible Disclosure Policy

As a provider of products and services for many users across the Internet, Experience.com recognises how important it is to help protect the privacy and security of our Customer Data. We understand that secure delivery of our Services is instrumental in maintaining the trust customers place in us and we strive to create innovative products that both serve our customers’ needs and operate in our customers’ best interest. Keeping Customer Data safe and secure is a top priority for Experience.com and a core company value.

We genuinely value the assistance of security researchers and any others in the security community to assist in keeping our systems secure. The responsible disclosure of security vulnerabilities helps us ensure the security and privacy of all our users.

GUIDELINES:

• Reach out tosecurity@experience.com, if you have found any potential vulnerability in our products meeting the criteria mentioned in the policy below.
• Experience.com will define the severity of the issue based on the impact and the ease of exploitation.
• We may take 2 to 4 days to validate the reported issue.
• Actions will be initiated to fix the vulnerability in accordance with our commitment to security and privacy. We will notify you when the issue is fixed
• When conducting security testing, individuals should not violate our privacy policies, modify/delete unauthenticated user data, disrupt production servers, or to degrade user experience.
• Perform research only within the scope set out below;
• Documenting or publishing the vulnerability details in the public domain is against our responsible disclosure policy.
• Keep information about any vulnerability confidential until the issue is resolved
• DDoS or DoS attacks are strictly restricted

SCOPE:

IN SCOPE DOMAINS:

• experience.com
• exp.experience.com
• app.experience.com
• pro.experience.com
• developer.experience.com

There are chances more domains will be added to this list if needed

QUALIFYING BUGS/ VULNERABILITY :

• Remote code execution (RCE)
• SQL/XXE Injection and command injection
• Cross-Site Scripting (XSS)
• Server side request forgery (SSRF)
• Cross site request forgeries (CSRF)
• RCE (Remote code execution)
• Cross-site request forgery in a privileged context
• Authentication or authorization flaws
• Injection Vulnerabilities (SQL,XXE)
• Directory Traversal
• Information Disclosure (High impact)
• Significant Security Misconfiguration
• API and endpoint unintended behavior or information disclosure

OUT-OF-SCOPE/ NON-QUALIFYING VULNERABILITIES :

• Html injection and Self-XSS
• Host header and banner grabbing issues
• Automated tool scan reports.Example: Web, SSL/TLS scan, Nmap scan results, etc.
• Missing HTTP security headers and cookie flags on insensitive cookies
• Rate limiting, brute force attack
• Login/logout CSRF
• Session timeout
• Unrestricted file upload
• Open redirections
• Formula/CSV Injection
• Denial of Service (DoS)/Distributed Denial of Service (DDoS)
• Vulnerabilities that require physical access to the victim machine.
• User enumeration such as User email, User ID, etc.
• Vulnerabilities found in third-party services
• EXIF data not stripped on images
• Vulnerabilities on pages with no sensitive actions and/or information.
• Vulnerable 1st and 3rd party libraries without a working PoC.
• Use of a known-vulnerable library which leads to a low-impact vulnerability (i.e. jQuery outdated version leads to low impact XSS)
• Requiring MITM or physical access to a user’s device.
• User/email enumeration without a PoC that demonstrates a specific flaw (It’s a feature, not a bug ).
• Missing cookie flags on non-sensitive cookies
• Missing Best Practice, Configuration or Policy Suggestions including SSL TLS configurations.
• Invalid or missing SPF/DKIM/DMARC configurations.
• Content spoofing/text injection
• Self-XSS (must be exploitable in reflected, stored or DOM-based types).
• Methods to extend product trial periods.
• Lack of rate-limiting in HTTP endpoints.
• Host Header Injection (without providing an exploitable scenario)
• Software version disclosure.
• Vulnerabilities only affecting users with outdated/unpatched browsers and platforms.
• Password and account recovery policies, such as reset link expiration or password complexity.
• Will mark the Duplication of vulnerabilities based on the vulnerability and their endpoints if reported previously
• Logout and other instances of low-severity Cross-Site Request Forgery
• Submitting a report without following the guidelines described in the Reporting Vulnerabilities section, e.g: without encryption

WHAT CAN YOU EXPECT FROM US :

Fast Response Time :

When you send us the initial submission, we will make our best effort to quickly respond. We don’t use any type of bot well, maybe yes, anyway, expect a kind welcome from one of our team members in two workdays or less.

Triaging Time :

We are committed to working with security researchers to help identify and fix vulnerabilities on any of our scoped systems, and we will try to keep you updated about the progress of your report throughout the triage process. Keep in mind that this could take up to 10 workdays from the initial submission day.‍

Safe Harbor :

We can promise that we will NOT take any legal action on participating researchers who act in good faith by following the guidelines outlined in this policy. If you have any doubt about this or any point of this policy, submit your report to us before engaging in conduct (accidental or not) that may be inconsistent with or unaddressed by this policy, or don’t hesitate to use one of our communication channels listed in this policy to contact us.

Research Safety :

If you come up with some fancy new techniques/vulnerabilities that you want to keep secret, eg.: until you present them at a security conference, we can assure you we will keep it secure, confidential and encrypted, so we will not share it with any third party. For obvious reasons, we’ll just only do it with our team members that will be responsible for fixing them during the remediation process with the minimum amount of information as possible.

WHAT WE EXPECT FROM YOU :

When researching please try to adhere these guidelines:‍

Own your Data : 

if you find a vulnerability that gives you access to other user’s data, please exploit it on an account that you own, send us a mail if you need creating a couple of test accounts for your usage; check with us first if you think you really, really, really need that.‍

Pwn → ∞, Destroy → 0 : 

Do not incur in any activity that results in denial of service conditions, degradation of our services, spamming, brute forcing accounts, or any other black magic that affects our customer’s user experience, privacy, and data.‍

Hack the planet, but not humans :

Social engineering is out of scope; do not attempt to socially engineer our organization, or our users.

Good Reports : 

We expect English, well-written reports. Every vulnerability that you report must be followed by a PoC, attaching code listings, screenshots or any other evidence that you think could help on the triaging process; reports with a clear step-by-step, remediation commendations and impact score that help us understand and save us time reproducing and fixing the vulnerabilities, will be more likely to be accepted. For more information see the Reporting Vulnerabilities section below.‍

Coordinated Disclosure :

If you have any plans to publicly disclose any of the vulnerabilities found in any assets described by our Scope section, please add this will into your report. We encourage you to not do that until:

• We fix the vulnerabilities
• The vulnerability time-frame has reached, depending on its severity we mutually agreed.

SEVERITY GUIDELINES 

All submissions will be rated by us only using the following criteria. We will not accept a rated submission. If that occurs we may re-rate or dismiss that submission.

Critical :

These severity issues present a direct and immediate risk to a broad array of our users or to Experience.com itself:

• Arbitrary code/command execution on a Experience.com server in our production network.
• Arbitrary SQL queries on the Experience.com production database.
• Bypassing the Experience.com login process, either password or 2FA.
• Access to sensitive production user data or access to internal production systems

High :  

These severity issues allow an attacker to read or modify highly sensitive data that they are not authorized to access.

• Injecting attacker controlled content into Experience.com (XSS) which bypasses CSP.
• Bypassing authorization logic to grant a repository collaborator more access than intended.
• Discovering sensitive user or Experience.com data in a publicly exposed resource.
• Gaining access to a non-critical resource that only Experience.com employees should be able to reach.

Medium : 

These severity issues allow an attacker to read or modify limited amounts of data that they are not authorized to access.

• Disclosing the title of issues in private repositories which should be inaccessible.
• Injecting attacker controlled content into Experience.com (XSS) but not bypassing CSP or executing sensitive actions with another user’s session.
• Bypassing CSRF validation for low risk actions, such as starring a repository or unsubscribing from a mailing list

Low :

These severity issues allow an attacker to access extremely limited amounts of data.

• Signing up arbitrary users for access to an “early access feature” without their consent.
• Creating an issue comment that bypasses our image proxying filter by providing a malformed URL.
• Bypassing community-and-safety features such as locked conversations.
• Triggering verbose or debug error pages without proof of exploitability or obtaining sensitive information.
• Triggering application exceptions that could affect many Experience.com users.

REPORTING VULNERABILITIES :

We encourage you to write high-valuable reports that help us to shorten the triage and remediation process time. For this reasons we recommend you to follow these guidelines :-

Report Format : We will only accept reports with markdown format, otherwise, the submission will be rejected. Before submitting your report, try to make sure that these guidelines are met:

• When adding an image, please use .png format
• If you need or want to attach a video, try to adhere to usual formats like.mp4, and then make a reference to it on the report.

Report Template : There’s a couple of fields that we would like to see on every report:

• Title : A one line description of the vulnerability.
• Summary: A brief description of the vulnerability and why it matters.
• Impact : a description of how this issue will impact our business.
• Likelihood: A brief description of the probability that this threat event might occur.
• Steps to Reproduce: A step-by-step walkthrough of how to reproduce this vulnerability with a PoC.
• Recommendations: Any advice on how this issue could be fixed or remediated.
• References and notes : any reference links or side notes that you want to make about the vulnerability, this field is optional but will be welcome.