submit bug report:https://prezi.com/bug-bounty/

Prezi Responsible Disclosure
At Prezi, we take security of our users’ data very seriously and we believe in harnessing the power of the security researcher community to help keep our users safe. We encourage the responsible disclosure of security vulnerabilities.

This brief ("brief") covers your participation in the Prezi Responsible Disclosure Program (the "Program"). It sets out terms between you and Prezi ("Prezi," "us" or "we"). By submitting any vulnerabilities to Prezi or otherwise participating in the Program in any manner, you accept these terms, the Prezi Privacy Policy, and the BugCrowd Standard Disclosure Terms, Code of Conduct, Disclosure Policy, and Terms of Service.

To join the program, you should read this entire brief, and only proceed if you accept all the terms within.

Thank you for making Prezi better for everyone!

Discovering security vulnerabilities
We encourage and allow you to conduct security research and vulnerability testing on Prezi services and products to which you have authorized access on the “prezi.com” domain.
Please always keep the following rules in mind:

Never attempt to access someone else’s account or data; please always use your own account(s) for testing.
Never try to modify or destroy any data that does not belong to you.
Do not attempt or launch a denial of service attack. We and our users appreciate reliability.
Do not attempt or execute social engineering attacks (including but not limited to unsolicited or unauthorized emails, spam, or other forms of unsolicited messages).
Do not test third parties that integrate with Prezi services (see the “What we are not interested in” section below for more details).
Do not operate directly or indirectly with malicious or harmful software. We like to keep prezi.com clean for our users.
Don’t do anything that violates any applicable law.
Your participation in the Program is entirely voluntary. You acknowledge that Prezi has not offered or promised any reward or bounty payment for your participation in the Program. However, Prezi reserves the right to reward participation in the Program in its sole discretion on a case by case basis.
What we are not interested in
In general, please don’t report the following findings, unless you can showcase an actual vulnerability leading to significant impact:

CSRF vulnerabilities where exploitation is not really probable (other random / hard to get value is required for exploitation), CSRF in the authentication function
Missing “HTTP only” flag for cookies, which are not the following ones: auth-sessionid, prezi-auth, sessionid
Missing “Secure” flags for any cookie
Username / user id enumeration
Missing “X-Frame-Options”, “Strict-Transport-Security”, “Nosniff”, “X-Xss-Protection” headers
Phishing by navigating password tabs a.k.a "window.opener" (reason)
Absence of rate limiting
Denial of Service
User password brute force attack
"Leakage" of publicly available information (e.g.: server version info in response header)
Since our list of integrations might change, please always resolve our subdomains before any testing to verify that they are not pointing to some external / 3rd party service.

For example, the following domains and subdomains are pointing to different third-party solutions, which we are not authorized to include in this program:

beautifulbits.prezi.com/
blog.prezi.com/
support.prezi.com
*.cdn01.prezi.com
*.cdn02.prezi.com
streamingcdn.prezi.com
videocdn.prezi.com
videothumbcdn.prezi.com
email.prezi.com
*.preziusercontent.com
*.prezicdn.net
*.prezi.community
Reporting security vulnerabilities
If you believe you have discovered a security vulnerability, please share the details with us by completing the form below.

We will acknowledge receipt of your report within five business days and work with you to understand the issue so we can validate it. We will also do our best to give an estimate on the resolution of the vulnerability and notify you when it is fixed.

submit bug report: https://www.python.org/blogs/

The Python Community
Great software is supported by great people. Our user base is enthusiastic, dedicated to encouraging use of the language, and committed to being diverse and friendly.

submit bug report:https://qiwi.com

Policy

