What is Quantopian?

Quantopian inspires talented people everywhere to write investment algorithms. Select authors may license their algorithms to us and get paid based on performance.

At the heart of Quantopian is a Python algorithmic trading platform called Zipline. Our members' Python code running on our platform presents a unique security challenge.

Our highest security priority is protecting the private data and intellectual property of our members and the funds the partners who invest money through us.

What to report ... here's your blueprint

IMPORTANT: Any account created at https://www.quantopian.com/ for security testing should have the string "hackerone" somewhere in the local part of its email address, i.e., the part before the "@". On many email platforms you can achieve this by appending "+hackerone" to the end of your username. The reason for this is explained in the description of the www.quantopian.com scope, below.

Please try to include the following on your reports:

The Basics

1. Subject line - What type of issue are you reporting, e.g., XSS, CSRF, authentication bypass, etc.?
2. Is it a known issue in a third-party component, e.g., does it have an assigned CVE number?
3. What are the specific steps for reproducing the issue?

--> We need more! <--

4. What is the impact of the issue?
5. How might an attacker leverage the issue? Show a proof-of-concept exploit or detailed instructions for leveraging the vulnerability to actually compromise the security of our site.
6. Do you have suggestions on how we should fix the issue? We want to know.

Things NOT to do

DO NOT submit more than 15 requests per minute. If your testing causes downtime, you run the risk of being ineligible to submit to the Quantopian program.

While researching, please refrain from:

