Vulnerability Disclosure Policy

This policy is intended for security researchers who have an interest in reporting security vulnerabilities or even potential security-related issues to the MURAL security team. This also sets our definition of good faith in the context of finding and reporting security vulnerabilities, as well as what you can expect from us in return for your effort, time, good will, and professional behavior.

‍

Scope

MURAL’s VDP initially covers the following assets for reporting:

• app.mural.co
• www.mural.co
• realtime.mural.co
• image.mural.co
• notifier.mural.co
  

As we move forward on this experience we will add more assets to our scope, so stay tuned!

‍

What can you expect from us‍

First Response Time: when you send us the initial submission, we will make our best effort to quickly reply to you. We don't use any type of bot, android or roomba... well, maybe yes, anyway, expect a kind welcome from one of our team members in two workdays or less (we always have something to do 😉).

‍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 (this must be aligned with our Disclosure Policy), 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.

‍Rewards: if your report gets eligible from our security team, we will be happy to give you a juicy bounty and, if you want to, enter our lovely Hall of Fame.

‍

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, create a couple of test accounts; 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, contractors, 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’re mutually agreed upon.
  

Bring Your Own Skills: we want to see your skills and how you apply your (lateral) thinking to bypass our protection measures. Try to avoid just copy-pasting the results from automated scans unless that you attach a PoC that demonstrates a specific vulnerability.

Finally, these are a couple of things that you may also try to avoid submitting because they unlikely be eligible for a bounty:

• Vulnerabilities on pages with no sensitive actions and/or information.
• Vulnerable 1st and 3rd party libraries without a working PoC.
• 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 😉).
• Lack of Secure or HttpOnly flag on non-sensitive cookies.
• Missing Best Practice, Configuration or Policy Suggestions including SSL/TLS configurations.
• Submitting a report without following the guidelines described in the Reporting Vulnerabilities section, e.g: without encryption.

‍

What we DON'T expect from you

Finally, here are some of the things that you may also try to avoid submitting because they will unlikely be eligible for a bounty:

• Vulnerabilities on pages with no sensitive actions and/or information.
• Vulnerable 1st and 3rd party libraries without a working PoC.
• 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.
• 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.

‍

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 and encoded in base64 like this: <st-mono><st-mono></st-mono></st-mono>

• If you need or want to attach a video, try to adhere to usual formats like .mp4 with H264 encoding, 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.
  

Communication Channel: the only communication channel that we offer to send the reports by this moment is through an email to security-at-mural-dot-co. Every email, as well as the report, evidence, or any attached file, must be encrypted with our PGP key.

‍

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 MURAL itself:

• Arbitrary code/command execution on a MURAL server in our production network. 
• Arbitrary SQL queries on the MURAL production database.
• Bypassing the MURAL 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 MURAL.co (XSS) which bypasses CSP.
• Bypassing authorization logic to grant a repository collaborator more access than intended.
• Discovering sensitive user or MURAL data in a publicly exposed resource.
• Gaining access to a non-critical resource that only MURAL 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 mural.co (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 MURAL users.