Bug Bounty Program
We take security very seriously. Thank you for taking the time to responsibly disclose any issues you find.
Alias Payments, builds and maintains a suite of mobile payments solutions for the fuel industry. Our products allow customers to pay at the pump using their mobile phone. Since we deal with payment information, security and privacy are our top priorities.
With this in mind, we remain committed to working with security researchers and alongside the security community, and will maintain trust, respect, and transparency that aligns with our commitment to security and privacy.
Other domains or subdomains not listed above and 3rd party services, are not in scope and will not qualify for a bounty.
Out of scope:
- Customer accounts and data are explicitly out of scope.
- Any data that you are not an owner of.
- Do not impact our customers in any way.
- Any vulnerability found in third party software.
To qualify for a bounty you must:
- Report a qualifying vulnerability that is in the scope of our program (see below)
- Be the first person to report the vulnerability
- Adhere to our disclosure guidelines (see below)
- Only test against your own accounts and data
- Refrain from disclosing the vulnerability until we’ve addressed it
- Communicate with our security team following our guidelines below (the security team will be way more impressed by your exploits than our support or social media teams)
Reports must include the following:
- A Proof of Concept
- Detailed steps on how to reproduce the vulnerability
- Explanation of how the attack could be executed in a real world scenario to compromise user accounts or data
The following finding types are specifically excluded from the bounty
- The use of Automated scanners is strictly prohibited (we have these tools too - don’t even think about using them)
- Descriptive error messages (e.g. Stack Traces, application or server errors).
- HTTP 404 codes/pages or other HTTP non-200 codes/pages.
- Fingerprinting / banner disclosure on common/public services.
- Disclosure of known public files or directories, (e.g. robots.txt).
- Clickjacking and issues only exploitable through clickjacking.
CSRF on forms that are available to anonymous users (e.g. the contact form).
- CSRF attacks that require knowledge of the CSRF token (e.g. attacks involving a local machine).
- Logout Cross-Site Request Forgery (logout CSRF).
- Content Spoofing.
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
- Cookies missing secure/HttpOnly.
- Lack of Security Speedbump when leaving the site.
- Weak Captcha / Captcha Bypass.
- Login or Forgot Password page brute force and account lockout not enforced.
- OPTIONS HTTP method enabled.
- Username / email enumeration.
Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.
- Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP.
- Cache-Control and Pragma
- HTTP/DNS cache poisoning.
SSL/TLS Issues, e.g.
- SSL Attacks such as BEAST, BREACH, Renegotiation attack.
- SSL Forward secrecy not enabled.
- SSL weak/insecure cipher suites.
- Not using certificate or public key pinning.
No Load testing (DoS/DDoS etc) is allowed on the instance.
- This includes application DoS as well as network DoS.
Self-XSS reports will not be accepted.
- Similarly, any XSS where local access is required (i.e. User-Agent Header injection) will not be accepted. The only exception will be if you can show a working off-path MiTM attack that will allow for the XSS to trigger.
- Vulnerabilities that are limited to unsupported browsers will not be accepted (i.e. “this exploit only works in IE6/IE7”). We only support the latest version of the following browsers on all platforms including mobile and desktop: Firefox, Safari, Microsoft Edge and Google Chrome.
- Known vulnerabilities in used libraries, or the reports that a product uses an outdated third party library (e.g. jQuery, Apache HttpComponents etc) unless you can prove exploitability.
- Missing or incorrect SPF records of any kind.
- Source code disclosure vulnerabilities.
- Information disclosure of non-confidential information (e. g. issue id, project id, commit hashes).
- The ability to upload/download viruses or malicious files to the platform.
- Email bombing/Flooding/rate limiting
- You must ensure that customer data is not affected in any way as a result of your testing. Please ensure you’re being non-destructive whilst testing and are only testing on data and accounts that you own.
In addition to above, customer accounts and data are not to be accessed in any way (i.e. no customer data is accessed, customer credentials are not to be used or “verified”)
- If you believe you have found sensitive customer data (e.g., login credentials, API keys etc) or a way to access customer data (i.e. through a vulnerability) report it, but do not attempt to successfully validate if/that it works.
- Use of any automated tools/scanners is strictly prohibited and will lead to you being removed from the program (trust us, we have those tools too).
- Reports need to be submitted in plain text (associated pictures/videos are fine as long as they’re in standard formats). Non-plain text reports (e.g. PDF, DOCX) will be asked to be resubmitted in plain text.
- Grants / awards / rewards are at the discretion of Alias and we withhold the right to grant, modify or deny grants. But we’ll be fair about it.
- Tax implications of any payouts are the sole responsibility of the reporter.
- Do NOT conduct non-technical attacks such as social engineering, phishing or unauthorized access to infrastructure.
- Do NOT test the physical security of Alias offices, employees, equipment, etc.
When conducting vulnerability research according to this policy, we consider this research to be:
- Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy;
- Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls;
- Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and
- Lawful, helpful to the overall security of the Internet, and conducted in good faith.
- You are expected, as always, to comply with all applicable laws.
If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through this program, or inquire via https://gasolinamovil.com/help before going any further.
All security bugs must be reported using this Google Form. This form is delivered to a subset of the team who handle security issues. Your report will be acknowledged within 24 hours, and you'll receive a more detailed response to your report within 48 hours indicating the next steps in handling your report.
After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement. These updates will be sent at least every five days. In reality, this is more likely to be every 24-48 hours.
If you have not received a reply to your report within 48 hours, or have not heard from the security team for the past five days, there are a few steps you can take:
- Contact our security team via email: security[at]aliaspayments.com.
- Contact the current security coordinator directly: Giovanni Collazo (hello[at]gcollazo.com).
- Contact our support team on https://gasolinamovil.com/help.
- Send a message or DM on Twitter to https://twitter.com/gasolinamovil.
If you have any suggestions to improve this policy, please send a message via https://gasolinamovil.com/help.
For the initial prioritization and rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy. However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority.
|Technical severity||Reward range|
|P1 - Critical||$500 - $1,000|
|P2 - Severe||$300 - $500|
|P3 - Moderate||$200 - $300|
|P4 - Low||$100 - $200|