[{"id":3771418,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n**Information Disclosure and Reward Policy**\nGrab values the contributions of security researchers in identifying vulnerabilities and safeguarding our platform. To ensure responsible reporting and fair recognition, the following guidelines apply to information leakage disclosures:\n-Reports on information leakage involving actual employee domain accounts are typically rewarded with a token of appreciation of **$50 USD** for each **unique case**. For other types of cases, rewards will be determined at our discretion.\n\n**_Note:_** Grab reserves the right to award bounties for cases demonstrating substantial impact. \n\n\n\n- Most information leakage issues are classified under Low Severity unless researchers can demonstrate a clear and significant impact. Examples of low-severity issues include, but are not limited to:\n      1. Leakage of non-sensitive public-facing information.\n      2. Discovery of outdated credentials or tokens that are no longer in use.\n      3. Misconfigured storage buckets containing non-sensitive data.\n\n- To ensure ethical and responsible disclosure, researchers are required to:\n     1. Provide source around how the leaked information was obtained.\n     2. Submit leaked credentials directly to Grab, refraining from testing their validity beyond authentication and immediately  logging out, without engaging in any functionality.\n\n- Any unauthorized exploitation or misuse of leaked information is strictly prohibited and may result in disqualification from the program.\n\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- This program is open and accessible to **external researchers only**; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n- Please report to us what data was accessed and delete the data accordingly. Do not save, copy, download, transfer, or disclose the data found, and please delete any files that may contain the data from your devices after the vulnerability has been validated.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n### Vulnerability found in LLM Models:\n\nAs we continue to innovate and integrate advanced technologies into our services, we recognize the potential for new types of vulnerabilities. This includes those related to Language Learning Models (LLM). For any Vulnerability related to LLM's please adhere to below guidelines:\n\n* Do not attempt any intrusive actions that could compromise the integrity and functionality of our LLM systems. This includes, but is not limited to, data poisoning and unauthorized data deletion.\n* Respect the boundaries of your testing activities. Any actions that could potentially harm our LLM systems or lead to unintended consequences are strictly prohibited.\n* Always make an effort in good faith to protect our LLM systems and data. This includes ensuring that there is no leak, manipulation, alteration, modification, or destruction of any data related to our LLM systems.\n\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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":"2026-03-20T08:23:24.953Z"},{"id":3764001,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n**Information Disclosure and Reward Policy**\nGrab values the contributions of security researchers in identifying vulnerabilities and safeguarding our platform. To ensure responsible reporting and fair recognition, the following guidelines apply to information leakage disclosures:\n-Reports on information leakage involving actual employee accounts are typically rewarded with a token of appreciation of **$50 USD** for each **unique case**. For other types of cases, rewards will be determined at our discretion.\n\n**_Note:_** Grab reserves the right to award bounties for cases demonstrating substantial impact. \n\n\n\n- Most information leakage issues are classified under Low Severity unless researchers can demonstrate a clear and significant impact. Examples of low-severity issues include, but are not limited to:\n      1. Leakage of non-sensitive public-facing information.\n      2. Discovery of outdated credentials or tokens that are no longer in use.\n      3. Misconfigured storage buckets containing non-sensitive data.\n\n- To ensure ethical and responsible disclosure, researchers are required to:\n     1. Provide source around how the leaked information was obtained.\n     2. Submit leaked credentials directly to Grab, refraining from testing their validity beyond authentication and immediately  logging out, without engaging in any functionality.\n\n- Any unauthorized exploitation or misuse of leaked information is strictly prohibited and may result in disqualification from the program.\n\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- This program is open and accessible to **external researchers only**; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n- Please report to us what data was accessed and delete the data accordingly. Do not save, copy, download, transfer, or disclose the data found, and please delete any files that may contain the data from your devices after the vulnerability has been validated.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n### Vulnerability found in LLM Models:\n\nAs we continue to innovate and integrate advanced technologies into our services, we recognize the potential for new types of vulnerabilities. This includes those related to Language Learning Models (LLM). For any Vulnerability related to LLM's please adhere to below guidelines:\n\n* Do not attempt any intrusive actions that could compromise the integrity and functionality of our LLM systems. This includes, but is not limited to, data poisoning and unauthorized data deletion.\n* Respect the boundaries of your testing activities. Any actions that could potentially harm our LLM systems or lead to unintended consequences are strictly prohibited.\n* Always make an effort in good faith to protect our LLM systems and data. This includes ensuring that there is no leak, manipulation, alteration, modification, or destruction of any data related to our LLM systems.\n\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-10-02T09:00:35.419Z"},{"id":3758372,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n**Information Disclosure and Reward Policy**\nGrab values the contributions of security researchers in identifying vulnerabilities and safeguarding our platform. To ensure responsible reporting and fair recognition, the following guidelines apply to information leakage disclosures:\n- Reports on information leakage are generally rewarded with a token of appreciation of **$50 USD** for each **unique case**.\n\n     **_Note:_** Grab reserves the discretion to award bounty for cases demonstrating substantial impact.\n\n\n- Most information leakage issues are classified under Low Severity unless researchers can demonstrate a clear and significant impact. Examples of low-severity issues include, but are not limited to:\n      1. Leakage of non-sensitive public-facing information.\n      2. Discovery of outdated credentials or tokens that are no longer in use.\n      3. Misconfigured storage buckets containing non-sensitive data.\n\n- To ensure ethical and responsible disclosure, researchers are required to:\n     1. Provide source around how the leaked information was obtained.\n     2. Submit leaked credentials directly to Grab, refraining from testing their validity beyond authentication and immediately  logging out, without engaging in any functionality.\n\n- Any unauthorized exploitation or misuse of leaked information is strictly prohibited and may result in disqualification from the program.\n\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- This program is open and accessible to **external researchers only**; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n- Please report to us what data was accessed and delete the data accordingly. Do not save, copy, download, transfer, or disclose the data found, and please delete any files that may contain the data from your devices after the vulnerability has been validated.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n### Vulnerability found in LLM Models:\n\nAs we continue to innovate and integrate advanced technologies into our services, we recognize the potential for new types of vulnerabilities. This includes those related to Language Learning Models (LLM). For any Vulnerability related to LLM's please adhere to below guidelines:\n\n* Do not attempt any intrusive actions that could compromise the integrity and functionality of our LLM systems. This includes, but is not limited to, data poisoning and unauthorized data deletion.\n* Respect the boundaries of your testing activities. Any actions that could potentially harm our LLM systems or lead to unintended consequences are strictly prohibited.\n* Always make an effort in good faith to protect our LLM systems and data. This includes ensuring that there is no leak, manipulation, alteration, modification, or destruction of any data related to our LLM systems.\n\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06-30T18:40:51.531Z"},{"id":3740707,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- This program is open and accessible to **external researchers only**; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n### Vulnerability found in LLM Models:\n\nAs we continue to innovate and integrate advanced technologies into our services, we recognize the potential for new types of vulnerabilities. This includes those related to Language Learning Models (LLM). For any Vulnerability related to LLM's please adhere to below guidelines:\n\n* Do not attempt any intrusive actions that could compromise the integrity and functionality of our LLM systems. This includes, but is not limited to, data poisoning and unauthorized data deletion.\n* Respect the boundaries of your testing activities. Any actions that could potentially harm our LLM systems or lead to unintended consequences are strictly prohibited.\n* Always make an effort in good faith to protect our LLM systems and data. This includes ensuring that there is no leak, manipulation, alteration, modification, or destruction of any data related to our LLM systems.\n\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-30T12:37:04.125Z"},{"id":3738069,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- This program is open and accessible to **external researchers only**; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06T07:20:25.859Z"},{"id":3738068,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- Additionally, this program is open and accessible to **external researchers only**; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06T07:19:48.196Z"},{"id":3737930,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-04T23:18:47.735Z"},{"id":3737787,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n- This program is open and accessible to external researchers only; any employees  (full time, part time, on fixed term contracts), contractors and certain service providers of Grab or its affiliates, sister  companies or associate companies shall be ineligible for this program. This exclusion shall be  effective retrospectively. Grab reserves the right to initiate disciplinary proceedings against any  individual who breaches this section and may demand a clawback for any rewards paid out in  contravention of this section.\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-04T09:43:27.730Z"},{"id":3703911,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note :**  For Mergers and Acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-09-28T08:15:44.705Z"},{"id":3703910,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites undergo an initial blackout period of **sixteen-months**. While we greatly appreciate any bug reports submitted earlier, they will not be eligible for rewards during this period.\n\n**Note **  For mergers and acquisitions (M\u0026A) until explicitly listed in the scope section, we will only accept reports of critical and high-severity bugs . These reports may be considered for bounty rewards at the discretion of our security team, who will assess severity and reward amounts.\n\nOur primary goal is to assess and address all reported vulnerabilities to enhance the safety of our platform. We highly value your patience and cooperation during this phase.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-09-28T08:14:19.902Z"},{"id":3679968,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n##_Attachment for November to December 2022 Promotion_\n\nPlease refer to the Grab Insurance Flow on pax app for instructions and program flow F2034129\n\n\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-11-15T13:54:09.650Z"},{"id":3679332,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n# Test Plan\n\nGrab core properties and other assets usually experience a large amount of data traffic\neveryday. During testing, kindly make sure to include a custom HTTP header in your requests\nso you can make it easier for us to determine activities that belong to the HackerOne community\nagainst our normal data and the malicious actors out in the world. Please do add the following\nwhen participating and submitting reports to the Grab program:\n* Please use HackerOne registered accounts \u003cusername\u003e@wearehackerone.com addresses or\nidentify yourself by providing your HackerOne username.\n* Include a custom HTTP header in all your traffic. Kindly add what header you use in the report\ntemplate so we can identify it easily.\n\n| **Identifier** | **Format** | **Examples** |\n| ------- | ------------------- |--------|\n| Username | X-Bug-Bounty:HackerOne-\u003cusername\u003e | X-Bug-Bounty:HackerOne-Th3Guardian |\n| Testing Timestamp | X-Bug-Bounty:Timestamp-\u003cDD-MM-YYYY HH:MM\u003e | X-Bug-Bounty:Timestamp-01-09-2022 23:49 |\n\nPlease always keep in mind and remember to abide by all program rules.\nTo mitigate potential damage, stop further testing, report the matter to Grab and HackerOne\nimmediately, and delete any related program data under your care.\n\n---------\n\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-11-02T05:39:36.160Z"},{"id":3673273,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n* Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n* Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n* Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n* Out-of-date software without demonstration of significant security impact.\n* Mis-configured host header with no significant security impact.\n* Broken Link Hijacking with no significant security impact.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n* Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n* Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n* Cross-site Request Forgery with no significant security impact.\n* Lack of cookie flags on non-sensitive cookies.\n* Issue related to HTTP \"OPTIONS\" method.\n* Content spoofing/text injection\n* Issues exploitable only on outdated browsers.\n* Best practice concerns without demonstrating an exploitable vulnerability.\n* Reverse Tabnabbing related issues.\n* Missing HTTP security headers with no significant security impact.\n* Infrastructure vulnerabilities, including:\n  * Issues related to weak TLS/SSL versions \u0026 ciphers.\n  * Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n  * Server misconfiguration issues (i.e., open ports, TLS, etc.)\n* Most vulnerabilities within our sandbox, uat, or staging environments.\n* Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n* Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n* Most issues requiring brute force.\n* Denial of service.\n* Spamming.\n* Insufficient rate limiting.\n* Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n* Any URIs leaked because a malicious app has permission to view URIs opened \n* Absence of certificate pinning \n* Sensitive data in URLs/request bodies when protected by TLS \n* User data stored unencrypted on external storage \n* Lack of obfuscation is out of scope \n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n* Any kind of sensitive data stored in-app private directory \n* Lack of binary protection control in the android app \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n* Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n* Absence of certificate pinning \n* Path disclosure in the binary \n* User data stored unencrypted on the file system \n* Lack of obfuscation is out of scope \n* Lack of jailbreak detection is out of scope \n* Crashes due to malformed URL Schemes \n* Lack of binary protection (anti-debugging) controls \n* Snapshot/Pasteboard leakage \n* Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06-24T07:24:10.672Z"},{"id":3673272,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n- Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n- Out-of-date software without demonstration of significant security impact.\n- Mis-configured host header with no significant security impact.\n- Broken Link Hijacking with no significant security impact.\n- Disclosure of known public files or directories, (e.g. robots.txt).\n- Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n- Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n- Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n- Cross-site Request Forgery with no significant security impact.\n- Lack of cookie flags on non-sensitive cookies.\n- Issue related to HTTP \"OPTIONS\" method.\n- Content spoofing/text injection\n- Issues exploitable only on outdated browsers.\n- Best practice concerns without demonstrating an exploitable vulnerability.\n- Reverse Tabnabbing related issues.\n- Missing HTTP security headers with no significant security impact.\n- Infrastructure vulnerabilities, including:\n- Issues related to weak TLS/SSL versions \u0026 ciphers.\n- Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n- Server misconfiguration issues (i.e., open ports, TLS, etc.)\n- Most vulnerabilities within our sandbox, uat, or staging environments.\n- Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n- Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n- Most issues requiring brute force.\n- Denial of service.\n- Spamming.\n- Insufficient rate limiting.\n- Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in the android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06-24T06:59:40.669Z"},{"id":3673213,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information, or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact on the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have a low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages that do not reveal any sensitive information (e.g. Stack Traces, application or server errors).\n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API, Sentry keys).\n- Open redirects. For the rare cases where the impact is higher, e.g. If you can leverage the open redirect to steal any sensitive information, perform an unauthorized action, chain with another vulnerability to bypass any restriction, etc., we do still want to hear about them.\n- Out-of-date software without demonstration of significant security impact.\n- Mis-configured host header with no significant security impact.\n- Broken Link Hijacking with no significant security impact.\n- Disclosure of known public files or directories, (e.g. robots.txt).\n- Clickjacking/Tapjacking issues without working POC and without demonstrating a significant security impact.\n- Comma Separated Values (CSV) injection without demonstrating a significant security impact.\n- Issues with prerequisite of MITM, physical or remote access to a victim's authenticated session.\n- Cross-site Request Forgery with no significant security impact.\n- Lack of cookie flags on non-sensitive cookies.\n- Issue related to HTTP \"OPTIONS\" method.\n- Content spoofing/text injection\n- Issues exploitable only on outdated browsers.\n- Best practice concerns without demonstrating an exploitable vulnerability.\n- Reverse Tabnabbing related issues.\n- Missing HTTP security headers with no significant security impact.\n- Infrastructure vulnerabilities, including:\n- Issues related to weak TLS/SSL versions \u0026 ciphers.\n- Mail server misconfiguration, spoofing, SPF, DMARC, etc.\n- Server misconfiguration issues (i.e., open ports, TLS, etc.)\n- Vulnerability requiring installation or use of 3rd party apps/ tools/ plugins for successful exploitation.\n- Issues with a prerequisite of phishing or controlling a victim's email account, social media accounts, etc.\n- Most issues requiring brute force.\n- Denial of service.\n- Spamming.\n- Insufficient rate limiting.\n- Disclosure of private IP addresses or domains pointing to private IP addresses.\n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in the android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06-23T02:56:06.241Z"},{"id":3668744,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-04-01T02:40:13.990Z"},{"id":3667799,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, license plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers, etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-03-09T03:43:29.217Z"},{"id":3667798,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-03-09T03:38:52.164Z"},{"id":3666637,"new_policy":"**_IMPORTANT NOTES_**\n* Please ensure that you have sufficient valid information in your report to demonstrate the RCE POC\n* A simple POC using DNS lookup or http request from tools such as webhook.site or requestbin.net and burp collaborator client (or any other similar mechanism) that does not prove the security impact _will not_ be eligible for bounty. \n* During your testing, kindly make sure to include a custom HTTP header in your requests so we can determine what activity belongs to the HackerOne community: *H1[Username]*\n* Only unique exploitable issues that are not internally known will be eligible for bounty\n* Eligible issues will be assessed based on its security impact for the final bounty\n* Other 0-day vulnerabilities (non-Log4J) will be handled the usual way and will only be accepted after the two months patch period.\n\n\n--------------\n\n\n# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-02-16T15:46:03.308Z"},{"id":3663656,"new_policy":"# POLICY UPDATE (4 JAN 2022) - Log4J issues are now eligible for submissions\n\nIn light of the criticality of the Log4J issue, Grab will be making an exception and lifting the patch period of this particular 0-day vulnerability. We are encouraging hackers to help surface exploitable log4j bugs in our in-scope systems and applications.\n\n **Starting from 4 January 2022, 12pm Singapore time (GMT+8), hackers can earn up to _$5,000_ in bounty per exploitable host reported to the Grab Program, with a clear POC and showing sufficient demonstration of the security impact.**\n\n**_IMPORTANT NOTES_**\n* Please ensure that you have sufficient valid information in your report to demonstrate the RCE POC\n* A simple POC using DNS lookup or http request from tools such as webhook.site or requestbin.net and burp collaborator client (or any other similar mechanism) that does not prove the security impact _will not_ be eligible for bounty. \n* During your testing, kindly make sure to include a custom HTTP header in your requests so we can determine what activity belongs to the HackerOne community: *H1[Username]*\n* Only unique exploitable issues that are not internally known will be eligible for bounty\n* Eligible issues will be assessed based on its security impact for the final bounty\n* Other 0-day vulnerabilities (non-Log4J) will be handled the usual way and will only be accepted after the two months patch period.\n\n\n--------------\n\n\n# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-01-04T04:40:00.177Z"},{"id":3663655,"new_policy":"# POLICY UPDATE (4 JAN 2022) - Log4J issues are now eligible for submissions\n\nIn light of the criticality of the Log4J issue, Grab will be making an exception and lifting the patch period of this particular 0-day vulnerability. We are encouraging hackers to help surface exploitable log4j bugs in our in-scope systems and applications.\n\n **Starting from 4 January 2022, 12pm Singapore time (GMT+8), hackers can earn up to _$5,000_ in bounty per exploitable host reported to the Grab Program, with a clear POC and showing sufficient demonstration of the security impact.**\n\n**_IMPORTANT NOTES_**\n* Please ensure that you have sufficient valid information in your report to demonstrate the RCE POC\n* A simple POC using DNS lookup or http request from tools such as webhook.site or requestbin.net and burp collaborator client (or any other similar mechanism) that does not prove the security impact _will not_ be eligible for bounty. \n* During your testing, kindly make sure to include a custom HTTP header in your requests so we can determine what activity belongs to the HackerOne community: *H1[Username]*\n* Only unique exploitable issues that are not internally known will be eligible for bounty\n* Eligible issues will be assessed based on its security impact for the final bounty\nOther 0-day vulnerabilities (non-Log4J) will be handled the usual way and will only be accepted after the two months patch period.\n\n\n--------------\n\n\n# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-01-04T04:39:13.955Z"},{"id":3663654,"new_policy":"# POLICY UPDATE (4 JAN 2022) - Log4J issues are now eligible for submissions\n\nIn light of the criticality of the Log4J issue, Grab will be making an exception and lifting the patch period of this particular 0-day vulnerability. We are encouraging hackers to help surface exploitable log4j bugs in our in-scope systems and applications.\n\n **Starting from 4 January 2022, 12pm Singapore time (GMT+8), hackers can earn up to _$5,000_ in bounty per exploitable host reported to the Grab Program, with a clear POC and showing sufficient demonstration of the security impact.**\n\n**_IMPORTANT NOTES_**\n* Please ensure that you have sufficient valid information in your report to demonstrate the RCE POC\n* A simple POC using DNS lookup or http request from tools such as webhook.site or requestbin.net and burp collaborator client (or any other similar mechanism) that does not prove the security impact _will not_ be eligible for bounty. \n* During your testing, kindly make sure to include a custom HTTP header in your requests so we can determine what activity belongs to the HackerOne community. \nH1[Username]\n* Only unique exploitable issues that are not internally known will be eligible for bounty\n* Eligible issues will be assessed based on its security impact for the final bounty\nOther 0-day vulnerabilities (non-Log4J) will be handled the usual way and will only be accepted after the two months patch period.\n\n\n--------------\n\n\n# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-01-04T04:37:10.568Z"},{"id":3657438,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines some example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed in the Rewards section are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | \n| :------- | ------------------- | \n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [^],  Access to source code|    \n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    \n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |  \n| None     | Duplicate, N.A, Informational bug(s)  | \n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n* Note that Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n* [^] Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-08-26T10:00:14.837Z"},{"id":3653432,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue if it is found to be valid. You may not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with the explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting a large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally identifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root cause, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low-security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low-security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting/banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/HTML \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. MX records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated WordPress instances \n- Most brute-forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in-app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06-14T13:30:54.673Z"},{"id":3652393,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or  destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n    * For all **other **disclosure guidelines (except for the disclosure of Grab issues mentioned above), please refer to [HackerOne's Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-18T10:48:03.053Z"},{"id":3652392,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or  destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \n\nFor all other disclosure guidelines (except for the disclose of Grab issues mentioned above), please refer  HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-18T09:06:24.090Z"},{"id":3652391,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or  destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. \nFor all other disclosure guidelines (except for the disclose of Grab issues mentioned above), please refer to the HackerOne Vulnerability Disclosure Guidelines. \n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-18T08:33:14.745Z"},{"id":3652160,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking an effort in good faith by ensuring that there is no leak, manipulation, alteration, modification and/or  destruction, in whatsoever manner, to any of user data and Grab proprietary data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-11T09:32:54.466Z"},{"id":3652090,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any Grab proprietary data, including PII and/or personal user information. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-10T09:35:03.204Z"},{"id":3650778,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n---------\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## _Mobile Apps Bounty Bonus_\n\nAs our native mobile apps are core and essential to our business, we will be awarding the following bonus amounts for valid Critical or High reports submitted to us. \n\n**Bonus Rewards on top of the base bounty:**\n\n| Report Severity | Bonus Bounty |\n| ---------- | ------------- |\n| Critical | $2,000 |\n| High | $1,000 |\n\nThe bonus amount will be determined based on the final severity of the report. \n\n**Mobile Assets eligible for bonus:**\n* Grab Passenger App (iOS/Android)\n* Grab Driver App (iOS/Android)\n\n## _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n---------\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n### Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n### Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n### Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n### Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---------\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---------\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-05T08:10:58.175Z"},{"id":3648610,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n### _Notes_\n\n* Please note that if a single fix is able to resolve multiple vulnerabilities, usually due to the same root case, it will be rewarded as a single bounty on one report, determined by its overall impact.\n* **For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-11T06:57:40.178Z"},{"id":3643912,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n**For quality reports that prove significant impact to the Grab business, are well-written, display an innovative approach in testing and where the reporter demonstrates a professional attitude, Grab may award a maximum of $2,000 bonus on top of the original bounty amount.** Decisions to award a bonus for a report is at our discretion.\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-10-20T09:39:20.470Z"},{"id":3643496,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-10-08T08:07:49.427Z"},{"id":3642957,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n| Domain        | Date Added  | Blackout end |\n| :------------ | ----------- | ------------ |\n| kios.grab.com | 06 Oct 2019 | 05 Oct 2020  |\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-29T10:38:36.659Z"},{"id":3642956,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-29T10:37:52.455Z"},{"id":3637395,"new_policy":"# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue, if it is found to be valid. You may not not disclose any information about the issue outside of the program unless you receive explicit written consent from the Grab team.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- **Disclose the vulnerability report directly and exclusively to us.** Please do not disclose (public disclosure or disclosure to other third parties- including vulnerability brokers) information about the issue or your report without explicit written consent from the Grab Team. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n| Domain        | Date Added  | Blackout end |\n| :------------ | ----------- | ------------ |\n| kios.grab.com | 06 Oct 2019 | 05 Oct 2020  |\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-06-16T10:22:19.682Z"},{"id":3627203,"new_policy":"## Updates\n\n**27/12/2019** - We have updated our **Policy** page with an  overhauled design. We hope this provides everyone a clearer and more concise representation of our program.\n\n**25/12/2019** -  **🎄Holiday notice:** some of our Triage team members are not available from December 20th through January 3rd. As a result, our usual response time may be longer than usual. The team wishes you all happy holidays and happy hacking! 🎄\n\n  ---\n\n# Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n# Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) |  Payout Range [1] |\n| :------- | ------------- | -------------------------- |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code|     🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |    $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |         $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n# Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties - including vulnerability brokers - before we addressed your report will forfeit the reward. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n###Known issues\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n###Acquisitions\n\nNewly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n| Domain        | Date Added  | Blackout end |\n| :------------ | ----------- | ------------ |\n| kios.grab.com | 06 Oct 2019 | 05 Oct 2020  |\n\n###Recently disclosed 0-day vulnerabilities\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n###Vulnerabilities found in third-party/vendors\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-01-02T05:39:15.997Z"},{"id":3627101,"new_policy":"## Updates\n\n**27/12/2019** - We have updated our **Policy** page with an  overhauled design. We hope this provides everyone a clearer and more concise representation of our program.\n\n**25/12/2019** -  **🎄Holiday notice:** some of our Triage team members are not available from December 20th through January 3rd. As a result, our usual response time may be longer than usual. The team wishes you all happy holidays and happy hacking! 🎄\n\n  ---\n\n## Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n## Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n## Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | Payout Range [1] |\n| :------- | ------------------------------------- | ---------------: |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code| 🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |  $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |       $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties - including vulnerability brokers - before we addressed your report will forfeit the reward. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n**Known issues**\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n**Acquisitions**\n\n Newly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n| Domain        | Date Added  | Blackout end |\n| :------------ | ----------- | ------------ |\n| kios.grab.com | 06 Oct 2019 | 05 Oct 2020  |\n\n**Recently disclosed 0-day vulnerabilities**\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n**Vulnerabilities found in third-party/vendors**\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-31T03:17:57.435Z"},{"id":3627100,"new_policy":"## Updates\n\n**27/12/2019** - We have updated our **Policy** page with an  overhauled design. We hope this provides everyone a clearer and more concise representation of our program.\n\n**25/12/2019** -  **🎄Holiday notice:** some of our Triage team members are not available from December 20th through January 3rd. As a result, our usual response time may be longer than usual. The team wishes you all happy holidays and happy hacking! 🎄\n\n  ---\n\n## Foreword\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. \n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n## Coordinated disclosure rules \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.  In the events of a possible bulk enumeration of customer data, refrain from harvesting large amount of information, a small sample is enough as a proof of concept.\n\nBy participating in this program, you agree to be bound by these rules.\n\n## Rewards\n\nGrab will only issue monetary rewards for reports demonstrating meaningful impact. 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 micro-site. \n\nFor this reason, we **strongly** encourage researchers to spend extra-time to provide a realistic attack/threat scenario adapted to our business. This will increase the chance of receiving a higher bounty.\n\nThe following table outlines the nominal rewards with example scenarios of vulnerabilities for in-scope assets. Note that all amounts listed here are the maximum we can pay for each issue based on their severities. All final decisions are at the discretion of Grab. \n\nWe try our best to cycle bounty payouts on Fridays. \n\n| Severity | Examples (inspired from previous reports) | Payout Range [1] |\n| :------- | ------------------------------------- | ---------------: |\n| Critical | RCE on a Production server,  Bulk personally indentifiable information (PII) exposure [2],  Access to source code| 🎉$5,000 - $10,000 |\n| High     | Restricted or limited account takeover,  Vertical/horizontal privilege escalations,  Authorization checks bypass allowing fraudulent transactions |  $2,000 - $5,000 |\n| Medium   | SSRF without clear impact demonstration,  Business logic error with monetary impact |    $500 - $2,000 |\n| Low      | Stored/Reflected XSS with low impact (no sensitive data exfiltrated),  Exposed logs without sensitive information,  Exposed API keys with low privileges |       $50 - $500 |\n| None     | Duplicate, N.A, Informational bug(s)  |            😞 $0 |\n\n~ **Bounty payout range table (all amounts are in USD)** ~\n\nWe sometimes decide on awarding a small bonus to promnote reports (and/or reseachers) meeting certain criterias such as: originality, clarity, or an overall professional attitude demonstrated by the reporter.\n\n*__[1]__ Asset severity can be used as a weightage for calculating the final bounty amount (please refer to the Scope section for more details).*\n\n*__[2]__ Including but not limited to: customer/driver name, email, address, IC number, driver photos, licence plate numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc.*\n\n## Report Eligibility\n\nGrab reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n- Be the first to report a specific vulnerability. \n- Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n- Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties - including vulnerability brokers - before we addressed your report will forfeit the reward. Please read and follow HackerOne's [Vulnerability Disclosure Guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n**Known issues**\n\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n**Acquisitions**\n\n Newly acquired sites are subject to a **twelve-month** blackout period. Bugs reported sooner are certainly appreciated but will not qualify for rewards.\n\n| Domain        | Date Added  | Blackout end |\n| :------------ | ----------- | ------------ |\n| kios.grab.com | 06 Oct 2019 | 05 Oct 2020  |\n\n**Recently disclosed 0-day vulnerabilities**\n\nWe need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. We will appreciate anyone raising awareness for new CVEs but such reports will not qualify for a reward either.\n\n**Vulnerabilities found in third-party/vendors**\n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n\n---\n\n## Out-of-Scope Vulnerabilities\n\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\nThe following findings are specifically excluded from the bounty: \n\n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g:\n  - Strict-Transport-Security \n  - X-Frame-Options \n  - X-XSS-Protection \n  - X-Content-Type-Options \n  - Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n  - Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n  - Certificates/TLS/SSL related issues \n  - DNS issues (i.e. mx records, SPF records, etc.) \n  - Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n## Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n## Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\n---\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\nWe are looking forward to seeing your reports,\\\n**Happy hunting !**\n\n🚗 Grab Application Security Team 🚗\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-31T03:15:31.441Z"},{"id":3624938,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n\n# Response Targets\n--------------------- \n\nGrab will make a best effort to meet the following response targets for hackers participating in our program:\n* Time to first response (from report submit) - 1 business days\n* Time to triage (from report submit) - 1 business days\n* Time to bounty (from triage) - 5 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n**Known Issues**\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\n**Third-party Vulnerabilities**\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n \n**Please note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.**\n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code.\n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-02T08:49:00.161Z"},{"id":3624812,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n\n# Response Targets\n--------------------- \n\nGrab will make a best effort to meet the following response targets for hackers participating in our program:\n* Time to first response (from report submit) - 1 business days\n* Time to triage (from report submit) - 1 business days\n* Time to bounty (from triage) - 5 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n**Known issues**\nPlease note that the Grab Security Team also actively looks for vulnerabilities across all assets internally. For reported issues that are already known to us, we will close them as duplicates.\nWe seek your kind cooperation to respect our final decision and to refrain from making multiple negotiations once the decision has been made. \n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code.\n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-29T05:08:50.957Z"},{"id":3620183,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n\n# Response Targets\n--------------------- \n\nGrab will make a best effort to meet the following response targets for hackers participating in our program:\n* Time to first response (from report submit) - 1 business days\n* Time to triage (from report submit) - 1 business days\n* Time to bounty (from triage) - 5 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code.\n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \n- Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two months before reporting these types of issues. \n- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-09-30T06:56:56.955Z"},{"id":3619449,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n\n# Response Targets\n--------------------- \n\nGrab will make a best effort to meet the following response targets for hackers participating in our program:\n* Time to first response (from report submit) - 1 business days\n* Time to triage (from report submit) - 1 business days\n* Time to bounty (from triage) - 5 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code.\n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-09-18T02:44:33.626Z"},{"id":3619261,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code.\n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-09-16T07:23:14.595Z"},{"id":3618846,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\nVulnerabilities affecting assets not listed as part of Grab's scope are not eligible for a bounty. If you find a vulnerability in a vendor or third-party that directly affects Grab, we will accept it and work with the third-party on a best-effort basis to remediate the issue. \nHowever, in certain exceptional cases, if we decide to reward, the decision will be at our discretion.\n \nPlease note that the rules, rewards, and assets in this Policy Page (https://hackerone.com/grab) precedes all previous versions and updates that may have been made in the past. All final decisions are at the discretion of Grab.\n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-09-11T13:57:27.484Z"},{"id":3609198,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys with no significant security impact (eg. Google Maps API keys) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-05-10T03:39:56.556Z"},{"id":3609076,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys (eg. Google Maps API keys) with no significant security impact\n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Publicly editable Git Wiki.\n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-05-08T08:22:47.233Z"},{"id":3608780,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Exposure of third-party API keys (eg. Google Maps API keys) with no significant security impact\n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-05-03T11:07:07.821Z"},{"id":3607117,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $5,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorisation Issues \n\n# Out-of-Scope Vulnerabilities\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated Wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n- Excessive Google Maps API key permissions in GrabFood Driver - `com.grab.food.dax`\n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n- Excessive Google Maps API key permissions in GrabFood Driver\n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-04-08T07:04:54.630Z"},{"id":3604531,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n- Excessive Google Maps API key permissions in GrabFood Driver - `com.grab.food.dax`\n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n- Excessive Google Maps API key permissions in GrabFood Driver\n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-03-08T09:52:12.611Z"},{"id":3604530,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n- Excessive Google Maps API key permissions in GrabFood Driver - `com.grab.food.dax`\n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-03-08T09:50:27.858Z"},{"id":3568634,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Path Disclosure\n- WordPress username enumeration\n- Most issues dealing with HTTP transmission.\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-02-09T17:16:06.009Z"},{"id":3565561,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- Broken Links\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-12-21T11:05:33.586Z"},{"id":3562139,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Flashed based XSS (XSF)\n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-10-23T08:14:09.197Z"},{"id":3560658,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-20T05:46:26.566Z"},{"id":3559967,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Properties\n--------------------- \n*.grabtaxi.com\n*.myteksi.com\n*.myteksi.net\n*.grab.co\n*.grab.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nparcel.grab.com\nwww.graballstars.com\nwww.drivegrab.com\n\n# Out-of-Scope Properties\n--------------------- \njira.grab.com\nwiki.grab.com\n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header\n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-04T10:01:21.522Z"},{"id":3557802,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Properties\n--------------------- \n*.grabtaxi.com\n*.myteksi.com\n*.myteksi.net\n*.grab.co\n*.grab.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nparcel.grab.com\nwww.graballstars.com\nwww.drivegrab.com\n\n# Out-of-Scope Properties\n--------------------- \njira.grab.com\nwiki.grab.com\n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- HTML Injection\n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-18T03:00:27.538Z"},{"id":3557755,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Properties\n--------------------- \n*.grabtaxi.com\n*.myteksi.com\n*.myteksi.net\n*.grab.co\n*.grab.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nparcel.grab.com\nwww.graballstars.com\nwww.drivegrab.com\n\n# Out-of-Scope Properties\n--------------------- \njira.grab.com\nwiki.grab.com\n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope Vulnerabiltiies\n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-17T09:20:04.761Z"},{"id":3557735,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Properties\n--------------------- \n*.grabtaxi.com\n*.myteksi.com\n*.myteksi.net\n*.grab.co\n*.grab.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nparcel.grab.com\nwww.graballstars.com\nwww.drivegrab.com\n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope \n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n# Out of Scope bugs for Android apps\n--------------------- \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Out of Scope bugs for iOS apps\n--------------------- \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n# Exclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-17T05:48:09.451Z"},{"id":3557734,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\n# Rewards \n--------------------- \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. \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# Rewards Payout Range \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n# In-Scope Properties\n--------------------- \n*.grabtaxi.com\n*.myteksi.com\n*.myteksi.net\n*.grab.co\n*.grab.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nparcel.grab.com\nwww.graballstars.com\nwww.drivegrab.com\n\n# In-Scope Vulnerability Classes\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n# Out-of-Scope \n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n### Out of Scope bugs for Android apps \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n### Out of Scope bugs for iOS apps \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\nExclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-17T05:47:11.395Z"},{"id":3557677,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\nRewards \n--------------------- \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. \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**Rewards Payout Range** \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n\n\n**In-Scope** \n--------------------- \n*.grabtaxi.com\n*.myteksi.com\n*.myteksi.net\n*.grab.co\n*.grab.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nparcel.grab.com\nwww.graballstars.com\nwww.drivegrab.com\n\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n**Out-of-Scope** \n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n### Out of Scope bugs for Android apps \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n### Out of Scope bugs for iOS apps \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\nExclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-16T04:15:06.901Z"},{"id":3557670,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\nRewards \n--------------------- \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. \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**Rewards Payout Range** \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n\n\n**In-Scope** \n--------------------- \n*.grabtaxi.com\ngrabtaxi.com\nmyteksi.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\ngrab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nwww.grabtaxi.com\nwww.graballstars.com\nparcel.grab.com\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n**Out-of-Scope** \n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n### Out of Scope bugs for Android apps \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n### Out of Scope bugs for iOS apps \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\nExclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-16T02:20:17.231Z"},{"id":3557399,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\nRewards \n--------------------- \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. \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**Rewards Payout Range** \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n\n\n**In-Scope** \n--------------------- \nPlease list all subdomains here\n*.grabtaxi.com\ngrabtaxi.com\nmyteksi.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\ngrab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nwww.grabtaxi.com\nwww.graballstars.com\nparcel.grab.com\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n**Out-of-Scope** \n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n### Out of Scope bugs for Android apps \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n### Out of Scope bugs for iOS apps \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\nExclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-12T09:34:00.160Z"},{"id":3557375,"new_policy":"\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery. \n\n# Coordinated disclosure rules \n--------------------- \n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere. \n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation. \n\n# Bounty eligibility \n--------------------- \n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should: \n\n1. Be the first to report a specific vulnerability. \n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary. \n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward. \n\n\nRewards \n--------------------- \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. \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**Rewards Payout Range** \n--------------------- \nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion \n\n- **Critical Security Issues ($5,000 - $10,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF) \n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII) \n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration \n\n\n\n**In-Scope** \n--------------------- \nPlease list all subdomains here\n*.grabtaxi.com\ngrabtaxi.com\nmyteksi.com\np.grabtaxi.com\nshare.grabtaxi.com\nhub.grab.com\ngrab.com\nsignup.grab.com\ngamma.grab.co\ndrive.grab.co\nmanage.grab.co\nwww.grabtaxi.com\nwww.graballstars.com\nparcel.grab.com\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- Directory Traversal Issues \n- Local File Disclosure (LFD) \n- Authorization Issues \n\n**Out-of-Scope** \n--------------------- \nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid. \n\n### The following findings are specifically excluded from the bounty: \n- Descriptive error messages (e.g. Stack Traces, application or server errors) \n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them \n- Publicly accessible login panels without proof of exploitation. \n- Reports that state that software is out of date/vulnerable without a proof of concept. \n- Host header issues without proof-of-concept demonstrating vulnerability. \n- HTTP codes/pages or other HTTP non- codes/pages. \n- Fingerprinting / banner disclosure on common/public services. \n- Disclosure of known public files or directories, (e.g. robots.txt). \n- Clickjacking and issues only exploitable through clickjacking. \n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). \n- Issues that require physical access to a victim’s computer. \n- CSRF in forms that are available to anonymous users (e.g. the contact form). \n- Login \u0026 Logout CSRF \n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. \n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies. \n- Lack of Security Speed bump when leaving the site. \n- Weak Captcha / Captcha Bypass \n- Login or Forgot Password page brute force and account lockout not enforced. \n- OPTIONS HTTP method enabled \n- Content injection issues. \n- HTTPS Mixed Content Scripts \n- Content Spoofing without embedded links/html \n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). \n- Reflected File Download (RFD). \n- XSS issues that affect only outdated browsers (like Internet Explorer) \n- Best practices concerns. \n- window.opener-related issues. \n- Highly speculative reports about theoretical damage. Be concrete. \n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g. \n* Strict-Transport-Security \n* X-Frame-Options \n* X-XSS-Protection \n* Host Header \n* X-Content-Type-Options \n* Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP \n* Content-Security-Policy-Report-Only \n- Infrastructure vulnerabilities, including: \n* Certificates/TLS/SSL related issues \n* DNS issues (i.e. mx records, SPF records, etc.) \n* Server configuration issues (i.e., open ports, TLS, etc.) \n- Most vulnerabilities within our sandbox, uat, or staging environments. \n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions \n- Vulnerabilities involving active content such as web browser add-ons \n- Physical or social engineering attempts (this includes phishing attacks against Grab employees). \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- Microsites with little to no user data \n- Issues requiring user-interaction \n- Outdated wordpress instances \n- Most brute forcing issues \n- Denial of service \n- Spamming \n\n\n### Out of Scope bugs for Android apps \n- Any URIs leaked because a malicious app has permission to view URIs opened \n- Absence of certificate pinning \n- Sensitive data in URLs/request bodies when protected by TLS \n- User data stored unencrypted on external storage \n- Lack of obfuscation is out of scope \n- OAuth \u0026 App secret hard-coded/recoverable in APK \n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope) \n- Any kind of sensitive data stored in app private directory \n- Lack of binary protection control in android app \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\n### Out of Scope bugs for iOS apps \n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries \n- Absence of certificate pinning \n- Path disclosure in the binary \n- User data stored unencrypted on the file system \n- Lack of obfuscation is out of scope \n- Lack of jailbreak detection is out of scope \n- OAuth \u0026 app secret hard-coded/recoverable in IPA \n- Crashes due to malformed URL Schemes \n- Lack of binary protection (anti-debugging) controls \n- Snapshot/Pasteboard leakage \n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) \n\nExclusions \n--------------------- \n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues. \n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power. \n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-12T02:50:25.288Z"},{"id":3557374,"new_policy":"Security is a top priority at Grab. While we take every possible measures to ensure our systems are well protected to safeguard your privacy, we still need your collaboration to make the Internet a better place. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology.\n\nIf you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nParticipation\n====================\n\nAt the current stage, the participation of this program is invitation-only. The Grab security team individually invites researchers to enter the program. Typically, these are individuals who have submitted quality reports and we have enjoyed working with or security researchers who have signal rating \u003e 1 on HackerOne platform. At times, we may reach out to additional reputable individuals we believe would benefit the program.\n\nSecurity is a top priority at Grab. We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nCoordinated disclosure rules\n---------------------\n\nPlease let us know as soon as possible upon discovery of a potential security issue, and we’ll make every effort to quickly correct the issue. Provide us a reasonable amount of time to fix the issue before publishing it elsewhere.\n\nMaking a good faith effort to not leak, manipulate, or destroy any user data. Please only test against accounts you own yourself or with explicit permission of the account holder. Please refrain from automated/scripted account creation.\n\nBounty eligibility\n---------------------\n\nGrabTaxi reserves the right to decide if the minimum severity threshold is met and whether it was previously reported. To qualify for a reward under this program, you should:\n\n1. Be the first to report a specific vulnerability.\n2. Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary.\n3. Disclose the vulnerability report directly and exclusively to us. Public disclosure or disclosure to other third parties -- including vulnerability brokers -- before we addressed your report will forfeit the reward.\n\nThings you should expect to receive little to no bounty for\n---------------------\n\n* Microsites with little to no user data\n* Issues requiring user-interaction\n* Outdated wordpress instances\n* Most brute forcing issues\n* Denial of service\n* Spamming\n\nRewards\n---------------------\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.\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**Rewards Payout Range**\n---------------------\nThe amounts listed here are the maximum we can pay for issues based on these severities. Purpose of this is provide you an idea of how we think about rewarding issues, at the end it all comes down to the underlying impact but at our discretion\n\n- **Critical Security Issues ($2,000 - $5,000):** Command injection, deserialisation bugs, sandbox escapes, remote code execution on a production server. Exposure of personally identifiable information (PII) customer IC numbers, driver images, licence numbers, location information etc or payment card information (PCI) like credit card numbers, bank account numbers etc. Potential access to source code or server-side request forgery (SSRF)\n\n- **High Security Issues ($1,000 - $2,000):** Restricted or limited account takeover, vertical/horizontal privilege escalations, authorization checks allowing bypassing fraudulent transactions and/or leading to the exposure of personally Identifiable Information (PII)\n\n- **Medium Security Issues ($200 - $1,000):** Stored/DOM Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not expose 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 enumeration\n\n**In-Scope**\n---------------------\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- Directory Traversal Issues\n- Local File Disclosure (LFD)\n- Authorization Issues\n\n**Out-of-Scope**\n---------------------\nThis section contains issues that are not accepted under this program, because they are malicious and/or because they have low security impact and will be immediately marked as invalid.\n \n###  The following findings are specifically excluded from the bounty:\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing auth tokens, we do still want to hear about them\n- Publicly accessible login panels without proof of exploitation.\n- Reports that state that software is out of date/vulnerable without a proof of concept.\n- Host header issues without proof-of-concept demonstrating vulnerability.\n- HTTP codes/pages or other HTTP non- codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt).\n- Clickjacking and issues only exploitable through clickjacking.\n- CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection).\n- Issues that require physical access to a victim’s computer.\n- CSRF in forms that are available to anonymous users (e.g. the contact form).\n- Login \u0026 Logout CSRF\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies.\n- Lack of Security Speed bump when leaving the site.\n- Weak Captcha / Captcha Bypass\n- Login or Forgot Password page brute force and account lockout not enforced.\n- OPTIONS HTTP method enabled\n- Content injection issues.\n- HTTPS Mixed Content Scripts\n- Content Spoofing without embedded links/html\n- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).\n- Reflected File Download (RFD).\n- XSS issues that affect only outdated browsers (like Internet Explorer)\n- Best practices concerns.\n- window.opener-related issues.\n- Highly speculative reports about theoretical damage. Be concrete.\n- [Missing HTTP security headers](https://www.owasp.org/index.php/List_of_useful_HTTP_headers), specifically, For e.g.\n * Strict-Transport-Security\n * X-Frame-Options\n * X-XSS-Protection\n * Host Header\n * X-Content-Type-Options\n * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n * Content-Security-Policy-Report-Only\n- Infrastructure vulnerabilities, including:\n * Certificates/TLS/SSL related issues\n * DNS issues (i.e. mx records, SPF records, etc.)\n * Server configuration issues (i.e., open ports, TLS, etc.)\n- Most vulnerabilities within our sandbox, uat, or staging environments.\n- Outdated web browsers: vulnerabilities contingent upon outdated or unpatched browsers will not be honoured, including Internet Explorer all versions\n- Vulnerabilities involving active content such as web browser add-ons\n- Physical or social engineering attempts (this includes phishing attacks against Grab employees).\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 \n### Out of Scope bugs for Android apps\n- Any URIs leaked because a malicious app has permission to view URIs opened\n- Absence of certificate pinning\n- Sensitive data in URLs/request bodies when protected by TLS\n- User data stored unencrypted on external storage\n- Lack of obfuscation is out of scope\n- OAuth \u0026 App secret hard-coded/recoverable in APK\n- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope)\n- Any kind of sensitive data stored in app private directory\n- Lack of binary protection control in android app\n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n \n### Out of Scope bugs for iOS apps\n- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries\n- Absence of certificate pinning\n- Path disclosure in the binary\n- User data stored unencrypted on the file system\n- Lack of obfuscation is out of scope\n- Lack of jailbreak detection is out of scope\n- OAuth \u0026 app secret hard-coded/recoverable in IPA\n- Crashes due to malformed URL Schemes\n- Lack of binary protection (anti-debugging) controls\n- Snapshot/Pasteboard leakage\n- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)\n\nExclusions\n---------------------\n- Issues related to software not under Grab’s control are out of scope. If you have found a vulnerability in systems managed externally, we can’t make any guarantees about when we can fix those issues.\n- We don’t need help running automated vulnerability scanners. We’ve got those covered. We need your brainpower, not your processing power.\n- Newly acquired sites are subject to a twelve-month blackout period. Bugs reported sooner are certainly appreciated but won't qualify for rewards.\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-12T02:47:47.418Z"}]