Qiwi Bug Bounty Program
We currently do not accept new reports.
Scope:
• qiwi kiosks
•  Visa Qiwi Wallet mobile apps for iOS, Android
• *.qiwi.ru
• *.qiwi.com
• *.qiwi.me
• *.rapida.ru
• *.contact-sys.com
• vitrina.contact-sys.com (only High and Critical severity server-side)
• *.flocktory.com ( only High and Critical severity server-side)
• *.qiwi.kz
• *.tochka-tech.com (except for issues with rate limits)
• *.tochka.com (except for issues with rate limits)
We do not accept/review reports with:
• Rate limits (including lack of captcha, etc) on domains tochka-tech.com, tochka.com and their subdomains
• Vulnerability scanners and other automated tools reports
• Reports based on product/protocol version without demonstration of real vulnerability presence, except for vulnerabilities with a CVSS v3 score 7+
• Reports of missed protection mechanism / inconsistent with best practices (e.g. no CSRF token, framing/clickjacking protection) without demonstration of real security impact for user or system
• framing, clickjacking;
• Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner);
• Self-XSS;
• Logout CSRF;
• Host header Injection;
• Reports regarding public availability of update1.qiwi.com and update-security1.qiwi.com
• SPF misconfiguration;
• Text-injection based on server error page;
How do I submit a bug report?
A bug report must give a detailed description of the discovered vulnerability:
• vulnerable hosts;
• the type of vulnerability;
• where exactly;
• security impact;
• steps impact;
• recommendations for fixing.
Reward payment and amounts.
We will pay you a reward if you are the first person to report a given vulnerability.  The amounts mentioned in the table below are approximate and may vary from vulnerability influence.
We are interested  the following  vulnerabilities criteria:
• possible use of the vulnerability
• on what service vulnerability found;
• value of financial, reputational and other risks from vulnerabilities.
Payments will be made through HackerOne.
Number of bug reports by one person of the Program is unlimited.
Also, public 0-day/1-day vulnerabilities may be considered as a duplicate within few days after vulnerability details publication, if vulnerability is known to our team from public sources and we are working to mitigate or patch it.
Qiwi Responsible Disclosure Policy
By submitting a bug report you agree to comply with Qiwi Responsible Disclosure Policy, which forbids public or private disclosure of the details of any vulnerability found on Qiwi within 90 days after vulnerability is fixed and only reciprocal agreement of the parties.
Qiwi employees, the employees in any of Qiwi companies group can't participate in the Qiwi Bug Bounty Program.

submit bug report: https://www.qualcomm.com/company/product-security

Report a Bug
Qualcomm takes security very seriously and we strive to address any security-related issues quickly and appropriately. If you have found a potential security issue in any Qualcomm product or software, please contact us via email: [email protected]. Or click the button below and use our form to contact us. For encrypted communication, you may use our public key.

submit bug report: https://hackerone.com/quantopian?type=team

Policy

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
Subject line - What type of issue are you reporting, e.g., XSS, CSRF, authentication bypass, etc.?
Is it a known issue in a third-party component, e.g., does it have an assigned CVE number?
What are the specific steps for reproducing the issue?
--> We need more! <--
What is the impact of the issue?
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.
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 secur[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
Difficulty of discovery
0 ”cookie-cutter” vulnerability, or one that is tested automatically by widely available tools.
1 easy to stumble across in normal usage of the site
2 easy to find if you are looking for it
3 requires work to discover and in-depth knowledge
4 requires work to discover and in-depth knowledge to understand
Ease of exploitation
0 impossible to exploit in any meaningful way
1 impossible to exploit unless combined with another vulnerability
2 extremely hard to exploit
3 straightforward but not easy to exploit
4 extremely easy to exploit
Impact on members who write, test, and trade algorithms through quantopian
0 no user impact
1 very little likely impact, almost not a security issue
2 compromise user private data but not their intellectual property
3 compromise user intellectual property
4 complete user account takeover
Impact on Quantopian’s money-management business
0 no impact.
1 very little likely impact, almost not a security issue
2 localized compromise of data
3 broad compromise of data
4 compromise of money
Stealthiness
0 exploitation would definitely be detected and thwarted quickly without damage or disruption
1 would be detected and thwarted eventually without site disruption
2 could go undetected or site disruption would be necessary to stop it
3 could go undetected and site disruption would be necessary to stop it
4 would likely go undetected for a long time
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.
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.
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.
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.
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.

submit bug bounty:https://www.rbs.co.uk/fraud-and-security.html#vulnerability

Reporting a Security Vulnerability
Our fundamental purpose is to keep our customers safe and secure and that’s why we at Royal Bank of Scotland take the security of our systems seriously.

If you have identified a potential vulnerability, please reach out to us via our Responsible Disclosure Programme – managed by Bugcrowd. Any submissions must be made through Bugcrowd and submitted on their platform.

NatWest Group will not accept submissions that have been found through the use of malignant or illegitimate means - If our Security Operations Centre identify your actions as malicious this will be treated as an attack and not a Responsible Disclosure submission.

Before submitting your finding please read over the terms and scope, and submit here.

submit bug report: https://www.rackspace.com/information/legal/rsdp

We've designed our infrastructure and services for security, to protect our customers and their data. But if you discover a security vulnerability with any of our products, control panels, or other infrastructure, we want to know.

Reporting process


Security issues within our product offerings take a very high priority. We want to work with you to understand the scope of the vulnerability and ensure that we correct the problem fully.

1. Report a vulnerability by notifying us at [email protected]. (If needed, you can encrypt your email using our public PGP key.) Please provide detailed information about the following:

The product, control panel, or infrastructure involved.
The steps required to reproduce the issue as well as any scripts or screenshots, if possible.
The impact of the vulnerability and how it can be exploited.
2. Once we receive your report, we will contact you to confirm we have received it within 5 business days.

3. Please do not post or share any information about a potential security vulnerability in any public setting until we have researched, responded to, and addressed the reported vulnerability and informed customers, if needed. Our products are complex, and reported security vulnerabilities will take time to investigate, address, and fix.

4) Rackspace does not have a monetary bug bounty program. For responsibly disclosed, new vulnerabilities, we have a hall of fame that can be found on this page.

