August 26, 2016

The product is currently in beta and there is some functionality that is incomplete.

Active development is underway so things are changing, a lot. Both the Hacker1 program and the app are currently in invite-only mode. For now, our primary concern is keeping information private rather than policing user-submitted content, etc. Therefore, exploits that let allow privilege escalation or access to other user’s content are higher priority.

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 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 readable (like legalrobot.s3.amazonaws.com).

Not in scope: the ideas.legalrobot.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 have made available a non-production environment (legalrobot-uat.com) that you may use for potentially destructive attacks and other 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 like AWS. When we are not actively doing testing, we usually shut off this server, so before initiating testing on this environment, we ask that you send us a quick email 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.

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 because we have to go clean up the database, and it’s a waste of your time because we obviously sanitize form input.

Ineligible Reports

  • Reports from automated tools or scans
  • Issues related to software 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
  • 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 or platforms
  • Social engineering of our staff or contractors
  • Any physical attempts against our property or our host’s data centers
  • Presence of autocomplete attribute on web forms
  • Missing security headers which do not lead directly to a vulnerability
  • Missing best practices (we require evidence of a security vulnerability)
  • Missing cookie flags on non-sensitive cookies
  • Missing http security headers (unless you deliver a proof of concept that leverages their absence)
  • Host header injections unless you can show how they can lead to stealing user data.
  • Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept, and not just a report from a scanner)
  • Any report that discusses how you can learn whether a given email address has an account.
  • An oracle that discloses whether a given username, email address, or phone number is associated with an actual account. (However, please do submit anything that allows you to recover usernames en masse.)
  • Reports of spam (i.e., any report involving ability to send emails without rate limits)
  • Self-XSS (we require evidence on how the XSS can be used to attack another user)
  • XSS on any site other than legalrobot.com.
  • Password, email and account policies, such as email id verification, reset link expiration, password complexity
  • 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.