• Actions which might overwhelm our resources or cause a denial of service to others, for example, flooding our servers with requests or submitting meaningless support inquiries (generally speaking, we discourage the use of automated scanners by researchers, but if you must use automated tools, please ensure that they do not submit more than 15 requests per minute);
• Actions which cause emails to be sent to our members (note: if your testing involves posting new threads or comments in our forums, then please put the string "qsectest" somewhere in the body of each of your test postings so that we can detect that they are test posts and not email them to our members);
• Accessing the private intellectual property or data of Quantopian or its members (e.g., if you are testing account security bypasses, please use test accounts you've created); or
• Social engineering (including phishing) of Quantopian employees or users.

How to reach us

You can always email [email protected] with questions or concerns about our program.

Testing our algorithm execution environment

Please notify [email protected] in advance if you intend to probe the security of our algorithm code execution environment, so that we can respond appropriately if our monitoring detects and notifies us about your testing or your testing triggers our automated guards.

Exclusions

Please don't submit reports about:

• xmlrpc.php on our blog; we know it's enabled and we are not going to disable it;
• DMARC or DKIM, or SPF;
• CSRF on www.quantopian.com, unless your proof-of-concept is successful when you've removed the CSRF token from both the cookie and the hidden form field in the submission;
• attacks requiring physical access to a member's or employee's device;
• attacks requiring a member's or employee's device to be compromised by malware, a rootkit, etc;
• third-party platforms and services hosting our resources or employed by them;
• social engineering;
• security vulnerabilities in third-party components made public within the past 14 days;
• issues that you have not actually confirmed are present on our site;
• issues without a clearly defined security impact; or
• other resources outside the scope of this program and not in control of Quantopian.

Rate Limit Exclusions

We are not interested in any issues pertaining to our site's default rate limits unless there is a specific user-facing impact to that limit. We strive to keep our rate limits out of the minds of our users, so we have intentionally made them rather lenient.

The only rate limit related reports we will review must have an impact beyond Denial-of-Service attacks. Examples:

• A rate limit that is too low on a function that sends notifications to users
• Any sort of intellectual property theft from another user

Any testing of our rate limits should stay within our 15 requests-per-minute guideline. This is below our overall site rate limit, but should be sufficient for testing issues with extra impact (such as the examples above).

Any rate limit testing of site behaviors that send notifications to Quantopian employees must be approved by Quantopian program administrators first.

Bounty Rewards

Our bounties usually range from $100 to $5,000. We rate reported vulnerabilities in five categories; these ratings are combined formulaically to arrive at a bounty amount. In some circumstances, we may find it necessary adjust the bounty amount determined by our formula, but we try to stick with the formula's results whenever possible.

Show greater impact = increase your bounty! Here's how it's done ...

0 = No impact and 4 = Critical

The rating scales above are provided only for informational purposes. Reported vulnerabilities are rated by us, not by the researchers reporting them. When reporting a vulnerability to us, you should not attempt to rate it according to the scales above. If you believe that we have misunderstood the scope or severity of a vulnerability, we encourage you to explain why; however, its severity rating is solely at our discretion and not up for debate.

Real examples of previous vulnerabilitiesnote: if your testing involves posting new threads or comments in our forums, then please put the string "qsectest" somewhere in the body of each of your test postings so that we can detect that they are test posts and not email them to our members

Please check out some of our previous reports to better understand how to explain the impact of your find and earn higher bounties.

1. World-writable S3 bucket used for deployment of Python wheels to our application servers. A bad actor could have tampered with the wheels in this bucket to introduce malicious code onto our servers. We ranked this report 3 out of 4 on ease of discovery, 2/4 on exploitability, 4/4 on user impact, 4/4 on fund impact, and 3/4 on stealthiness, resulting in a bounty of $3,125.

2. Authorization not being enforced properly for collaboration. A bad actor could have exploited this vulnerability to gain access to the chat sessions and portions of the algorithm source code of other users' collaboration-enabled algorithms. We ranked this report 4/4 on ease of discovery, 2/4 on exploitability, 3/4 on user impact, 2/4 on fund impact, and 3/4 on stealthiness, resulting in a bounty of $2,425.

3. Stored XSS in algorithm name when a collaborator attempts to delete the algorithm. A bad actor would have had to insert XSS code into the algorithm title (which would have been visible to the collaborator) and then somehow get the collaborator to attempt to delete the algorithm. We ranked this report 3/4 on ease of discovery, 2/4 on exploitability, 3/4 on user impact, 1/4 on fund impact, and 2/4 on stealthiness, resulting in a bounty of $1,500.

4. Rate limiting on account confirmation emails not working. A bad actor could have exploited this to flood any email address with emails from Quantopian and in the process run up Quantopian's bill with our email service provider. We ranked this report 2/4 on discoverability, 3/4 on exploitability, 1/4 on user impact, 0/4 on fund impact, and 0/4 on stealthiness, resulting in a bounty of $325.

Timeline

We usually send an initial response to vulnerability reports within two business days. Feel free to ping us if you don't hear back within two days of submitting a report.

We triage most reports, i.e., reproduce them and determine their severity, before our initial response. If we are unable to do so, our initial response includes either an estimate of when we believe we will be able to triage it, or a request for additional information we need from the reporter.

We try to pay the bounty for a report within 30 days of our severity determination or within 7 days after we have closed the vulnerability, whichever is sooner. If we're late, please let us know.

Eligibility

While we are grateful to everyone who submits vulnerability reports to us, reports must satisfy the following criteria to be eligible for a bounty:

• You must follow all of the rules and conditions outlined in the HackerOne disclosure guidelines.
• The first report of a vulnerability is always considered for a bounty; subsequent, duplicate reports are considered on a case-by-case basis.
• You may not publicly disclose a reported vulnerability prior to us resolving it.

Fine print

Bounties are paid at our sole and complete discretion, and we reserve the right not to pay a bounty for an eligible report, for any reason or no reason.

We may modify the terms of this program or terminate the program at any time without prior notice.

→ Please only submit reports about actual vulnerabilities with a clearly defined security impact. ←

Here is what that means:

Please do not submit reports of the type, "I ran this security scanner on your site and it says your site is vulnerable to X, so it must be vulnerable to X!" Security scanners return false positives all the time.

Please do not submit reports of the type, "I'm reading this script off of the internet which says to check for X in responses from a web server, and your server returns X, so it must be vulnerable."

For a report to be useful to us, it must:

• indicate that the reporter fully understands the issue being reported and is not just cribbing it from a scanner or web page; and
• include a proof-of-concept exploit or detailed instructions for leveraging the vulnerability to actually compromise the security of our site.

Furthermore, please note that we specifically do not wish to receive reports about:

• the fact that you are able to enumerate usernames on our blog. This is not a security vulnerability;
• the fact that xmlrpc.php is accessible on our blog. We use it, and we're not going to remove it;
• CSRF tokens failing to be checked because you removed the CSRF token from your request and the request was processed anyway; this is because our site embeds the CSRF token in both the request header and the form contents, and you removed it from one of those locations but not the other;
• issues related to status.quantopian.com; it's hosted by StatusPage.io, not by us, so if there are any security issues there, report it to them, not us;
• attacks requiring physical access to a member's or employee's device;
• attacks requiring a member's or employee's device to be compromised by malware, a rootkit, etc;
• third-party platforms and services hosting our resources or employed by them;
• social engineering;
• SPF, DMARC or DKIM;
• security vulnerabilities in third-party components made public within the past 14 days; or
• to reiterate what is written above, any report without a clearly defined security impact and a proof-of-concept or detailed exploit instructions.

When submitting reports via email:

• Please use meaningful subject lines which, for example, mention what kind of vulnerability you are reporting and the affected application component. Please do not use generic subject lines like "security issue" or "bug bounty".
• Please do not send us large email messages (>~1MB). If you need to email us a large file, please upload it to a file-sharing service and send us a link.

While researching, please refrain from:

• actions which might overwhelm our resources or cause a denial of service to others, for example, flooding our servers with requests or submitting meaningless support inquiries (generally speaking, we discourage the use of automated scanners by researchers, but if you must use automated tools, please ensure that they do not submit more than 15 requests per minute);
• actions which cause emails to be sent to our members (note: if your testing involves posting new threads or comments in our forums, then please put the string "qsectest" somewhere in the body of each of your test postings so that we can detect that they are test posts and not email them to our members);
• accessing the private intellectual property or data of Quantopian or its members (e.g., if you are testing account security bypasses, please use test accounts you've created); or
• social engineering (including phishing) of Quantopian employees or users.