Remember to use discretion when reporting issues and respect our customers’ and users’ data and privacy. Note that Rackspace may not be responsible for customer vulnerabilities. If you are unsure, let us know.

Security disclosure and notifications

For the protection of our customers, Rackspace Technology does not disclose, discuss, or confirm security issues until a full investigation has occurred and any necessary patches, fixes, or releases are available. Rackspace Technology usually distributes security disclosures and notifications through blog posts and customer support portals.

Keeping our community safe

We would like to acknowledge the following people who have responsibly disclosed security vulnerabilities in the past. Thank you for your help in keeping our community safe.

Tom Maher
Daksh Patel*
Koutrouss Naddara
Kamil Sevi
Osanda Malith Jayathissa*
Rodolfo Godalle, Jr.
Sabari Selvan
Tikarye Ashish B.
Gurjant Singh Sadhra
Ishan Anand
Jayvardhan Singh
Ciaran McNally
Ketan Sirigiri
Sangeetha Rajesh S
Scott Glossop
Yasir Zargar
Joel Parker Henderson
Zeel Chavda
Noman Shaikh
Rishabh Sharma*
Shawar Khan
Zee Shan
Prial Islam
Zika Ds
Piyush Soni
Macall Salugsugan
Vineet Kumar
Andrew Stucki
Ben Leonard-Lagarde
Maksym Bendeberia (Websafety Ninja)
R Atikislam
Robbie Wiggins
Salonee Jaiswal
Pranav Bhandari
Ken Nevers @k3nundrum (Red Sea Information Security)
Aman Deep Singh Chawla
Quang Vu Dinh @vudq16 (NCSC VietNam)
Varun Gupta
John Moss (7 Elements)
Subhasish Mukherjee
Apoorva Jois
Pratik Dabhi LinkedIn / Twitter
K Mohammed Danish Faraz LinkedIn / Twitter
Ibrahim Saud M LinkedIn / Twitter
Wesley Kirkland LinkedIn
Pritam Mukherjee
Sadik Shaikh
Yunus Yıldırım
Shiraz Ali Khan
Ahmed Salah Abdalhfaz
Guillermo Gregorio
Ivan Pellino
Gourab Sadhukhan
Divya Singh
Cameron Walsh
Akash Rajendra Patil
Isa Ghojaria
Shubham Garg
Prince Prafull
Foysal Ahmed Fahim*
Harinder Singh (S1N6H)
Noah Wilcox
Abdullah Mudzakir
Mohammad Sleaman Ahmad (HamaGold)
Marcin Bukowski (insect.pl)
Joao Paulo Figueiredo Guedes
Ramansh Sharma
* Indicates two or more vulnerabilities have been reported

Note: While we sincerely appreciate reports for vulnerabilities of all severity levels, this listing is reserved for people who have reported previously unknown vulnerabilities, which Rackspace Technology has determined to be of a high or critical severity, or in cases where there has been continued research or other contributions made by the person.

Having trouble with an account?

If you’re a Rackspace Technology customer and you’re having difficulty accessing your account, or if you believe your account has been accessed without your authorization, please contact your support team.