[{"id":3767345,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n\n---\n**CVE's and 0-Days**\n\n---\n\n**CVE Age Requirement**\nWe will only accept CVEs that meet all of the criteria below:\n- Public for at least 60 days\n- Demonstrated impact on our environment (not theoretical)\n- Reproducible with clear steps or proof-of-impact\n\nCVE reports that do not meet the 60-day requirement are out of scope.\n\n**Exception – Critical Cases**\nWe may accept exceptions only if the CVE is clearly critical, such as:\n- Unauthenticated remote code execution\n- Critical privilege escalation\n- Direct access to sensitive data or systems\n- Any exploitation with immediate and severe risk\n\nExceptions are evaluated case-by-case and are not guaranteed.\n\n\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.\n\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| Broken URL links on *.uber.com | $100 or $0 (Case by case) |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-12-12T19:39:25.774Z"},{"id":3748154,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.\n\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| Broken URL links on *.uber.com | $100 or $0 (Case by case) |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-01-16T03:42:41.513Z"},{"id":3747575,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.\n\nFraud unrelated to product security issues (i.e., not related to a system or service) is not handled by the Bug Bounty program and should be reported to fraud-reports@uber.com with the following information:\n\n**Subject:** Fraud Report\n- Fraud location\n- Detailed explanation\n- Confirmation if the issue can - be reproduced\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| Broken URL links on *.uber.com | $100 or $0 (Case by case) |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-01-07T16:54:36.209Z"},{"id":3737756,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| Broken URL links on *.uber.com | $100 or $0 (Case by case) |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-09-03T19:56:17.127Z"},{"id":3733495,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.   Fraud unrelated to product security issues is not handled by the bug bounty program and should be reported to fraud@uber.com. \n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| Broken URL links on *.uber.com | $100 or $0 (Case by case) |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-23T17:29:28.906Z"},{"id":3731749,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.   Fraud unrelated to product security issues is not handled by the bug bounty program and should be reported to fraud@uber.com. \n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| Broken URL links on *.uber.com | $100|\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-08T17:51:41.101Z"},{"id":3723900,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities not involving product or coding flaws, but solely relying upon possession of stolen or compromised credentials or authentication obtained by ATO or credential stuffing, and by enumeration with pre-defined and known list of UUIDs\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Account \u0026 Financial Fraud**\n\n---\nㅤ\nCertain types of account fraud are in-scope provided that part of the attack chain relies on exploiting the workflow logic caused by technical product and services vulnerabilities, coupled with additional operational security loopholes for a hybrid end-to-end exploit. Vulnerabilities associated with fraud will be allotted a bonus payment upon validation related to financial impact.  Examples of fraud exploits that are potentially in-scope would include, but are not limited to the items listed below.\n\nPlease ensure to read the Out of Scope section prior to submitting a vulnerability associated with a fraud issue. Submissions associated with credential stuffing, brute forcing, or compromised passwords from data breaches are out of scope.\n\nFinancial Fraud: \n- Financial exploits in Uber services that require multi-account collusion and abuse\n\n\nIdentity Fraud:\n- Identity exploits involving stolen, hi-jacked and/or synthetic identities \n- Identity exploits that can potentially culminate into safety issues\n\n\nEach submission in this area will be reviewed on a case by case basis, and must be determined to be related to a technical product vulnerability to be considered in-scope.   Fraud unrelated to product security issues is not handled by the bug bounty program and should be reported to fraud@uber.com. \n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nReports that require an attacker to be authenticated, including accounts they can sign up for, will have the Privileges Required metric set to Low (PR:L) when calculating the CVSS severity score.\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-04-19T16:25:04.052Z"},{"id":3688823,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Open redirect resulting in a low security impact. In the event you are able to chain with other vulnerabilities (e.g., steal tokens, SSRF, etc.), please let us know\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Gift card enumeration\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-05T17:05:22.682Z"},{"id":3685978,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Gift card enumeration\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-04-10T13:16:28.089Z"},{"id":3685249,"new_policy":"\n\n---\n**Uber Bug Bounty Program Terms**  \n\n---\nㅤ\nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users  and company assets. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Issues that do not have an information security related impact will be closed. Below we describe the various security impact buckets that are in-scope, examples of admissible vulnerability types, and domains that could potentially have meaningful security impact.  \nBy submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n\n**Ground Rules**\n\n**Do**:\n- Do abide by these Program Terms\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your submission\n- Do be respectful when interacting with our team, and our team will do the same\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address\n- Do exercise caution when testing to avoid negative impact to data or services \n- Do respect privacy \u0026 make a good faith effort not to change or destroy Uber or personal data\n- Do stop whenever you are unsure if your test case may cause, or have caused, destructive data or systems damage with testing a vulnerability; report your initial finding(s) and request authorization to continue testing\n\n**Do NOT**:\n- Do not leave any system in a more vulnerable state than you found it\n- Do not use or interact with accounts you do not own\n- Do not brute force credentials or guess credentials to gain access to systems or accounts\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately\n- Do not perform denial of service (DoS) attacks or related tests that would cause availability interruptions or degradation of our services\n- Do not publicly disclose a vulnerability submission without our explicit review and consent\n- Do not engage in any form of social engineering of Uber employees, customers, or partners\n- Do not engage or target any specific Uber employees, customers, or partners during your testing\n- Do not access, extract, or download personal or business information beyond that which is minimally necessary for your Proof-of-Concept purposes\n- Do not do anything that would cause destruction of Uber data or systems\n\n---\n**Good Faith Disclosures and Safe Harbor**\n\n---\nㅤ\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n1. Follow the rules outlined in this policy: This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms, these Program Terms will control.\n2. Respect our users’ privacy: You should only interact with Uber accounts you own or with explicit permission from the account holder. The intent of the program is designed to hunt for vulnerabilities in our products and services.  If you encounter user information during the course of your research:\n- Stop at that point in your testing where you have an adequate proof of concept for submission purposes. Actions taken beyond this are not authorized\n- Report the Submission with a complete proof of concept immediately to our security team so we can investigate\n- Keep user information confidential; Do not save, copy, store, transfer, disclose, or otherwise retain the information\n- Work with us if we have any further requests\n3. Extortion: You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests. If you find a vulnerability, report it to us with no conditions attached.\n4. Test with care: You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our security team.\n\n---\n**Eligibility to Participate**\n\n---\nㅤ\nTo be eligible to participate in our Bug Bounty Program, you must:\n- Be at least 18 years of age if you test using an Uber account\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program\n- Not be using duplicate HackerOne accounts\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n**Out-of-Scope**\n\n---\nㅤ\nCertain vulnerabilities are considered out-of-scope for the Bug Bounty Program. Those out-of-scope vulnerabilities include, but are not limited to:\n\n- Vulnerabilities dependent on Phishing in a DNS domain that is not in one of our primary service domains\n- Most vulnerabilities that rely on a runtime context within a sandbox, lab, staging, testing or non-production environment\n- Vulnerabilities involving stolen or compromised credentials\n- Credential stuffing or physical access to a device\n- Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls\n- Man-in-the-Middle attacks except in mobile applications\n- Account enumeration with a pre-defined and known list of UUIDs\n- Invite/Promo code enumeration\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Information disclosures related to existence of accounts: Account oracles, the ability to submit a phone number, email, UUID and receive back a message indicating an account exists\n- Reports against Uber services that state that a particular software component is of a specific version, and is vulnerable without an accompanying proof-of-concept\n- Vulnerabilities only affecting users using outdated, unpatched, or unsupported browsers, mobile application, mobile operating system, and end-point client software, including the versions of our applications currently in the app stores \n- Stack traces, path disclosure, and directory listings\n- CSV injection vulnerabilities\n- Best practices concerns without a demonstrable information assurance issue and proof-of-concept\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc.)\n- Negligible security severity\n- Speculative reports about theoretical damage -- please always provide a proof-of-concept\n- Vulnerabilities that cannot be used to exploit other users or Uber (e.g., self-xss or having a user paste JavaScript into the browser console)\n- Vulnerabilities as reported by automated scanning and/or enumeration tools without additional analysis, validation, or reasoning as to how such Submissions have a demonstrable information assurance impact and vulnerability\n- Distributed or denial of service attacks (DDoS/DoS) and/or reports on rate limiting issues\n- Content injection or content spoofing issues\n- Cross-site Request Forgery (CSRF) with minimal security implications or lack of information assurance issues (e.g., Logout CSRF, etc.)\n- Missing cookie flags on non-authentication cookies\n- Submissions that require physical access to a victim’s computer/device for successful exploitation\n- SSL/TLS protocol scan reports reporting purported vulnerable protocol versions or handshakes \n- Banner grabbing issues (figuring out what web server we use, etc.).\n- Open ports or services without an accompanying proof-of-concept demonstrating a vulnerability or bonafide information assurance issues\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Exposed login panels without an accompanying proof-of-concept demonstrating a vulnerability or path of exploitation \n- Dangling IPs\n- Gift card enumeration\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- Reports on third-party products, services, or applications not owned by Uber\n- Out-of-scope domains – Please refer to the scoping section\n\n---\n**Calculating Security Impact**\n\n---\nㅤ\nUnderstanding the security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n**Multiplying Factors**\n\n- Sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact\n- Scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale\n- Severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, changing a user’s last name, versus adding new payment information, have drastically different security impacts\n- Forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification\n\n**Mitigating Factors**\n\n- Requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before the exploit is successful\n- Authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim\n- Requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID\n- Existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs\n- Physical access -- exploit scenarios requiring physical access to a device\n- Noticeable to the victim -- exploits that are noticeable to the victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable\n- Account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban\n- Social engineering -- when an exploit requires social engineering a person to be successful.\n- Requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful\n- Requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely\n\n---\n**Confidentiality**\n\n---\nㅤ\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n**Report Quality**\n\n---\nㅤ\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots when applicable)\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security severity\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask\n- Video proof-of-concepts (PoCs) will only be considered with a completed report. Stand alone video proof-of-concepts will automatically be closed\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope\n- All reports must demonstrate security impact to be considered for bounty reward\n\n\nPlease note: Known vulnerabilities or submissions by researchers leading back to the same root cause will be classified as a duplicate finding.\n\n---\n**Report States**\n\n---\nㅤ\nWe strive to be consistent with how we close reports and below are the details for each state:\n\n- **Spam**: a report with no useful information\n- **Needs more info**: not enough actionable information in report to triage\n- **Not applicable**: no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n- **Duplicate**: a vulnerability that has previously been found either internally or via Hackerone\n- **Informative**: a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)\n- **Triaged**: either a valid report or a report that needs more investigation from an internal team, typically the former\n- **Resolved**: a verified vulnerability that has been fixed\n\n---\n**Bounty Amounts**\n\n---\nㅤ\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n\n- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount\n- Follow up security bypasses on reported vulnerabilities are subject to bonus payments\n\nThe bounty ranges for the different security impact buckets:\n\n- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000\n- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000\n- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000\n- Phishing -- the payout ranges for this bucket range from $0 to $5,000\n- Safety -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\nBounty payouts are generally determined based on the criticality of the finding. The following chart illustrates sample ranges of vulnerabilities and the severity they have historically been associated with.\n\n\n| Vulnerability | Common Severity Range |\n| :------: | :---------: |\n| IDOR | Low - Critical |\n| Information disclosure |  Low - Critical |\n| Server-Side Request Forgery |  Medium - Critical |\n| XSS | Medium - High |\n\n---\n**Benefits and rewards**\n\n---\nㅤ\n**Pay at Triage**\n\nWe strive to reward valid reports within 14 days from the date the report reaches the triage stage, often sooner.\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**CVSS Scoring Exceptions**\n\nThere are several situations in which Uber will determine a reward without calculating a CVSS 3.1 score. An example of set price per exploit has been listed below:\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**Additional Reward Policy**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g., /foobar.json):\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs\n\nAll of the endpoints support offset and limit as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\nThe public endpoints for asset information are for recon purposes. Information returned by those endpoints (or not) does not mean a bounty is guaranteed.\n\n---\n**Rights and Licenses**\n\n---\nㅤ\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission. \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\n---\n**FAQ**\n\n---\nㅤ\nCan I get Uber swag?\nUber does not currently offer swag.\n\nCan Uber provide me with a pre-configured test account?\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\nWhat is required when submitting a report?\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\nHow do I make my report great?\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\nI submitted a report. Now what? I have questions.\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\nWhat causes a report to be closed as Informative, Duplicate, N/A, or Spam?\nhttps://docs.hackerone.com/hackers/report-states.html\n\nWhat is an example of an accepted vulnerability?\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n\nWhat if I find Uber accounts or passwords on the Internet?\nPasswords / accounts found on The Internal would be considered an informational finding.\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-03-22T19:17:35.777Z"},{"id":3676235,"new_policy":"\nUber Bug Bounty Program\n---\n\nThe scope for Uber’s Bug Bounty program includes most of our assets. If it is not explicitly out of scope and there is a security impact, we want to know about it. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.\n\nYour participation in our Bug Bounty Program is voluntary. Before finding and reporting any vulnerabilities you are required to read and agree to the Bug Bounty Program Terms (the \"Program Terms\"). In these terms, references to \"you\" or \"researcher\" refer to a researcher that submits a high quality report in accordance with the Uber Bug Bounty Program Terms and \"we\" or \"us\" refers to Uber.\n\n---\n\n**Table of Contents**\n\n**I. Program Terms**\n1. Safe Harbor\n2. Program Eligibility\n3. Program Rules\n4. Disclosure Policy and Confidentiality\n5. Legal\n\n**II. Submitting Reports**\n1. Report Quality\n2. Out of Scope\n\n**III. Bounty Awards**\n1. Pay At Triage\n2. CVSS Scoring Exceptions\n3. Additional Reward Policies\n\n**IV. Additional Info**\n1. SSRF Sheriff\n2. Asset Recon\n3. FAQ\n\n---\n\n**I. Program Terms**\n\n**1. Safe Harbor**\n\nAny activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Uber reserves all legal rights in the event of noncompliance with this policy.\n\n**2. Program Eligibility**\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n- Be at least 18 years of age if you test using an Uber account.\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n- Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n**3. Program Rules**\n\n**Do:**\n- Do abide by these Uber Bug Bounty Program Terms.\n- Do respect privacy \u0026 make a good faith effort not to access, process or destroy personal data.\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your report.\n- Do be respectful when interacting with our team, and our team will do the same.\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your `@wearehackerone.com` email address.\n- Do exercise caution when testing to avoid negative impact to customers and the services they depend on.\n- Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.\n\n**Do NOT:**\n- Do not leave any system in a more vulnerable state than you found it.\n- Do not brute force credentials or guess credentials to gain access to systems.\n- Do not participate in denial of service attacks.\n- Do not upload shells or create a backdoor of any kind.\n- Do not publicly disclose a Vulnerability without our explicit review and consent.\n- Do not engage in any form of social engineering of Uber employees, customers, or partners.\n- Do not engage or target any Uber employee, customer, or partner during your testing.\n- Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.\n- Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.\n- Do not interact with accounts you do not own.\n\n**4. Disclosure Policy and Confidentiality**\n\nAny data you receive, obtain access to or collect about Uber, Uber affiliates or any Uber users, customers, employees or agents in connection with the Bug Bounty Program is considered Uber’s confidential information (\"Confidential Information\").\n\nConfidential Information must be kept confidential and only used: (i) to make the disclosure to Uber under the Uber Bug Bounty Program; or (ii) to provide any additional information that may be required by Uber in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Uber's request, you will permanently erase all Confidential Information for any systems and devices.\n\nYou may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Bug Bounty submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.\n\nAny unauthorized public disclosure will result in a program ban.\n\nPlease review HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) for general best practices. For any reports submitted to Uber, this policy supersedes any conflicting HackerOne policies.\n\n**5. Legal**\n\nUber reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\nPlease check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can [subscribe](https://docs.hackerone.com/hackers/manage-notifications.html#program-notifications) to receive email notifications when this policy is updated.\n\n**II. Submitting Reports**\n\n**1. Report Quality**\n\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n- Video only proof-of-concepts (PoCs) will not be considered.\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n- All reports must demonstrate security impact to be considered for bounty reward.\n\n**2. Out-of-Scope**\n\nIn addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:\n\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n- Negligible security impact\n- Unchained open redirects\n- Reports that state that software is out of date/vulnerable without a proof-of-concept\n- Highly speculative reports about theoretical damage\n- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n- SSL/TLS scan reports (this means output from sites such as SSL Labs)\n- Open ports without an accompanying proof-of-concept demonstrating vulnerability\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- CSV injection\n- Best practices concerns\n- Protocol mismatch\n- Rate limiting\n- Exposed login panels\n- Dangling IPs\n- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n- Content injection issues\n- Missing cookie flags on non-authentication cookies\n- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n- Issues that require physical access to a victim’s computer/device\n- Stack traces\n- Path disclosure\n- Directory listings\n- Banner grabbing issues (figuring out what web server we use, etc.)\n- If a site is abiding by the privacy policy, there is no vulnerability.\n- Enumeration/account oracles\n- UUID enumeration of any kind\n- Invite/Promo code enumeration\n- Gift card enumeration\n- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n- Distributed denial of service attacks (DDOS)\n\n**III. Bounty Awards**\n\n**1. Pay At Triage**\n\nWe strive to reward valid reports within 14 days of acceptance, often sooner.\n\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**2. CVSS Scoring Exceptions**\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**3. Additional Reward Policies**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**IV. Additional Info**\n\n**1. SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n* 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. /foobar.json):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**2. Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs \n\nAll of the endpoints support `offset` and `limit` as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\n**3. FAQ**\n\n**Can I get Uber swag?**\n\nUber does not currently offer swag.\n\n**Can Uber provide me with a pre-configured test account?**\n\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\n**What is required when submitting a report?**\n\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\n**How do I make my report great?**\n\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\n**I submitted a report. Now what? I have questions.**\n\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\n**What causes a report to be closed as Informative, Duplicate, N/A, or Spam?**\n\nhttps://docs.hackerone.com/hackers/report-states.html\n\n**What is an example of an accepted vulnerability?**\n\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-17T20:10:11.983Z"},{"id":3676122,"new_policy":"\nUber Bug Bounty Program\n---\n\nThe scope for Uber’s Bug Bounty program includes most of our assets. If it is not explicitly out of scope and there is a security impact, we want to know about it. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.\n\nYour participation in our Bug Bounty Program is voluntary. Before finding and reporting any vulnerabilities you are required to read and agree to the Bug Bounty Program Terms (the \"Program Terms\"). In these terms, references to \"you\" or \"researcher\" refer to a researcher that submits a high quality report in accordance with the Uber Bug Bounty Program Terms and \"we\" or \"us\" refers to Uber.\n\n---\n\n**Table of Contents**\n\n**I. Program Terms**\n1. Safe Harbor\n2. Program Eligibility\n3. Program Rules\n4. Disclosure Policy and Confidentiality\n5. Legal\n\n**II. Submitting Reports**\n1. Report Quality\n2. Out of Scope\n\n**III. Bounty Awards**\n1. Pay At Triage\n2. CVSS Scoring Exceptions\n3. Additional Reward Policies\n\n**IV. Additional Info**\n1. SSRF Sheriff\n2. Asset Recon\n3. FAQ\n\n---\n\n**I. Program Terms**\n\n**1. Safe Harbor**\n\nAny activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Uber reserves all legal rights in the event of noncompliance with this policy.\n\n**2. Program Eligibility**\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n- Be at least 18 years of age if you test using an Uber account.\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n- Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n**3. Program Rules**\n\n**Do:**\n- Do abide by these Uber Bug Bounty Program Terms.\n- Do respect privacy \u0026 make a good faith effort not to access, process or destroy personal data.\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your report.\n- Do be respectful when interacting with our team, and our team will do the same.\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your `@wearehackerone.com` email address.\n- Do exercise caution when testing to avoid negative impact to customers and the services they depend on.\n- Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.\n\n**Do NOT:**\n- Do not leave any system in a more vulnerable state than you found it.\n- Do not brute force credentials or guess credentials to gain access to systems.\n- Do not participate in denial of service attacks.\n- Do not upload shells or create a backdoor of any kind.\n- Do not publicly disclose a Vulnerability without our explicit review and consent.\n- Do not engage in any form of social engineering of Uber employees, customers, or partners.\n- Do not engage or target any Uber employee, customer, or partner during your testing.\n- Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.\n- Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.\n- Do not interact with accounts you do not own.\n\n**4. Disclosure Policy and Confidentiality**\n\nAny data you receive, obtain access to or collect about Uber, Uber affiliates or any Uber users, customers, employees or agents in connection with the Bug Bounty Program is considered Uber’s confidential information (\"Confidential Information\").\n\nConfidential Information must be kept confidential and only used: (i) to make the disclosure to Uber under the Uber Bug Bounty Program; or (ii) to provide any additional information that may be required by Uber in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Uber's request, you will permanently erase all Confidential Information for any systems and devices.\n\nYou may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Bug Bounty submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.\n\nAny unauthorized public disclosure will result in a program ban.\n\nPlease review HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) for general best practices. For any reports submitted to Uber, this policy supersedes any conflicting HackerOne policies.\n\n**5. Legal**\n\nUber reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\nPlease check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can [subscribe](https://docs.hackerone.com/hackers/manage-notifications.html#program-notifications) to receive email notifications when this policy is updated.\n\n**II. Submitting Reports**\n\n**1. Report Quality**\n\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n- Video only proof-of-concepts (PoCs) will not be considered.\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n- All reports must demonstrate security impact to be considered for bounty reward.\n\n**2. Out-of-Scope**\n\nIn addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:\n\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n- Negligible security impact\n- Unchained open redirects\n- Reports that state that software is out of date/vulnerable without a proof-of-concept\n- Highly speculative reports about theoretical damage\n- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n- SSL/TLS scan reports (this means output from sites such as SSL Labs)\n- Open ports without an accompanying proof-of-concept demonstrating vulnerability\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- CSV injection\n- Best practices concerns\n- Protocol mismatch\n- Rate limiting\n- Exposed login panels\n- Dangling IPs\n- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n- Content injection issues\n- Missing cookie flags on non-authentication cookies\n- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n- Issues that require physical access to a victim’s computer/device\n- Stack traces\n- Path disclosure\n- Directory listings\n- Banner grabbing issues (figuring out what web server we use, etc.)\n- If a site is abiding by the privacy policy, there is no vulnerability.\n- Enumeration/account oracles\n- UUID enumeration of any kind\n- Invite/Promo code enumeration\n- Gift card enumeration\n- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n- Distributed denial of service attacks (DDOS)\n\n**III. Bounty Awards**\n\n**1. Pay At Triage**\n\nWe strive to reward valid reports within 14 days of acceptance, often sooner.\n\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**2. CVSS Scoring Exceptions**\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**3. Additional Reward Policies**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**IV. Additional Info**\n\n**1. SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n* 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. /foobar.json):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**2. Asset Recon**\n\nUber provides endpoints to determine whether an asset belongs to Uber:\n\nhttps://appsec-analysis.uber.com/public/bugbounty/ListDomains\nhttps://appsec-analysis.uber.com/public/bugbounty/ListIPs \nhttps://appsec-analysis.uber.com/public/bugbounty/ListStorageBuckets\n\nAll of the endpoints support `offset` and `limit` as optional parameters.\n\nExample: https://appsec-analysis.uber.com/public/bugbounty/ListDomains?offset=0\u0026limit=100.\n\n**3. FAQ**\n\n**Can I get Uber swag?**\n\nUber does not currently offer swag.\n\n**Can Uber provide me with a pre-configured test account?**\n\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\n**What is required when submitting a report?**\n\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\n**How do I make my report great?**\n\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\n**I submitted a report. Now what? I have questions.**\n\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\n**What causes a report to be closed as Informative, Duplicate, N/A, or Spam?**\n\nhttps://docs.hackerone.com/hackers/report-states.html\n\n**What is an example of an accepted vulnerability?**\n\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-15T20:46:35.436Z"},{"id":3673842,"new_policy":"\nUber Bug Bounty Program\n---\n\nThe scope for Uber’s Bug Bounty program includes most of our assets. If it is not explicitly out of scope and there is a security impact, we want to know about it. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.\n\nYour participation in our Bug Bounty Program is voluntary. Before finding and reporting any vulnerabilities you are required to read and agree to the Bug Bounty Program Terms (the \"Program Terms\"). In these terms, references to \"you\" or \"researcher\" refer to a researcher that submits a high quality report in accordance with the Uber Bug Bounty Program Terms and \"we\" or \"us\" refers to Uber.\n\n---\n\n**Table of Contents**\n\n**I. Program Terms**\n1. Safe Harbor\n2. Program Eligibility\n3. Program Rules\n4. Disclosure Policy and Confidentiality\n5. Legal\n\n**II. Submitting Reports**\n1. Report Quality\n2. Out of Scope\n\n**III. Bounty Awards**\n1. Pay At Triage\n2. CVSS Scoring Exceptions\n3. Additional Reward Policies\n\n**IV. Additional Info**\n1. SSRF Sheriff\n2. FAQ\n\n---\n\n**I. Program Terms**\n\n**1. Safe Harbor**\n\nAny activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Uber reserves all legal rights in the event of noncompliance with this policy.\n\n**2. Program Eligibility**\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n- Be at least 18 years of age if you test using an Uber account.\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n- Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n**3. Program Rules**\n\n**Do:**\n- Do abide by these Uber Bug Bounty Program Terms.\n- Do respect privacy \u0026 make a good faith effort not to access, process or destroy personal data.\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your report.\n- Do be respectful when interacting with our team, and our team will do the same.\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your `@wearehackerone.com` email address.\n- Do exercise caution when testing to avoid negative impact to customers and the services they depend on.\n- Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.\n\n**Do NOT:**\n- Do not leave any system in a more vulnerable state than you found it.\n- Do not brute force credentials or guess credentials to gain access to systems.\n- Do not participate in denial of service attacks.\n- Do not upload shells or create a backdoor of any kind.\n- Do not publicly disclose a Vulnerability without our explicit review and consent.\n- Do not engage in any form of social engineering of Uber employees, customers, or partners.\n- Do not engage or target any Uber employee, customer, or partner during your testing.\n- Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.\n- Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.\n- Do not interact with accounts you do not own.\n\n**4. Disclosure Policy and Confidentiality**\n\nAny data you receive, obtain access to or collect about Uber, Uber affiliates or any Uber users, customers, employees or agents in connection with the Bug Bounty Program is considered Uber’s confidential information (\"Confidential Information\").\n\nConfidential Information must be kept confidential and only used: (i) to make the disclosure to Uber under the Uber Bug Bounty Program; or (ii) to provide any additional information that may be required by Uber in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Uber's request, you will permanently erase all Confidential Information for any systems and devices.\n\nYou may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Bug Bounty submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.\n\nAny unauthorized public disclosure will result in a program ban.\n\nPlease review HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) for general best practices. For any reports submitted to Uber, this policy supersedes any conflicting HackerOne policies.\n\n**5. Legal**\n\nUber reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\nPlease check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can [subscribe](https://docs.hackerone.com/hackers/manage-notifications.html#program-notifications) to receive email notifications when this policy is updated.\n\n**II. Submitting Reports**\n\n**1. Report Quality**\n\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n- Video only proof-of-concepts (PoCs) will not be considered.\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n- All reports must demonstrate security impact to be considered for bounty reward.\n\n**2. Out-of-Scope**\n\nIn addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:\n\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n- Negligible security impact\n- Unchained open redirects\n- Reports that state that software is out of date/vulnerable without a proof-of-concept\n- Highly speculative reports about theoretical damage\n- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n- SSL/TLS scan reports (this means output from sites such as SSL Labs)\n- Open ports without an accompanying proof-of-concept demonstrating vulnerability\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- CSV injection\n- Best practices concerns\n- Protocol mismatch\n- Rate limiting\n- Exposed login panels\n- Dangling IPs\n- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n- Content injection issues\n- Missing cookie flags on non-authentication cookies\n- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n- Issues that require physical access to a victim’s computer/device\n- Stack traces\n- Path disclosure\n- Directory listings\n- Banner grabbing issues (figuring out what web server we use, etc.)\n- If a site is abiding by the privacy policy, there is no vulnerability.\n- Enumeration/account oracles\n- UUID enumeration of any kind\n- Invite/Promo code enumeration\n- Gift card enumeration\n- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n- Distributed denial of service attacks (DDOS)\n\n**III. Bounty Awards**\n\n**1. Pay At Triage**\n\nWe strive to reward valid reports within 14 days of acceptance, often sooner.\n\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**2. CVSS Scoring Exceptions**\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**3. Additional Reward Policies**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**IV. Additional Info**\n\n**1. SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n* 'http://dca11-pra.prod.uber.internal:31084/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. /foobar.json):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**2. FAQ**\n\n**Can I get Uber swag?**\n\nUber does not currently offer swag.\n\n**Can Uber provide me with a pre-configured test account?**\n\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\n**What is required when submitting a report?**\n\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\n**How do I make my report great?**\n\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\n**I submitted a report. Now what? I have questions.**\n\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\n**What causes a report to be closed as Informative, Duplicate, N/A, or Spam?**\n\nhttps://docs.hackerone.com/hackers/report-states.html\n\n**What is an example of an accepted vulnerability?**\n\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-07-05T23:07:41.647Z"},{"id":3671355,"new_policy":"\nUber Bug Bounty Program\n---\n\nThe scope for Uber’s Bug Bounty program includes most of our assets. If it is not explicitly out of scope and there is a security impact, we want to know about it. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.\n\nYour participation in our Bug Bounty Program is voluntary. Before finding and reporting any vulnerabilities you are required to read and agree to the Bug Bounty Program Terms (the \"Program Terms\"). In these terms, references to \"you\" or \"researcher\" refer to a researcher that submits a high quality report in accordance with the Uber Bug Bounty Program Terms and \"we\" or \"us\" refers to Uber.\n\n---\n\n**Table of Contents**\n\n**I. Program Terms**\n1. Safe Harbor\n2. Program Eligibility\n3. Program Rules\n4. Disclosure Policy and Confidentiality\n5. Legal\n\n**II. Submitting Reports**\n1. Report Quality\n2. Out of Scope\n\n**III. Bounty Awards**\n1. Pay At Triage\n2. CVSS Scoring Exceptions\n3. Additional Reward Policies\n\n**IV. Additional Info**\n1. SSRF Sheriff\n2. FAQ\n\n---\n\n**I. Program Terms**\n\n**1. Safe Harbor**\n\nAny activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Uber reserves all legal rights in the event of noncompliance with this policy.\n\n**2. Program Eligibility**\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n- Be at least 18 years of age if you test using an Uber account.\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n- Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n**3. Program Rules**\n\n**Do:**\n- Do abide by these Uber Bug Bounty Program Terms.\n- Do respect privacy \u0026 make a good faith effort not to access, process or destroy personal data.\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your report.\n- Do be respectful when interacting with our team, and our team will do the same.\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your `@wearehackerone.com` email address.\n- Do exercise caution when testing to avoid negative impact to customers and the services they depend on.\n- Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.\n\n**Do NOT:**\n- Do not leave any system in a more vulnerable state than you found it.\n- Do not brute force credentials or guess credentials to gain access to systems.\n- Do not participate in denial of service attacks.\n- Do not upload shells or create a backdoor of any kind.\n- Do not publicly disclose a Vulnerability without our explicit review and consent.\n- Do not engage in any form of social engineering of Uber employees, customers, or partners.\n- Do not engage or target any Uber employee, customer, or partner during your testing.\n- Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.\n- Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.\n- Do not interact with accounts you do not own.\n\n**4. Disclosure Policy and Confidentiality**\n\nAny data you receive, obtain access to or collect about Uber, Uber affiliates or any Uber users, customers, employees or agents in connection with the Bug Bounty Program is considered Uber’s confidential information (\"Confidential Information\").\n\nConfidential Information must be kept confidential and only used: (i) to make the disclosure to Uber under the Uber Bug Bounty Program; or (ii) to provide any additional information that may be required by Uber in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Uber's request, you will permanently erase all Confidential Information for any systems and devices.\n\nYou may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Bug Bounty submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.\n\nAny unauthorized public disclosure will result in a program ban.\n\nPlease review HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) for general best practices. For any reports submitted to Uber, this policy supersedes any conflicting HackerOne policies.\n\n**5. Legal**\n\nUber reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\nPlease check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can [subscribe](https://docs.hackerone.com/hackers/manage-notifications.html#program-notifications) to receive email notifications when this policy is updated.\n\n**II. Submitting Reports**\n\n**1. Report Quality**\n\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n- Video only proof-of-concepts (PoCs) will not be considered.\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n- All reports must demonstrate security impact to be considered for bounty reward.\n\n**2. Out-of-Scope**\n\nIn addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:\n\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n- Negligible security impact\n- Unchained open redirects\n- Reports that state that software is out of date/vulnerable without a proof-of-concept\n- Highly speculative reports about theoretical damage\n- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n- SSL/TLS scan reports (this means output from sites such as SSL Labs)\n- Open ports without an accompanying proof-of-concept demonstrating vulnerability\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- CSV injection\n- Best practices concerns\n- Protocol mismatch\n- Rate limiting\n- Exposed login panels\n- Dangling IPs\n- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n- Content injection issues\n- Missing cookie flags on non-authentication cookies\n- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n- Issues that require physical access to a victim’s computer/device\n- Stack traces\n- Path disclosure\n- Directory listings\n- Banner grabbing issues (figuring out what web server we use, etc.)\n- If a site is abiding by the privacy policy, there is no vulnerability.\n- Enumeration/account oracles\n- UUID enumeration of any kind\n- Invite/Promo code enumeration\n- Gift card enumeration\n- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n- Distributed denial of service attacks (DDOS)\n\n**III. Bounty Awards**\n\n**1. Pay At Triage**\n\nWe strive to reward valid reports within 14 days of acceptance, often sooner.\n\nBounty rewards will be calculated according to CVSS 3.1 as applicable and using the bounty ranges published on our program page.\n\nThe official CVSS 3.1 reference used by our program is:\nhttps://nvd.nist.gov/vuln-metrics/cvss/v3-calculator\n\nAt our discretion as program owners, some report types will not receive rewards based on CVSS 3.1 score. These reports will receive either a fixed amount reward or the reward will be determined on a case-by-case basis. See Section 2 below.\n\n**2. CVSS Scoring Exceptions**\n\nThe report types listed below will receive rewards without calculating a CVSS 3.1 score:\n\n| Type | Reward |\n| :------: | :---------: |\n| Subdomain Takeover | $500 |\n| 3rd Party Info Disclosures (Prezi, Trello, Google Doc, etc) | Case by case |\n\n**3. Additional Reward Policies**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**IV. Additional Info**\n\n**1. SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n* `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n* `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. /foobar.json):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**2. FAQ**\n\n**Can I get Uber swag?**\n\nUber does not currently offer swag.\n\n**Can Uber provide me with a pre-configured test account?**\n\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\n**What is required when submitting a report?**\n\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\n**How do I make my report great?**\n\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\n**I submitted a report. Now what? I have questions.**\n\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\n**What causes a report to be closed as Informative, Duplicate, N/A, or Spam?**\n\nhttps://docs.hackerone.com/hackers/report-states.html\n\n**What is an example of an accepted vulnerability?**\n\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-05-13T15:55:06.705Z"},{"id":3663452,"new_policy":"\nUber Bug Bounty Program\n---\n\nThe scope for Uber’s Bug Bounty program includes most of our assets. If it is not explicitly out of scope and there is a security impact, we want to know about it. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.\n\nYour participation in our Bug Bounty Program is voluntary. Before finding and reporting any vulnerabilities you are required to read and agree to the Bug Bounty Program Terms (the \"Program Terms\"). In these terms, references to \"you\" or \"researcher\" refer to a researcher that submits a high quality report in accordance with the Uber Bug Bounty Program Terms and \"we\" or \"us\" refers to Uber.\n\n---\n\n**Table of Contents**\n\n**I. Program Terms**\n1. Safe Harbor\n2. Program Eligibility\n3. Program Rules\n4. Disclosure Policy and Confidentiality\n5. Legal\n\n**II. Submitting Reports**\n1. Report Quality\n2. Out of Scope\n\n**III. Bounty Awards**\n\n**IV. Additional Info**\n1. SSRF Sheriff\n2. FAQ\n\n---\n\n**I. Program Terms**\n\n**1. Safe Harbor**\n\nAny activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Uber reserves all legal rights in the event of noncompliance with this policy.\n\n**2. Program Eligibility**\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n- Be at least 18 years of age if you test using an Uber account.\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n- Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n**3. Program Rules**\n\n**Do:**\n- Do abide by these Uber Bug Bounty Program Terms.\n- Do respect privacy \u0026 make a good faith effort not to access, process or destroy personal data.\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your report.\n- Do be respectful when interacting with our team, and our team will do the same.\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your `@wearehackerone.com` email address.\n- Do exercise caution when testing to avoid negative impact to customers and the services they depend on.\n- Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.\n\n**Do NOT:**\n- Do not leave any system in a more vulnerable state than you found it.\n- Do not brute force credentials or guess credentials to gain access to systems.\n- Do not participate in denial of service attacks.\n- Do not upload shells or create a backdoor of any kind.\n- Do not publicly disclose a Vulnerability without our explicit review and consent.\n- Do not engage in any form of social engineering of Uber employees, customers, or partners.\n- Do not engage or target any Uber employee, customer, or partner during your testing.\n- Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.\n- Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.\n- Do not interact with accounts you do not own.\n\n**4. Disclosure Policy and Confidentiality**\n\nAny data you receive, obtain access to or collect about Uber, Uber affiliates or any Uber users, customers, employees or agents in connection with the Bug Bounty Program is considered Uber’s confidential information (\"Confidential Information\").\n\nConfidential Information must be kept confidential and only used: (i) to make the disclosure to Uber under the Uber Bug Bounty Program; or (ii) to provide any additional information that may be required by Uber in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Uber's request, you will permanently erase all Confidential Information for any systems and devices.\n\nYou may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Bug Bounty submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.\n\nAny unauthorized public disclosure will result in a program ban.\n\nPlease review HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) for general best practices. For any reports submitted to Uber, this policy supersedes any conflicting HackerOne policies.\n\n**5. Legal**\n\nUber reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\nPlease check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can [subscribe](https://docs.hackerone.com/hackers/manage-notifications.html#program-notifications) to receive email notifications when this policy is updated.\n\n**II. Submitting Reports**\n\n**1. Report Quality**\n\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n- Video only proof-of-concepts (PoCs) will not be considered.\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n- All reports must demonstrate security impact to be considered for bounty reward.\n\n**2. Out-of-Scope**\n\nIn addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:\n\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n- Negligible security impact\n- Unchained open redirects\n- Reports that state that software is out of date/vulnerable without a proof-of-concept\n- Highly speculative reports about theoretical damage\n- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n- SSL/TLS scan reports (this means output from sites such as SSL Labs)\n- Open ports without an accompanying proof-of-concept demonstrating vulnerability\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- CSV injection\n- Best practices concerns\n- Protocol mismatch\n- Rate limiting\n- Exposed login panels\n- Dangling IPs\n- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n- Content injection issues\n- Missing cookie flags on non-authentication cookies\n- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n- Issues that require physical access to a victim’s computer/device\n- Stack traces\n- Path disclosure\n- Directory listings\n- Banner grabbing issues (figuring out what web server we use, etc.)\n- If a site is abiding by the privacy policy, there is no vulnerability.\n- Enumeration/account oracles\n- UUID enumeration of any kind\n- Invite/Promo code enumeration\n- Gift card enumeration\n- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n- Distributed denial of service attacks (DDOS)\n\n**III. Bounty Awards**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**IV. Additional Info**\n\n**1. SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n* `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n* `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. /foobar.json):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**2. FAQ**\n\n**Can I get Uber swag?**\n\nUber does not currently offer swag.\n\n**Can Uber provide me with a pre-configured test account?**\n\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\n**What is required when submitting a report?**\n\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\n**How do I make my report great?**\n\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\n**I submitted a report. Now what? I have questions.**\n\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\n**What causes a report to be closed as Informative, Duplicate, N/A, or Spam?**\n\nhttps://docs.hackerone.com/hackers/report-states.html\n\n**What is an example of an accepted vulnerability?**\n\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-12-29T00:09:00.829Z"},{"id":3663446,"new_policy":"\nUber Bug Bounty Program\n---\n\nThe scope for Uber’s Bug Bounty program includes most of our assets. If it is not explicitly out of scope and there is a security impact, we want to know about it. Issues without security impact that are submitted to our program will be closed. Please review the program’s Out of Scope section and all other policies before submitting a report.\n\nYour participation in our Bug Bounty Program is voluntary. Before finding and reporting any vulnerabilities you are required to read and agree to the Bug Bounty Program Terms (the \"Program Terms\"). In these terms, references to \"you\" or \"researcher\" refer to a researcher that submits a high quality report in accordance with the Uber Bug Bounty Program Terms and \"we\" or \"us\" refers to Uber.\n\n---\n\n**Table of Contents**\n\n**I. Program Terms**\n1. Safe Harbor\n2. Program Eligibility\n3. Program Rules\n4. Disclosure Policy and Confidentiality\n5. Legal\n\n**II. Submitting Reports**\n1. Report Quality\n2. Out of Scope\n\n**III. Bounty Awards**\n\n**IV. Additional Info**\n1. SSRF Sheriff\n2. FAQ\n\n---\n\n**I. Program Terms**\n\n**1. Safe Harbor**\n\nAny activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Uber reserves all legal rights in the event of noncompliance with this policy.\n\n**2. Program Eligibility**\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n- Be at least 18 years of age if you test using an Uber account.\n- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n- Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n**3. Program Rules**\n\n**Do:**\n- Do abide by these Uber Bug Bounty Program Terms.\n- Do respect privacy \u0026 make a good faith effort not to access, process or destroy personal data.\n- Do be patient \u0026 make a good faith effort to provide clarifications to any questions we may have about your report.\n- Do be respectful when interacting with our team, and our team will do the same.\n- Do perform testing only using accounts that are your own personal/test accounts. By default, we expect your report to clearly reference your @wearehackerone.com email address.\n- Do exercise caution when testing to avoid negative impact to customers and the services they depend on.\n- Do stop whenever unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.\n\n**Do NOT:**\n- Do not leave any system in a more vulnerable state than you found it.\n- Do not brute force credentials or guess credentials to gain access to systems.\n- Do not participate in denial of service attacks.\n- Do not upload shells or create a backdoor of any kind.\n- Do not publicly disclose a Vulnerability without our explicit review and consent.\n- Do not engage in any form of social engineering of Uber employees, customers, or partners.\n- Do not engage or target any Uber employee, customer, or partner during your testing.\n- Do not attempt to extract, download, or otherwise exfiltrate data that may have PII or other sensitive data other than your own.\n- Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password of an account you did not register yourself or an account that was not provided to you, stop and report the finding immediately.\n- Do not do anything that would be considered a privacy violation, cause destruction of data, or interrupt or degrade our service.\n- Do not interact with accounts you do not own.\n\n**4. Disclosure Policy and Confidentiality**\n\nAny data you receive, obtain access to or collect about Uber, Uber affiliates or any Uber users, customers, employees or agents in connection with the Bug Bounty Program is considered Uber’s confidential information (\"Confidential Information\").\n\nConfidential Information must be kept confidential and only used: (i) to make the disclosure to Uber under the Uber Bug Bounty Program; or (ii) to provide any additional information that may be required by Uber in relation to the submitted report. No further use or exploitation of Confidential Information is allowed. Upon Uber's request, you will permanently erase all Confidential Information for any systems and devices.\n\nYou may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Bug Bounty submitted report, without our prior explicit consent. You must get explicit consent by submitting a disclosure request to our program. Please note, not all requests for public disclosure will be approved.\n\nAny unauthorized public disclosure will result in a program ban.\n\nPlease review HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) for general best practices. For any reports submitted to Uber, this policy supersedes any conflicting HackerOne policies.\n\n**5. Legal**\n\nUber reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n\nPlease check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can [subscribe](https://docs.hackerone.com/hackers/manage-notifications.html#program-notifications) to receive email notifications when this policy is updated.\n\n**II. Submitting Reports**\n\n**1. Report Quality**\n\nHigh quality submissions allow our team to understand the issue better and engage the appropriate teams to fix. The best reports provide enough actionable information to verify and validate the issue without requiring any follow up questions for more information or clarification.\n\n- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n- Video only proof-of-concepts (PoCs) will not be considered.\n- A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n- All reports must demonstrate security impact to be considered for bounty reward.\n\n**2. Out-of-Scope**\n\nIn addition to the explicit Out of Scope list on our program page, reports of the following issues are also out of scope:\n\n- Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n- Ability to send push notifications/SMS messages/emails without the ability to change content\n- Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n- Negligible security impact\n- Unchained open redirects\n- Reports that state that software is out of date/vulnerable without a proof-of-concept\n- Highly speculative reports about theoretical damage\n- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n- SSL/TLS scan reports (this means output from sites such as SSL Labs)\n- Open ports without an accompanying proof-of-concept demonstrating vulnerability\n- Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n- CSV injection\n- Best practices concerns\n- Protocol mismatch\n- Rate limiting\n- Exposed login panels\n- Dangling IPs\n- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n- Content injection issues\n- Missing cookie flags on non-authentication cookies\n- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n- Issues that require physical access to a victim’s computer/device\n- Stack traces\n- Path disclosure\n- Directory listings\n- Banner grabbing issues (figuring out what web server we use, etc.)\n- If a site is abiding by the privacy policy, there is no vulnerability.\n- Enumeration/account oracles\n- UUID enumeration of any kind\n- Invite/Promo code enumeration\n- Gift card enumeration\n- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n- Distributed denial of service attacks (DDOS)\n\n**III. Bounty Awards**\n\nPrevious bounty amounts are not considered a precedent for future bounty amounts. Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWhen determining bounty amounts, we consider the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nBounty payouts and amounts, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, only the earliest valid report that meets requirements and provides enough actionable information to identify the issue may be considered for a bounty.\n\n**IV. Additional Info**\n\n**1. SSRF Sheriff**\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n* `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n* `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to any endpoint, of any request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. /foobar.json):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n**2. FAQ**\n\n**Can I get Uber swag?**\n\nUber does not currently offer swag.\n\n**Can Uber provide me with a pre-configured test account?**\n\nIf credentials are necessary to access any of our assets, this will be included in our policy page under test plan or test instructions. If you do not see any instructions about test accounts in our policy, none are available or provided.\n\n**What is required when submitting a report?**\n\nhttps://docs.hackerone.com/hackers/submitting-reports.html\n\n**How do I make my report great?**\n\nhttps://docs.hackerone.com/hackers/quality-reports.html\n\n**I submitted a report. Now what? I have questions.**\n\nhttps://www.hackerone.com/blog/how-bug-bounty-reports-work\n\n**What causes a report to be closed as Informative, Duplicate, N/A, or Spam?**\n\nhttps://docs.hackerone.com/hackers/report-states.html\n\n**What is an example of an accepted vulnerability?**\n\nValid and accepted vulnerabilities would be the type of report that identifies a unique security impact on this program’s specific scope. The report must also meet any submission criteria outlined in the policy, such as test plan instructions and a working proof of concept.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-12-28T19:15:13.208Z"},{"id":3663296,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n- `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are:  \n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * RouteMatch\n      * Transplace\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://hackerone.com/careem?type=team)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-12-21T22:55:02.868Z"},{"id":3663061,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n- `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are:  \n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * RouteMatch\n      * Transplace\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://hackerone.com/careem?type=team)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `uberscoot.us`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-12-15T18:51:00.975Z"},{"id":3663060,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n- `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are:  \n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * RouteMatch\n      * Transplace\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://hackerone.com/careem?type=team)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `uberscoot.us`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-12-15T18:49:32.247Z"},{"id":3661880,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://dca11-45h.prod.uber.internal:31247/\u003chandle\u003e@wearehackerone.com`\n- `http://phx4-war.prod.uber.internal:31981/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are:  \n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * RouteMatch\n      * Transplace\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `uberscoot.us`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-17T22:07:34.701Z"},{"id":3661810,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are:  \n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * RouteMatch\n      * Transplace\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `uberscoot.us`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-16T22:45:20.115Z"},{"id":3661795,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are:  \n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * RouteMatch\n      * Transplace\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-16T16:52:37.516Z"},{"id":3661524,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n* All reports must demonstrate security impact to be considered for bounty reward.\n\n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n\n* **Fraud reports are out of scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-10T16:27:10.940Z"},{"id":3661523,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-10T16:22:53.292Z"},{"id":3660231,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\n==Security Awareness Month Promotion==\n---------------------\n$$ Bounty multipliers for High and Critical vulnerabilities! \nSee promotion details on the [Updates tab](https://hackerone.com/uber/updates?type=team).\n\n=========================\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-10-19T19:17:54.633Z"},{"id":3660230,"new_policy":"\nUber Bug Bounty Program Terms\n__________________________________________\n\nSecurity Awareness Month Promotion\n---------------------\n$$ Bounty multipliers for High and Critical vulnerabilities! \nSee promotion details on the [Updates tab](https://hackerone.com/uber/updates?type=team).\n\n=========================\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-10-19T19:17:05.795Z"},{"id":3659184,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n*    `ot.to`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-10-03T18:15:16.783Z"},{"id":3657894,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * Careem (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-03T18:56:51.002Z"},{"id":3657890,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * HKTaxi\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-03T18:18:00.926Z"},{"id":3657888,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Rate limiting \n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-03T17:01:24.118Z"},{"id":3654770,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * AutoCab\n      * Drizly\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n  * The following mobile apps:\n      * Postmates versions prior to 5.23.0 (Android) and 6.0 (iOS)\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-07-13T21:19:04.463Z"},{"id":3652797,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n      * UT\n\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-27T18:03:36.965Z"},{"id":3650867,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\nGood Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-04-06T22:55:37.069Z"},{"id":3650859,"new_policy":"\nUber Bug Bounty Program Terms\n=====================\n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---------------------\nTable of Contents\n---------------------\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---------------------\n##Good Faith Vulnerability Research and Disclosure\n---------------------\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---------------------\nEligibility to Participate\n---------------------\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---------------------\nSubmissions and Report Quality\n---------------------\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---------------------\nSSRF Sheriff\n---------------------\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---------------------\nSecurity Impact Buckets\n---------------------\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---------------------\nBounty Amounts\n---------------------\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---------------------\nOut-of-Scope\n---------------------\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---------------------\nConfidentiality\n---------------------\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---------------------\nRights and Licenses\n---------------------\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-04-06T18:54:30.896Z"},{"id":3650075,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267/\u003chandle\u003e@wearehackerone.com`\n- `http://dca4-erz.prod.uber.internal:31551/\u003chandle\u003e@wearehackerone.com`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-19T00:49:35.774Z"},{"id":3649860,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267`\n- `http://dca4-erz.prod.uber.internal:31551`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Divested Companies** \n   * Recently divested companies or Lines of Business  \n   * Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * SoBi/Social Bicycles\n      * Jump\n      * Uber Freight EU\n      * ATG\n      * Uber China\n      * Lion City Rental\n      * Uber Russia\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-11T21:18:36.248Z"},{"id":3649718,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://agent10046-phx3.prod.uber.internal:31267`\n- `http://dca4-erz.prod.uber.internal:31551`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-08T20:15:22.723Z"},{"id":3649600,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://192.168.255.20:7764`\n- `http://agent10046-phx3.prod.uber.internal:7764`\n- `http://dca4-erz.prod.uber.internal:7764`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*     `*.sobi.io` domains or any properties relating to SocialBicycles/SoBi, since they belong to MobilityCloud Inc\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-05T02:13:36.813Z"},{"id":3648710,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.217.158:31536` aka `http://agent6836-phx3.prod.uber.internal:31536`\n- `http://10.196.238.0:31005` aka `http://agent8516-dca4.prod.uber.internal:31005`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n      * Drizly\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-02-12T22:56:47.932Z"},{"id":3648603,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.217.158:31536` aka `http://agent6836-phx3.prod.uber.internal:31536`\n- `http://10.196.238.0:31005` aka `http://agent8516-dca4.prod.uber.internal:31005`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently signed/acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n      * AutoCab\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-02-10T23:07:58.046Z"},{"id":3646361,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.217.158:31536` aka `http://agent6836-phx3.prod.uber.internal:31536`\n- `http://10.196.238.0:31005` aka `http://agent8516-dca4.prod.uber.internal:31005`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n      * Postmates\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-12-02T01:49:44.879Z"},{"id":3642256,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.217.158:31536` aka `http://agent6836-phx3.prod.uber.internal:31536`\n- `http://10.196.238.0:31005` aka `http://agent8516-dca4.prod.uber.internal:31005`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop: security@cornershopapp.com\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-10T22:20:10.534Z"},{"id":3642253,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.217.158:31536` aka `http://agent6836-phx3.prod.uber.internal:31536`\n- `http://10.196.238.0:31005` aka `http://agent8516-dca4.prod.uber.internal:31005`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Acquired Companies** \n   * Recently acquired companies will be subject to a blackout period to allow our team to get up to speed and perform internal reviews.   Bugs reported during the blackout period will typically not qualify for a reward.\n   * Companies currently in a blackout period are: \n      * RouteMatch\n   * The following acquired companies run their own public bug bounty or vulnerability disclosure programs.  Vulnerabilities solely pertaining to these companies are out of scope and should be reported directly to their programs:\n      * [Careem] (https://security.careem.com/)\n      * Cornershop\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-10T21:32:56.636Z"},{"id":3641304,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.217.158:31536` aka `http://agent6836-phx3.prod.uber.internal:31536`\n- `http://10.196.238.0:31005` aka `http://agent8516-dca4.prod.uber.internal:31005`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-08-13T22:16:12.912Z"},{"id":3633536,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.214.84:31386` aka `http://agent6478-phx3.prod.uber.internal:31386`\n- `http://10.196.238.0:31054` aka `http://agent8516-dca4.prod.uber.internal:31054`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-03-20T18:50:10.073Z"},{"id":3632910,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.214.84:31626` aka `http://agent6478-phx3.prod.uber.internal:31626`\n- `http://10.196.238.0:31030` aka `http://agent8516-dca4.prod.uber.internal:31030`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage if the security impact is immediately understood, and then the remainder of the bounty at resolution once we completely understand the security impact. In the unlikely event that we are unable to tell at the time of triage if a Submission is eligible for a bounty, we will hold off on awarding the minimum bounty until we're able to confirm or until the report is resolved. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-03-13T21:42:17.048Z"},{"id":3632335,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.214.84:31626` aka `http://agent6478-phx3.prod.uber.internal:31626`\n- `http://10.196.238.0:31030` aka `http://agent8516-dca4.prod.uber.internal:31030`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-03-05T23:21:13.692Z"},{"id":3632327,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.214.84:31883` aka `http://agent6478-phx3.prod.uber.internal:31883`\n- `http://10.196.238.0:31000` aka `http://agent8516-dca4.prod.uber.internal:31000`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-03-05T19:53:31.354Z"},{"id":3626445,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* SSRF Sheriff\n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##SSRF Sheriff\n---\n\nWe have set up a \"sheriff\" service for SSRF testing. If you believe you have an SSRF in production, please use either of the following IP/port combinations for testing:\n\n- `http://10.82.126.161:31368` aka `http://agent632-phx3.prod.uber.internal:31368`\n- `http://10.196.238.0:31000` aka `http://agent8516-dca4.prod.uber.internal:31000`\n\nThis service will accept HTTP requests to *any* endpoint, of *any* request type, and will return a secret token in both headers and response body. It also responds with valid response types for all of the file extensions listed below (just append the extension to your request path, e.g. `/foobar.json`):\n\n- xml\n- json\n- gif, png, jpg/jpeg\n- html\n- txt\n- mp4\n- csv\n\nFor additional information about the SSRF Sheriff Service, including the source code, see: https://github.com/teknogeek/ssrf-sheriff\n\n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-18T19:40:11.678Z"},{"id":3624663,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Unchained open redirects\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-26T17:42:51.097Z"},{"id":3623414,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Unchained open redirects\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Gift card enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-11T18:05:25.850Z"},{"id":3623277,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n*    Research and disclose in good faith.\n*    Respect our users’ privacy.\n*    No extortion, shake downs, or duress.\n*    Don’t leave any system in a more vulnerable state than you found it.\n*    Don’t publicly disclose a vulnerability without our consent and review.\n*    Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Unchained open redirects\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-08T21:14:37.176Z"},{"id":3623276,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n    * Research and disclose in good faith.\n    * Respect our users’ privacy.\n    * No extortion, shake downs, or duress.\n    * Don’t leave any system in a more vulnerable state than you found it.\n    * Don’t publicly disclose a vulnerability without our consent and review.\n    * Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Unchained open redirects\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    `*.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-08T20:59:43.815Z"},{"id":3623275,"new_policy":"--- \n##Uber Bug Bounty Program Terms\n--- \n\nThe scope for Uber’s Bug Bounty program is inclusive of most of our assets. If it’s not out of scope, and it’s impactful, it’s in scope. If you find something that would be impactful to our users, we want to hear about it. Issues without security impact submitted to our program will be closed out - please review our out of scope section before submitting. \n\nYour participation in our Bug Bounty Program is voluntary. By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).\n\n**Ground Rules**\n    * Research and disclose in good faith.\n    * Respect our users’ privacy.\n    * No extortion, shake downs, or duress.\n    * Don’t leave any system in a more vulnerable state than you found it.\n    * Don’t publicly disclose a vulnerability without our consent and review.\n    * Be respectful when interacting with our team, and our team will do the same.\n \n---\n##Table of Contents\n---\n* Good Faith Vulnerability Research and Disclosure\n* Eligibility to Participate\n* Submissions and Report Quality \n* Security Impact Buckets \n* Bounty Amounts\n* Out-of-Scope\n* Confidentiality\n* Rights and Licenses \n \n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith means that you will:\n\n**Play by the rules.** This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between these Program Terms and any of Uber’s other terms,  the program terms described on this page will control. \n \n**Respect our users’ privacy.** You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:\n \n*    Stop right there. Actions taken beyond this are not authorized.\n*    Report this immediately to our Bug Bounty team so we can investigate.\n*    Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n*    Work with us if we have any further requests.\n\n**Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.\n \n**Don’t cause more harm than good.** You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.\n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.\n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n##Eligibility to Participate\n---\n\nTo be eligible to participate in our Bug Bounty Program, you must:\n\n* Be at least 18 years of age if you test using an Uber account.\n* Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n* Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n* Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n* Not be using duplicate HackerOne accounts.\n \nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only proof-of-concepts (PoCs) will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.\n \n---\n##Security Impact Buckets\n---\n\nWe use “impact buckets” to categorize vulnerabilities, and each impact bucket has several different factors that we use to determine the overall severity and likelihood of the issue.\n\n**Data Exposure**:  the ability to access user data, employee data, or sensitive Uber business data without having an authorized relationship with the Victim or the company.\n* Factors considered may include: \n    * Number of impacted users\n    * Sensitivity of data exposed \n    * Scale of exposure \n\n**Unauthorized Actions on Behalf of User**: the ability to forge authenticated actions on behalf of a Victim.\n* Factors considered may include: \n    * Ability to modify data on behalf of another user \n    * Severity of forged actions\n    * Possibility of account takeover\n    * Level of privilege/access obtained\n    * Actions noticeable by victim \n\n**Unauthorized Actions on Behalf of Uber**: the ability to forge authenticated actions on behalf of Uber.\n* Factors considered may include: \n    * Actions performed by the authenticated request\n    * Level of privilege/access obtained\n    * Service interruption \n    * Requires brute forcing \n\n**Monetary Impact**: the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* Factors considered may include: \n    * Financial impact\n    * Service interruption \n    * Number of impacted users\n    * Requires multiple accounts \n \n**Social Engineering**: the ability to carry out targeted and convincing phishing on Uber users.  (Note: Almost all examples of social engineering end up out-of-scope; see below.)\n* Factors considered may include: \n    * Sensitivity of data exposed \n    * Number of users impacted \n    * Possibility of account takeover\n    * Ability to control content \n    * Existence of rate limiting\n\n**Physical Safety**: the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* Factors considered may include: \n    * Potential to cause physical harm \n    * Number of users potentially impacted \n \n---\n##Bounty Amounts\n---\nPrevious bounty amounts are not considered a precedent for future bounty amounts.\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our $500 minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact. In the unlikely event that we're unable to tell at the time of triage if a Submission is within scope, we will hold off on awarding the minimum bounty until we're able to confirm. \n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n##Out-of-Scope\n---\n* Must demonstrate security impact for report to be considered - general software bugs are not in scope for this program. \n\n* **Fraud reports are no longer in scope. This includes reports detailing the ability to take free rides and evade payment. Please send all fraud-related issues to external-fraud-reports-group@uber.com**\n\n* **Most Social Engineering**\n    * Unchained open redirects\n    * Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n    * Ability to send push notifications/SMS messages/emails without the ability to change content\n    * Ability to take over social media pages (Twitter, Facebook, Linkedin, etc)\n    * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* **Negligible security impact**\n    * Reports that state that software is out of date/vulnerable without a proof-of-concept\n    * Highly speculative reports about theoretical damage \n    * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n    * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated\n    * SSL/TLS scan reports (this means output from sites such as SSL Labs)\n    * Open ports without an accompanying proof-of-concept demonstrating vulnerability\n    * Subdomain takeovers - please demonstrate that you are able to take over the page by leaving a non-offensive message, such as your username\n    * CSV injection\n    * Best practices concerns\n    * Protocol mismatch\n    * Exposed login panels\n    * Dangling IPs\n    * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console\n    * Content injection issues\n    * Missing cookie flags on non-authentication cookies\n    * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n    * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores\n    * Issues that require physical access to a victim’s computer/device\n    * Stack traces\n    * Path disclosure\n    * Directory listings\n    * Banner grabbing issues (figuring out what web server we use, etc.)\n    * If a site is abiding by the privacy policy, there is no vulnerability.\n* **Enumeration/account oracles**\n    * UUID enumeration of any kind\n    * Invite/Promo code enumeration\n    * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists\n* **Distributed denial of service attacks (DDOS)**\n \n**Out-of-scope domains**\n*    `support-uber.com`\n*    `lioncityrentals.com.sg`\n*    `xchangeleasing.com`\n*    `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n*    `uber.onelogin.com` (OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them)\n*    `bizblog.uber.com`\n*    `newsroom.uber.com`\n*    `love.uber.com`\n*    `drive.uber.com`\n*     `eng.uber.com`\n*    `people.uber.com`\n*    *`.et.uber.com`\n \n---\n##Confidentiality\n---\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request through the HackerOne platform. Please note, not all requests for public disclosure can be approved. \n\n---\n##Rights and Licenses\n---\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.\n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.\n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-11-08T20:58:09.017Z"},{"id":3574808,"new_policy":"---\n##Uber Bug Bounty Program Terms\n--- \nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.  \nYour participation in our Bug Bounty Program is voluntary.  By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n**Ground Rules**\n  * Research and disclose in good faith.\n  * Respect our users’ privacy.  \n  * No extortion, shake downs, or duress.\n  * Don’t leave any system in a more vulnerable state than you found it.\n  * Don’t publicly disclose a vulnerability without our consent.\n  * Be respectful when interacting with our team, and our team will do the same.\n\n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n\n1. **Play by the rules.**  This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains.  If there is any inconsistency between the these Program Terms and any of Uber’s other terms, these Program Terms will control.  \n\n2. **Respect our users’ privacy.**  You should only interact with Uber accounts you own or with explicit permission from the account holder.  We want you to hunt for bugs, not user data.  If you encounter user information during the course of your research:\n  * Stop right there.  Actions taken beyond this are not authorized.\n  * Report this immediately to our Bug Bounty team so we can investigate.\n  * Do not save, copy, store, transfer, disclose, or otherwise retain the information.\n  * Work with us if we have any further requests.\n\n\n3. **Don’t extort us.** You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down.  In other words, if you find a vulnerability, report it to us with no conditions attached.    \n\n4. **Don’t cause more harm than good.**  You should never leave a system or users in a more vulnerable state than when you found them.  This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.  \n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and if a third party initiates legal action, we will make it known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.  \n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n## Eligibility to Participate\n---\nTo be eligible to participate in our Bug Bounty Program, you must:\n  * Have a signal of at least 1.0 or written permission from Uber’s Bug Bounty Team.\n  * Be at least 18 years of age if you test using an Uber account.\n  * Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n  * Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n  * Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n  * Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship with the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n\n\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality Submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n\n   * Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n   * Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n   * Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n   * In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n   * Video only proof-of-concepts (PoCs) will not be considered.\n   * A vulnerability must be verifiable and reproducible for us to be considered in-scope.  \n\n\n---\n##Confidentiality\n---\n\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have significantly different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we pay out our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\n\n\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n## Out-of-Scope\n---\n\n  * Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n  * UUID enumeration of any kind.\n  * Invite/Promo code enumeration.\n  * Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n  * Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n  * Reports that state that software is out of date/vulnerable without a proof-of-concept.\n  * Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores.\n  * Stack traces, path disclosure, and directory listings.\n  * CSV injection.\n  * Best practices concerns.\n  * Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n  * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n  * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n  * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n  * Distributed denial of service attacks (DDOS).\n  * Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n  * Content injection issues.\n  * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n  * Missing cookie flags on non-authentication cookies.\n  * Issues that require physical access to a victim’s computer/device.\n  * SSL/TLS scan reports (this means output from sites such as SSL Labs).\n  * Banner grabbing issues (figuring out what web server we use, etc.).\n  * Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n  * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n  \n**Out-of-scope domains**\n\n\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n  * `*.et.uber.com`\n\n---\n##Rights and Licenses\n---\n\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.  \n\nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.  \n\nBy making a Submission, you give us the right to use your Submission for any purpose.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-26T10:27:57.626Z"},{"id":3573986,"new_policy":" The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n \n Bounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n \n In the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n \n Besides our scope, it’s worth mentioning a few tenets of our program:\n * We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n * You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n \n ---\n ## Security Impact Buckets\n ---\n \n **Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n * in-scope vulnerability class examples:\n   * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n   * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n   * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n   * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n \n * out-of-scope vulnerability class examples:\n  * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n * potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n \n ---\n \n **Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n * in-scope vulnerability class examples:\n   * XSS in domain with authenticated experience allowing forgery of requests.\n   * CSRF, with non-negligible security impact, in domain with authenticated experience.\n   * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n   * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n \n * out-of-scope vulnerability class examples:\n   * XSS or CSRF in a domain without an authenticated experience.\n   * Credential re-usage from public dumps.\n * potential domains  to look at:\n   * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n \n ---\n \n **Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n * in-scope vulnerability class examples:\n   * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n   * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n   * Disclosure of proprietary source code.\n * out-of-scope vulnerability class examples:\n   * Signing up with multiple accounts to abuse invite/promo code usage.\n   * Invite/Promo code enumeration or collection.\n * potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n \n ---\n \n **Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n * in-scope vulnerability class examples:\n   * HTML injection on www.uber.com allowing for convincing phishing.\n   * XSS in an unauthenticated domain like www.uber.com\n * out-of-scope vulnerability class examples:\n   * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n   * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n * potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n \n ---\n \n **Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n * in-scope vulnerability class examples:\n   * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n   * Ability to update driver image/documents without review from Uber.\n * potential domains  to look at: partners.uber.com, riders.uber.com\n \n ---\n ## Calculating Security Impact\n ---\n \n Understanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n \n ### Multiplying Factors\n \n * **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n * **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n * **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n * **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n \n ### Mitigating Factors\n * **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n * **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n * **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n * **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n * **physical access** -- exploit scenarios requiring physical access to a device.\n * **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n * **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n * **social engineering** -- when an exploit requires social engineering a person to be successful.\n * **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n * **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n \n See our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n \n ---\n ## Report States\n ---\n \n We strive to be consistent with how we close reports and below are the details for each state:\n * **spam** -- a report with no useful information\n * **needs more info** -- not enough actionable information in report to triage\n * **not applicable** -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n * **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n * **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n * **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n * **resolved** -- a verified vulnerability that has been fixed\n \n ---\n ## Bounty Amounts\n ---\n \n Previous bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n \n We focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n \n We recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n \n The general process for determining bounty:\n * Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n * Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n * Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n * Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n * With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n \n The bounty ranges for the different security impact buckets:\n * **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n * **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n * **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n * **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n * **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n \n ---\n ## Report Quality\n ---\n \n High quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n * Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n * Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n * Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n * In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n \n ---\n ## Program Policies\n ---\n \n * If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n * Video only PoCs will not be considered.\n * Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n * Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n * A vulnerability must be reproducible for us to be considered in-scope.\n * Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n * Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n \n ---\n ## Out-of-Scope\n ---\n \n * Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n * UUID enumeration of any kind.\n * invite/Promo code enumeration.\n * account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n * Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n * Reports that state that software is out of date/vulnerable without a proof of concept.\n-* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n+* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores.\n * Stack traces, path disclosure, and directory listings.\n * CSV injection.\n * Best practices concerns.\n * Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n * Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n * Distributed denial of service attacks (DDOS).\n * Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n * Content injection issues.\n * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n * Missing cookie flags on non-authentication cookies.\n * Issues that require physical access to a victim’s computer/device.\n * SSL/TLS scan reports (this means output from sites such as SSL Labs).\n * Banner grabbing issues (figuring out what web server we use, etc.).\n * Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n * Out-of-scope domains\n   * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n   * `uber.onelogin.com`\n     * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n   * `bizblog.uber.com`\n   * `newsroom.uber.com`\n   * `love.uber.com`\n   * `drive.uber.com`\n   * `eng.uber.com`\n   * `people.uber.com`\n   * `*.et.uber.com`\n \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-16T23:13:40.503Z"},{"id":3573985,"new_policy":"---\n##Uber Bug Bounty Program Terms\n--- \nThe scope for Uber’s Bug Bounty Program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.  \nYour participation in our Bug Bounty Program is voluntary.  By submitting a report or otherwise disclosing a vulnerability to us (making a “Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).  \n\n**Ground Rules**\n  * Research and disclose in good faith.\n  * Respect our users’ privacy.  \n  * Don’t extort us. \n  * Don’t leave any system in a more vulnerable state than you found it.\n  * Don’t publicly disclose a vulnerability without our consent.\n  * Be respectful when interacting with our team, and our team will do the same.\n\n---\n##Good Faith Vulnerability Research and Disclosure\n---\nYou must act in good faith when investigating and reporting vulnerabilities to us.  Acting in good faith means that you will:\n\n1. **Play by the rules.**  This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains.  If there is any inconsistency between the these Program Terms and any of Uber’s other terms, these Program Terms will control.  \n\n2. **Respect our users’ privacy.**  You should only interact with Uber accounts you own or with explicit permission from the account holder.  Additionally, you should only access the minimum data necessary to identify and report a vulnerability.  If you encounter information about our users, including personal or sensitive data, you must:\n  * Report this immediately to our Bug Bounty team.\n  * Only view and copy user information to the extent required to identify and report the vulnerability.\n  * Not proceed with any further access, acquisition, copying, storage, sharing, transferring, using, or retaining of such information.\n  * Never use or disclose user information for any reason other than to test and disclose a vulnerability to our Bug Bounty team.\n  * Work with us to ensure that we are able to secure all user information and engage in effective mitigation efforts.\n\n3. **Don’t extort us.**  You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests.    \n\n4. **Don’t cause more harm than good.**  You should never leave a system or users in a more vulnerable state than when you found them.  This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam. \n\nIf you have made a good faith effort to abide by these Program Terms, we will not initiate or recommend legal action against you, and we will take reasonable steps to make known that your activities were conducted pursuant to the Bug Bounty Program.\n\nFailure to act in good faith will result in immediate disqualification from the Bug Bounty Program and ineligibility for receiving any benefit of the Bug Bounty Program.  \n\nIf at any point while researching a vulnerability, you are unsure whether you should continue, immediately engage with our Bug Bounty team.\n\n---\n## Eligibility to Participate\n---\nTo be eligible to participate in our Bug Bounty Program, you must:\n  * Have a signal of at least 1.0 or written permission from Uber’s Bug Bounty Team.\n  * Be at least 18 years of age if you test using an Uber account.\n  * Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.\n  * Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n  * Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n  * Not be using duplicate HackerOne accounts.\n\nIf (i) you do not meet the eligibility requirements above; (ii) you breach any of these Program Terms or any other agreements you have with Uber or its affiliates; or (iii) we determine that your participation in the Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole discretion, may remove you from the Bug Bounty Program and disqualify you from receiving any benefit of the Bug Bounty Program. \n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n##Submissions and Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).\n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.\n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n* Video only PoCs will not be considered.\n* A vulnerability must be verifiable and reproducible for us to be considered in-scope.  \n\n---\n##Confidentiality\n---\n\nAny information you receive or collect about us, our affiliates or any of our users, employees or agents in connection with the Bug Bounty Program (“Confidential Information”) must be kept confidential and only used in connection with the Bug Bounty Program. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your submission, without our prior written consent.  You must get written consent by submitting a disclosure request through the HackerOne platform.\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. \n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.\n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\nBounty payouts and amount, if any, will be determined by us in our sole discretion. In no event are we obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by us in our sole discretion. You are solely responsible for any tax implications related to any bounty payouts you may receive.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.\n\n---\n## Out-of-Scope\n---\n\n* Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores.\n* Stack traces, path disclosure, and directory listings.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n  * `*.et.uber.com`\n\n---\n##Rights and Licenses\n---\n\nWe may modify the Program Terms or cancel the Bug Bounty Program at any time.  \nBy making a Submission, you represent and warrant that the Submission is original to you and you have the right to submit the Submission.  \nBy making a Submission, you give us the right to use your Submission for any purpose.\n \n \n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-16T23:03:49.798Z"},{"id":3566513,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\n## Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\n## Program Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\n## Out-of-Scope\n---\n\n* Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores.\n* Stack traces, path disclosure, and directory listings.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n  * `*.et.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-01-10T20:45:59.367Z"},{"id":3566223,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\n## Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\n## Program Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\n## Out-of-Scope\n---\n\n* Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces, path disclosure, and directory listings.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n  * `*.et.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-01-05T19:52:09.000Z"},{"id":3560288,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\n## Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\n## Program Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\n## Out-of-Scope\n---\n\n* Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n  * `*.et.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-09-11T17:54:26.217Z"},{"id":3559685,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\n## Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\n## Program Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\n## Out-of-Scope\n---\n\n* Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n  * `*.et.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-28T18:50:36.009Z"},{"id":3559198,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n## Report States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n## Bounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\n## Report Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\n## Program Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\n## Out-of-Scope\n---\n\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:34:26.329Z"},{"id":3559197,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\nOut-of-Scope\n---\n\nThis section describes the things we consider out-of-scope:\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:32:51.243Z"},{"id":3559196,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\nOut-of-Scope\n---\n\n\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:32:16.127Z"},{"id":3559195,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent [blog post](https://medium.com/@ubersecurity/uber-bug-bounty-treasure-map-17192af85c1a) on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\nOut-of-Scope\n---\n\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:31:39.794Z"},{"id":3559194,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\nOut-of-Scope\n---\n\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:30:42.775Z"},{"id":3559193,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS [Identity \u0026 Access Management](https://aws.amazon.com/iam) credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the Bug Bounty Program Terms.\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\nOut-of-Scope\n---\n\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:29:40.132Z"},{"id":3559192,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the Bug Bounty Program Terms.\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\nOut-of-Scope\n---\n\n* UUID enumeration of any kind.\n* invite/Promo code enumeration.\n* account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.\n* Stack traces or path disclosure.\n* CSV injection.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.\n* Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Distributed denial of service attacks (DDOS).\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing cookie flags on non-authentication cookies.\n* Issues that require physical access to a victim’s computer/device.\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n* Out-of-scope domains\n  * `*.uber.com.cn` domains or any other properties relating to Uber in China, since they belong to Didi Chuxing\n  * `uber.onelogin.com`\n    * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n  * `bizblog.uber.com`\n  * `newsroom.uber.com`\n  * `love.uber.com`\n  * `drive.uber.com`\n  * `eng.uber.com`\n  * `people.uber.com`\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:26:57.392Z"},{"id":3559191,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\nProgram Policies\n---\n\n* If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. \n* Video only PoCs will not be considered.\n* Using duplicate HackerOne accounts is against our policy and can result in a program ban.\n* Currently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n* A vulnerability must be reproducible for us to be considered in-scope.\n* Your participation in the Bug Bounty Program is voluntary and subject to the Bug Bounty Program Terms.\n* Please follow the Terms \u0026 Conditions of all of our in-scope domains.\n\n---\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:23:38.979Z"},{"id":3559190,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\nHigh quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.\n* Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.\n* Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible). \n* Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact. \n* In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.\n\n---\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:22:32.708Z"},{"id":3559189,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\nBounty Amounts\n---\n\nPrevious bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.\n\nWe focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors. \n\nWe recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. To accomplish both of these needs, we have a hybrid model where we payout our minimum bounty at time of triage and then full bounty at resolution once we completely understand security impact.\n\nThe general process for determining bounty:\n* Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”\n* Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”\n* Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”\n* Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”\n* With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.\n\nThe bounty ranges for the different security impact buckets:\n* **Exposure of User Data** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Unauthorized Requests on Behalf of User/Employee** -- the payout ranges for this bucket range from $0 to $10,000.\n* **Monetary Impact** -- the payout ranges for this bucket range from $0 to $10,000\n* **Phishing** -- the payout ranges for this bucket range from $0 to $5,000\n* **Safety**  -- the payout ranges for this bucket range from $0 to $10,000\n\n---\nReport Quality\n---\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:21:40.172Z"},{"id":3559188,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\nReport States\n---\n\nWe strive to be consistent with how we close reports and below are the details for each state:\n* **spam** -- a report with no useful information\n* **needs more info** -- not enough actionable information in report to triage\n* **not applicable** -- no reproducible security vulnerability\n* **duplicate** -- a vulnerability that has previously been found either internally or via Hackerone\n* **informative** -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us) \n* **triaged** -- either a valid report or a report that needs more investigation from an internal team, typically the former\n* **resolved** -- a verified vulnerability that has been fixed\n\n---\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:19:35.542Z"},{"id":3559187,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n\n---\n## Calculating Security Impact\n---\n\nUnderstanding security impact of a given report is understanding which security buckets it lands in, understanding the scale of exposure in each of those situations, understanding what mitigating factors exist, and finally understanding what multiplying factors exist. Below are some categories to consider when assessing security impact.\n\n### Multiplying Factors\n\n* **sensitivity of user data exposed** -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.\n* **scale of exposure** -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.\n* **severity of forged actions** -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.\n* **forge communication from Uber** -- when a vulnerability allows an Attacker to send communication (and control the content)  to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.\n\n### Mitigating Factors\n* **requires user interaction** -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.\n* **authorized relationship** -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.\n* **requires brute forcing** -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.\n* **existence of rate limiting** -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.\n* **physical access** -- exploit scenarios requiring physical access to a device.\n* **noticeable to victim** -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.\n* **account put into arrears or banned** -- when an exploit then puts the Attacker’s account into arrears or results in a ban.\n* **social engineering** -- when an exploit requires social engineering a person to be successful.\n* **requires privileged network position** -- when an exploit (often times MiTM) requires having privileged network position to be successful\n* **requires multiple accounts** -- when an exploit requires the ability to mint new accounts indefinitely.\n\nSee our recent blog post on Treasure Map 2.0 for some specific examples on determining security impact of a given report.\n\n---\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:18:10.369Z"},{"id":3559186,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n---\n## Security Impact Buckets\n---\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:14:49.102Z"},{"id":3559185,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n## Security Impact Buckets\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n\n---\n\n**Monetary Impact:** the ability to cause monetary impact to Uber or Uber users through a technical vulnerability.\n* in-scope vulnerability class examples:\n  * IDOR/authorization issue allowing an Attacker the ability to provide false payment profile resulting in ride not being charged to account and account not going into arrears -- essentially the ability to take free rides indefinitely with little to no chance of discovery.\n  * The ability to take drivers offline in a city/region en masse, resulting in service disruption.\n  * Disclosure of proprietary source code.\n* out-of-scope vulnerability class examples:\n  * Signing up with multiple accounts to abuse invite/promo code usage.\n  * Invite/Promo code enumeration or collection.\n* potential domains  to look at: partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com\n\n---\n\n**Phishing:** (almost all examples of Phishing end up out-of-scope) the ability to carry out targeted and convincing phishing on Uber users.\n* in-scope vulnerability class examples:\n  * HTML injection on www.uber.com allowing for convincing phishing.\n  * XSS in an unauthenticated domain like www.uber.com\n* out-of-scope vulnerability class examples:\n  * Reports that do not demonstrate a technical vulnerability, like spear phishing. \n  * Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).\n* potential domains  to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com \n\n---\n\n**Safety:** the ability to bypass physical safety controls through a technical vulnerability -- the key aspect of these reports is that there exists a technical vulnerability in our services.\n* in-scope vulnerability class examples:\n  * Trip rate IDOR authorization issue that allows a Driver to increase their rating.\n  * Ability to update driver image/documents without review from Uber.\n* potential domains  to look at: partners.uber.com, riders.uber.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:14:16.533Z"},{"id":3559184,"new_policy":"The scope for Uber’s bug bounty program is focused on securing the data of our users. Therefore, our approach is to evaluate any given report based on the specific security impact for users (versus domain + vulnerability class). Below we describe the various security impact buckets that are in-scope, examples of vulnerability types, and domains that could potentially have meaningful security impact.\n\nBounty awards are not additive and are subject to change as our internal environment evolves. We determine the upper bound for security impact and award based on that impact. Prior bounty amounts awarded are not precedent for future payments.\n\nIn the same way that software is constantly changing, so will our program’s scope in an effort to accurately represent the state of our services at that point in time.\n\nBesides our scope, it’s worth mentioning a few tenets of our program:\n* We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.\n* You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.\n\n## Security Impact Buckets\n\n**Exposure of User Data:** the ability to access user or employee data without having an authorized relationship from the Victim.\n* in-scope vulnerability class examples:\n  * AWS Identity \u0026 Access Management credential exposure resulting in access to driver documents in an S3 bucket.\n  * Adding a user to a Partner’s account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.\n  * Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.\n  * IDOR/authorization vulnerabilities resulting in exposure of personal data.\n\n* out-of-scope vulnerability class examples:\n * The ability to determine if a phone number or email has an Uber account, also known as an account oracle.\n* potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com\n\n---\n\n**Unauthorized Requests on Behalf of User/Employee:** the ability to forge authenticated requests on the behalf of a Victim.\n* in-scope vulnerability class examples:\n  * XSS in domain with authenticated experience allowing forgery of requests.\n  * CSRF, with non-negligible security impact, in domain with authenticated experience.\n  * Password reset token exposed, allowing Attacker ability to reset password of victim and login to make state changing requests.\n  * IDOR/authorization vulnerabilities allowing Attacker to make state changing actions on behalf of a Victim.\n\n* out-of-scope vulnerability class examples:\n  * XSS or CSRF in a domain without an authenticated experience.\n  * Credential re-usage from public dumps.\n* potential domains  to look at:\n  * partners.uber.com, riders.uber.com, eats.uber.com, business.uber.com, rush.uber.com, auth.uber.com, login.uber.com, developer.uber.com, central.uber.com\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-08-16T08:11:43.318Z"},{"id":3558020,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* m.uber.com\n* partners.uber.com\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* vulnerability reports with video only PoCs\n* Invite/Promo code enumeration.\n* Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* bizblog.uber.com\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n## Trial Reports\nCurrently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n\n## Duplicate Accounts\nUsing duplicate accounts is against our policy and can result in a program ban.\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-07-20T21:17:25.831Z"},{"id":3558019,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* m.uber.com\n* partners.uber.com\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* vulnerability reports with video only PoCs\n  * please don't send us videos\n* Invite/Promo code enumeration.\n* Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* bizblog.uber.com\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n## Trial Reports\nCurrently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n\n## Duplicate Accounts\nUsing duplicate accounts is against our policy and can result in a program ban.\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-07-20T21:16:46.422Z"},{"id":3555162,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Invite/Promo code enumeration.\n* Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* bizblog.uber.com\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n## Trial Reports\nCurrently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n\n## Duplicate Accounts\nUsing duplicate accounts is against our policy and can result in a program ban.\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-06-06T15:46:37.084Z"},{"id":3555083,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* bizblog.uber.com\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n## Trial Reports\nCurrently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n\n## Duplicate Accounts\nUsing duplicate accounts is against our policy and can result in a program ban.\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-06-05T19:48:21.417Z"},{"id":3554540,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* bizblog.uber.com\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n## Trial Reports\nCurrently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n\n## Duplicate Accounts\nUsing duplicate accounts is against our policy and can result in a program ban.\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-05-28T22:18:11.578Z"},{"id":3549018,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* bizblog.uber.com\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n## Trial Reports\nCurrently, our program has zero trial reports for researchers with a signal of 1.0 or less. \n\n## Duplicate Accounts\nUsing duplicate accounts is against our policy and can result in a program ban.\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-03-14T22:26:00.474Z"},{"id":3545658,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* newsroom.uber.com\n* love.uber.com\n* drive.uber.com\n* eng.uber.com\n* people.uber.com\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-01-25T23:42:59.758Z"},{"id":3545071,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* \\*.uber.com.cn\n  * or any other properties relating to Uber in China, since they belong to Didi Chuxing\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-01-16T22:07:20.612Z"},{"id":3543354,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* lert.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-12-16T21:27:30.336Z"},{"id":3437120,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* dial.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-08-18T18:49:51.466Z"},{"id":3349960,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* brand.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-08-10T21:24:39.303Z"},{"id":3337743,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-08-10T00:30:41.010Z"},{"id":3337716,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* api.uber.com\n* bonjour.uber.com\n* business.uber.com\n* cn-cfe1.uber.com\n* cn-dc1.uber.com\n* cn-dc2.uber.com\n* cn-dc3.uber.com\n* cn-dca1.uber.com\n* cn-geo1.uber.com\n* cn-pek1.uber.com\n* cn-pr.uber.com\n* cn-sjc1.uber.com\n* cn-slow1.uber.com\n* cn-slow2.uber.com\n* cn-slow3.uber.com\n* cn-spdy.uber.com\n* cn-tt1.uber.com\n* cn.uber.com\n* cn1.uber.com\n* cnfrontend-dca1.uber.com\n* cnfrontend-sjc1.uber.com\n* cnfrontend.uber.com\n* csp.uber.com\n* developer.uber.com\n* eats.uber.com\n* get.uber.com\n* getrush.uber.com\n* help.uber.com\n* login.uber.com\n* m.uber.com\n* partners.uber.com\n* petition.uber.org\n* riders.uber.com\n* rush.uber.com\n* sftp.uber.com\n* sms.uber.com\n* track.uber.com\n* trip.uber.com\n* ubereats.com\n* ubermovement.com\n* \\*.uberinternal.com\n* vault.uber.com\n* www.uber.com\n* Android/iPhone Partner App\n* Android/iPhone Rider App\n* Android/iPhone Eats App\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* uber.onelogin.com\n  * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilties in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-08-10T00:25:03.628Z"},{"id":3087412,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* \\*.uber.com\n* \\*.uberinternal.com\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilties in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## Policy Changes\nYou can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions).\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-07-18T17:40:41.888Z"},{"id":3054542,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* \\*.uber.com\n* \\*.uberinternal.com\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* Host header issues without an accompanying proof-of-concept demonstrating vulnerability.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* \\*.dev.uber.com\n* \\*.dev.uberinternal.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilties in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## GitHub repo\nThis page is hosted in a [GitHub repo](https://github.com/uber/Bug-Bounty-Page). Check the repo for any recent rule changes.\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-07-13T17:35:21.903Z"},{"id":3054462,"new_policy":"# Scope\n\nWe are interested in any vulnerability that could negatively affect the security of our users.\n\n## In-Scope Vulnerability Classes\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n## In-Scope Properties\n* \\*.uber.com\n* \\*.uberinternal.com\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n## Out-of-scope Vulnerability Classes\n* Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.\n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control.\n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues that affect only outdated browsers.\n* Stack traces that disclose information.\n* CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n* Submissions on the S3 bucket `uber`, **We do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.\n* Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.\n* Denial of Service Attacks.\n* Reflected File Download (RFD).\n* `window.opener`-related issues.\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees).\n* Content injection issues.\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes.\n* Missing cookie flags on non-security-sensitive cookies.\n* Issues that require physical access to a victim’s computer.\n* Missing security headers that do not present an immediate security vulnerability.\n* Fraud issues (please see the below section elaborating on this).\n* SSL/TLS scan reports (this means output from sites such as SSL Labs).\n* Banner grabbing issues (figuring out what web server we use, etc.).\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability.\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n## Out-of-scope Properties\n* \\*.dev.uber.com\n* \\*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over.\n* uber-finder.com - this is not software owned by Uber Engineering.\n\n# Rewards\n\nOur rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We don't want to encourage people spamming us with vague issues in an attempt to be first.\n\nIf a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability.  For example, if you find 3 vulnerabilties in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact.\n\nThe payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges.\n\nAt the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues.\n\n## Things you should expect to receive little to no bounty for\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n## Bounty Payout Range\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\n# Miscellany\n\n## Reporting Guidelines\nWe need detailed written steps to reproduce. We do not accept reports that include only a video.\n\n## GitHub repo\nThis page is hosted in a [GitHub repo](https://github.com/uber/Bug-Bounty-Page). Check the repo for any recent rule changes.\n\n## Fraud issues\nIf you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\n## Examples of good bugs\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n# Frequently Asked Questions\n\n## Can I blog about my bug?\nYes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue.\n\n## What is your policy on chaining bugs and privilege escalation?\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\n## Do you provide test accounts?\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.\n\n## What is a user UUID and when do you reward for enumeration of it?\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\n## What is a vehicle UUID and when do you reward for enumeration of it?\nA vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances.\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\n\n## What about public disclosure?\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\n## What is an Uber microsite?\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\n## Are Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n# Program terms\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-07-13T17:22:59.813Z"},{"id":2975525,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Submissions on the S3 bucket `uber`, **we do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n* https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/\n\n-----\n*Psst, this is a [Github repo! Wondering if there was a recent rule change? Click here!](https://github.com/uber/Bug-Bounty-Page)*\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-06-27T16:59:53.612Z"},{"id":2888314,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Submissions on the S3 bucket `uber`, **we do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n* Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n\n-----\n*Psst, this is a [Github repo! Wondering if there was a recent rule change? Click here!](https://github.com/uber/Bug-Bounty-Page)*\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-06-10T20:41:24.958Z"},{"id":2870588,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Submissions on the S3 bucket `uber`, **we do not own this bucket!**.\n* Best practices concerns.\n* Highly speculative reports about theoretical damage. Be concrete.\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n\n-----\n*Psst, this is a [Github repo! Wondering if there was a recent rule change? Click here!](https://github.com/uber/Bug-Bounty-Page)*\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-06-06T15:36:14.978Z"},{"id":2744751,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two week before reporting these types of issues.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n\n-----\n*Psst, this is a [Github repo! Wondering if there was a recent rule change? Click here!](https://github.com/uber/Bug-Bounty-Page)*\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-05-11T17:59:54.342Z"},{"id":2726197,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us one week before reporting these types of issues.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n\n-----\n*Psst, this is a [Github repo! Wondering if there was a recent rule change? Click here!](https://github.com/uber/Bug-Bounty-Page)*\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-05-06T23:44:22.847Z"},{"id":2584878,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us one week before reporting these types of issues.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-05-02T23:44:50.765Z"},{"id":2584875,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n* Recently public 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us one week before reporting these types of issues.\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-05-02T23:44:17.046Z"},{"id":2568728,"new_policy":"Program Update April 28 2016 \n==\nPayouts Clarification\n\nThere has been some confusion around the way we do rewarding in our bug bounty program. Our rewards are solely impact based, meaning that we look at what can be done with a bug and reward based on the impact to both the business and our customers.\n\nTo clarify, we want to explain some of the logic behind “impact.” For example, we rank vulnerabilities in our production data center much higher than vulnerabilities in third-party services because a real-world attacker could do much more damage in our production data center than with control over one of our WordPress blogs hosted on WP Engine. The former could compromise customer information, while the latter essentially allows defacement of an Uber branded website—no personal information is stored there.\n\nWhen we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly.\n\nWe’d also like to clarify how we handle payout in the case of multiple vulnerability reports in a single component of our systems. For our WordPress blogs, for example, we often get reports that list many vulnerabilities in a single plugin. These submissions are unique because, despite the component having multiple vulnerabilities, the fix is the same: remove the vulnerable plugin. In these situations, we opt to reward a bounty for the highest risk issue submitted instead of paying each issue out individually. The reasoning for this is due to the possibility of receiving a submission on a WordPress plugin with 30 separate cross-site scripting (XSS) vulnerabilities. It doesn’t make sense to pay out tens of thousands of dollars when the remediation is just removing the poorly designed plugin. For fairness, we bump up payouts for these submissions if the researchers put extra effort into finding these issues. We handle this determination case by case.\n\nAt the end of the day, rewarding is done at our discretion. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and even generous. We will adapt as the program continues.\n\n\nProgram update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, our blogs and city-specific Uber sites) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the our core services, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n* http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html\n* http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-28T18:25:55.731Z"},{"id":2559836,"new_policy":"Program update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-26T22:15:28.486Z"},{"id":2496661,"new_policy":"Program update April 14 2016\n==\n\n* Removed \"rate limiting\" from Medium issues description. It is always at our discretion how much to reward an issue and we do so based on the impact to ubers customers, data, code and employees. Our motivation is to reward as much as possible for great issues. That said the payout ranges below are intended as rough guidance on how we categorize issues, not a strict rubric.\n\nProgram update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-15T00:39:22.514Z"},{"id":2496636,"new_policy":"Program update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-15T00:20:35.782Z"},{"id":2480977,"new_policy":"Program update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-11T23:07:29.047Z"},{"id":2480850,"new_policy":"Program update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-11T22:31:14.054Z"},{"id":2480616,"new_policy":"Program update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\nN.B: the amounts listed here are the maximum we can pay for these categories of issues. \n\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-11T21:51:08.625Z"},{"id":2480606,"new_policy":"Program update April 11 2016\n==\nThank you everyone for the outpouring of attention, effort, and bugs. \n\nOur public bug bounty has been live for a few weeks now and we have been impressed with the great reports we have seen. We are adjusting our scope based on what we have learned to best encourage research on the areas most likely to be rewarded\n\n\nNo longer in scope as of 4/11/2016\n====\n* *.dev.uber.com\n* Open redirects - 99% of open redirect issues have low security impact. For the rare cases, like stealing oauth tokens, we do still want to hear about them\n* *.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. They have requested to be removed. \n* Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. \n* Reports that state that software is out of date/vulnerable without a proof of concept.\n* XSS issues in non-current browsers. \n* Stack traces disclosing information\n* “CSV injection” - see: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection\n* Uber-finder.com - this is not software owned by Uber engineering. \n\nNow in scope as of 4/11/2016\n===\n* *.uberinternal.com - anything here is internal software used by Uber the company. We may not be able to fix flaws found here as quickly as we are beholden to other companies\n* Bulk vehicle uuid enumeration - any instance where you could collect a lot of vehicle uuids is interesting to us based on the circumstances. \n\nTo get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console:\n```js\nvuids = document.querySelectorAll( \"#vehicle-uuid\" );for( var i = 0;i\u003cvuids.length;i++){console.log( vuids[i].value )};\n```\nGenerally speaking, any request which allows you to enumerate bulk vehicle UUIDs for accounts is considered an issue we are concerned about.\n\nThese changes go into effect today but any issues submitted before then will be evaluated against the old program scope. \n\nHow are payouts done for dupes?\n===\nIf we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue. We dont want to encourage people spamming us with vague issues in an attempt to be first. \n\n\n\nWant to blog about your bug?\n===\nWe have received questions about blog posts about bugs. To be clear, we love it! We just ask that you wait until the issue is both fixed and paid out before you publish the blog. We also prefer that you request disclosure through hacker1 for an issue as full background for anyone reading your blog post. Any questions around this just let us know and we would be happy to help out.\n\nPayouts\n====\nIt is important to mention the payout ranges on this page are guidelines to express roughly how we think about the severity of families of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. So far we have most commonly rewarded on the top end of the ranges. \n\nAccepted report requirements\n====\nWe no longer accept reports with only a video, but need detailed written repro steps\n\nProgram terms\n===\nYour participation in the Bug Bounty Program is voluntary and subject to the [Bug Bounty Program Terms](https://www.uber.com/legal/other/bug-bounty-program-terms/).\n\n\nWhat type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n* Open Redirect Vulnerabilities\n* Publicly accessible login panels\n\n\nThings you should expect to recieve low to no bounty for\n==\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-04-11T21:46:08.544Z"},{"id":2404429,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nThe following are  vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Best practices concerns. \n* Highly speculative reports about theoretical damage. Be concrete. \n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n\nExamples of good bugs\n==\n\n* https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-24T06:39:52.425Z"},{"id":2404428,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences, shouldn't contain much or any user data and aren’t part of the uber.com domain space, the impact of issues on these sites is significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services will not be rewarded for except in extraordinary circumstances. Generally there are [better areas](https://eng.uber.com/bug-bounty/) to spend your time than microsites.\n\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-24T06:35:51.564Z"},{"id":2403810,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-24T01:48:39.525Z"},{"id":2401483,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is a user UUID and when do you reward for enumeration of it?\n===\nWe reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console:\n```js\nalert(JSON.parse($(\"#web-support-data-script\").text).user.uuid);\n```\n(We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users).\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-24T00:19:17.851Z"},{"id":2398789,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels that don't require login credentials\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n* Open ports without an accompanying proof-of-concept demonstrating vulnerability\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T22:17:19.372Z"},{"id":2398667,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T21:52:19.466Z"},{"id":2398539,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n* Publicly accessible login panels\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T21:30:40.598Z"},{"id":2397145,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n* Banner grabbing issues (figuring out what web server we use, etc)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T17:56:24.140Z"},{"id":2396168,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe. Since we are primary interested in vulnerabilities which could lead to the exfiltration of customer information, vulnerabilities in microsite services may not be rewarded for except in extraordinary circumstances.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T16:04:41.878Z"},{"id":2396138,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Fraud issues (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts.  Whenever possible only test against yourself, never other users. If there is every a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. \n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nFraud related issues. \n===\nIf you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software.  Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T15:51:22.642Z"},{"id":2393671,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com. Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T03:30:08.015Z"},{"id":2393665,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nDo you provide test accounts?\n===\nAs of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-23T03:26:38.512Z"},{"id":2392881,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issues\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-22T23:03:05.858Z"},{"id":2392876,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Content injection issue.\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-22T23:02:37.002Z"},{"id":2390825,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-22T17:43:50.397Z"},{"id":2389943,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud-group@uber.com`. We currently do not reward for fraud issues. \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-22T15:34:54.513Z"},{"id":2389650,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nBounty Payout Range\n===\n* **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor).\n\n* **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc.\n\n* **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, rate limiting issues, account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID).\n\n* **Fraud Issues** - Send these to `ext-uber-fraud-group@uber.com`. We currently do not reward for fraud issues. \n\nExample Report\n-----------------------\n*Title:* Cross-site Scripting (XSS) in ubermovement.com\n\n*Description:*\nThe website located at http://ubermovement.com suffers from a reflected Cross-site Scripting (XSS) vulnerability.\n\n*Reproduction Steps:*\n\n* Open the latest Firefox web browser\n\n* Navigate to the following URL:\n`http://ubermovement.com/search?query=\u003cscript\u003ealert(“Hi Uber!”)\u003c/script\u003e`\n\n* Note that the XSS payload has fired.\n\nI’ve tested this in the latest Firefox and Chrome, however it does not work in the latest Internet Explorer. Attached to this report are screenshots of this issue occurring in Firefox.\n\n---\n\nThe above report is an example of an ideal report. It is clear with reproduction steps that a developer would have no trouble understanding. Note that remediation steps are not provided, nor are links to the relevant OWASP pages. Unless specifically requested by the Uber security team these recommendations are unnecessary and will be added upon the bug being created internally.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-22T15:00:13.395Z"},{"id":2389648,"new_policy":"What type of vulnerabilities is Uber looking for?\n===\nAt Uber we are looking for any vulnerability which could negatively affect the security of our users. The main categories of vulnerabilities that we look for are the following:\n\n* Cross-site Scripting (XSS)\n* Cross-site Request Forgery\n* Server-Side Request Forgery (SSRF)\n* SQL Injection\n* Server-side Remote Code Execution (RCE)\n* XML External Entity Attacks (XXE)\n* Open Redirect Vulnerabilities\n* Access Control Issues (Insecure Direct Object Reference issues, etc)\n* Full Path Disclosure\n* Exposed Administrative Panels and Ports (Excluding OneLogin)\n* Directory Traversal Issues\n* Local File Disclosure (LFD)\n* Information Disclosure of Sensitive Information (such as system configurations, user data, etc)\n\nPlease note that if a vulnerability (such as XSS) only affects a small population, e.g. a browser with a low usage percentage, the reward will be determined accordingly. Vulnerabilities that exist only in antiquated browsers such as Internet Explorer 8 for example, are not in scope.\n\nWhat type of vulnerabilities is Uber NOT looking for?\n===\nIn general, vulnerabilities which are considered to be “best practice suggestions” are not in scope for this program. The following is a short list of some vulnerabilities which Uber does not consider severe enough for a reward:\n\n* Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console)\n* Denial of Service Attacks\n* Reflected File Download (RFD)\n* `window.opener` Related Issues\n* Physical or social engineering attempts (this includes phishing attacks against Uber employees)\n* Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc)\n* Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)\n* Missing autocomplete attributes\n* Missing cookie flags on non-security sensitive cookies\n* Issues which require physical access to a victim’s computer\n* Missing security headers which do not present an immediate security vulnerability\n* Promo code fraud (please see the below section elaborating on this)\n* SSL/TLS scan reports (this means output from sites such as SSL Labs)\n\nWhat is your policy on chaining bugs and privilege escalation?\n===\nChaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool.\n\nWhat is in scope for this program?\n===\n* https://*.uber.com/\n* https://*.dev.uber.com/\n* http://petition.uber.org\n* http://ubermovement.com\n* iPhone Rider Application\n* iPhone Partner Application\n* Android Rider Application\n* Android Partner Application\n\n*_In addition to the above sites in certain situations some microsites may also be in scope. For more information on microsites at Uber please see the relevant sections below._\n\n*_Please note that *.dev.uber.com servers don’t contain production data and thus vulnerabilities in these hosts may result in lower payouts._\n\nWhat about public disclosure?\n===\nFound a particularly interesting or clever bug in an Uber service? We’re more than happy to publicly disclose your bug once it has been remediated by our developers. Please note that in certain situations we may request more time to investigate an issue internally to ensure that it is properly fixed across all Uber services. Public disclosure before Uber has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.\n\nWhat is an Uber microsite?\n===\nAn Uber microsite is a website which is not explicitly listed in the scope above but is made by an Uber employee and owned by Uber. The most common examples of microsites include Uber city sites, blogs, and partner incentive sites.\n\nAre Uber microsites (for example, city-specific Uber sites and blogs) in scope?\n===\nMicrosites are an important part of how Uber reaches people in diverse local markets all around the world. Since they have smaller audiences and aren’t part of the uber.com domain space, the impact of issues on these sites can be significantly less severe.\n\nOur top priority is the protection of our customers, so we’ll pay a bounty for reports of issues on Uber-owned properties that pose a meaningful security risk, provided the research is conducted in accordance with our program terms. We’ll use our discretion in deciding whether to pay, and how much to pay, for issues on microsites. Payments may be reduced for lower-impact issues, in comparison to payments for issues at one of the listed in-scope properties.\n\n\nWhat is promo code/give-get fraud and why don’t you reward for it?\n===\nPromo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. If you’d like to report an issue with our fraud, please contact ext-uber-fraud@uber.com.\n\nExample Report\n-----------------------\n*Title:* Cross-site Scripting (XSS) in ubermovement.com\n\n*Description:*\nThe website located at http://ubermovement.com suffers from a reflected Cross-site Scripting (XSS) vulnerability.\n\n*Reproduction Steps:*\n\n* Open the latest Firefox web browser\n\n* Navigate to the following URL:\n`http://ubermovement.com/search?query=\u003cscript\u003ealert(“Hi Uber!”)\u003c/script\u003e`\n\n* Note that the XSS payload has fired.\n\nI’ve tested this in the latest Firefox and Chrome, however it does not work in the latest Internet Explorer. Attached to this report are screenshots of this issue occurring in Firefox.\n\n---\n\nThe above report is an example of an ideal report. It is clear with reproduction steps that a developer would have no trouble understanding. Note that remediation steps are not provided, nor are links to the relevant OWASP pages. Unless specifically requested by the Uber security team these recommendations are unnecessary and will be added upon the bug being created internally.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-03-22T15:00:13.185Z"}]