September 8, 2016

If you believe you have found a security vulnerability in Legal Robot, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem. However, the product is currently in beta, so we do expect a large volume of changes in our code and may already be aware of the issue. If you submit a report for a known issue, we will do our best to let you know quickly so you can move on.

Rules

Use good judgment (except as outlined below in “Destructive/Invasive Attacks”):

  • Do not destroy or degrade the performance of our products and services, or violate the privacy and integrity of user accounts and data.
  • To be clear, you must never attempt to view, modify, or damage data belonging to others in production (feel free to do this in our non-production environment).
  • Do not interact with other users without their prior consent.
  • Do not attempt a denial-of-service attack.
  • Do not perform any research or testing in violation of law.
  • You must be the first person to report the issue to us. If a duplicate reproduction is submitted while the vulnerability is still in the wild, we will only award a bounty if the duplicate submissions provide more information or show the issue to be more extensive.

As long as your research stays within the bounds of these criteria, we welcome the dialog and promise not to take legal action.

Attributes of a Good Report

  • Detailed steps on reproducing the bug. If valuable, please include any screenshots, links you clicked on, pages visited, etc.
  • Describe the versions of all relevant components of the attack (e.g. browser, OS, etc).
  • Describe a concrete attack scenario. How will the problem impact our services or customers? Put the problem into context.

Scope

We welcome you to report problems on legalrobot.com (production) and legalrobot-uat.com (non-production) or our Android and iOS app. Also in scope: any S3 bucket we own (they all have legalrobot in the name). Some S3 buckets simply hold logos, videos, and other assets which are intentionally publicly accessible (like legalrobot.s3.amazonaws.com).

Not in scope: the legalrobot.ideas.aha.io domain. Also, any mail server issues are out of scope on the legalrobot-uat.com domain.

We are particularly interested in problems that allow unauthorized access to other user’s documents and will award monetary bounties accordingly. However, YOU MUST ONLY ATTEMPT THIS IN OUR NON-PRODUCTION ENVIRONMENT (legalrobot-uat.com).

Destructive/Invasive Attacks

We provide a non-production environment (legalrobot-uat.com) that you may use for destructive and invasive attacks. All of the data in this environment is non-sensitive, so have at it… just DO NOT do anything illegal, or launch a denial-of-service or other attack that could disrupt or get us blacklisted with our service providers. If this server is offline send us a note at [email protected] with the expected duration of your testing. Also, because this is not a full production environment, DMARC, SPF, and similar email issues will not be eligible. To be clear, issues that exist on the legalrobot-uat.com domain but not legalrobot.com will not be accepted.

Automated Testing

We do our own automated testing for security issues and are likely aware of anything that is found through those methods. We ask you to refrain from adding your own automated testing load to our servers and submitting reports for issues from automatic scanners. We likely know about those issues anyway so they will not be eligible.

Annoying Tests

Submitting form data like “><img src=M onerror=prompt(1);>” just annoys us. It’s a waste of our time and yours because we obviously sanitize inputs. Related: don’t deface our blog comments with XSS attempts - we use Disqus for comments, so we wouldn’t have any control over those components anyway.

Ineligible Reports

  • Reports from automated tools or scans
  • Already public issues related to software, scripts, or protocols not under our control (e.g. meteor.js, node.js, cordova, etc)… unless we are using a version that is seriously out of date
  • Use of a known-vulnerable library without evidence of exploitability
  • Attacks requiring physical access to a user’s device or network
  • Attacks that require attacker app to have the permission to overlay on top of our app (e.g., tapjacking)
  • Any access to data where the targeted user needs to be operating a rooted mobile device
  • Vulnerabilities affecting users of outdated browsers, platforms, or crypto (i.e. TLS BEAST)
  • Social engineering of our staff or contractors, phishing, spear phishing, etc.
  • Any physical attempts against our property or our host’s data centers
  • Presence of autocomplete attribute on web forms
  • Missing public key pins
  • Missing best practices (we require evidence of a security vulnerability)
  • Missing cookie flags on non-sensitive cookies (we don’t use cookie-based auth)
  • Host header injections unless you can show how they can lead to stealing user data.
  • Reports of spam (i.e. any report involving ability to send emails without rate limits)
  • Lack of CSRF tokens (unless there is evidence of actual, sensitive user action not protected by a token)
  • Login/logout CSRF

Thanks & Compensation

We believe in recognizing the work of others. If your work helps us improve the security of our service, we’d be happy to acknowledge your contribution. In addition to showing our appreciation for our security researchers, we also offer a monetary bounty for certain security bugs, provided you follow the rules. More serious issues will be rewarded appropriately. Many researchers find similar or identical issues at the same time so unfortunately, duplicate issues will only receive our appreciation.

History

  The text of this page is released into the Public Domain under the Creative Commons Zero license.