Security first: Cayan's bug bounty program
Our approach to security focuses on protecting merchants and their data. We monitor every transaction from swipes to payments, and are always innovating in fraud prevention. We protect businesses’ data as if our business depends on it—because it does.
We follow industry-leading standards to:
- Manage our network
- Secure our web and client applications
- Set policies across our organization
We take the security of our services very seriously and monitor their use for indications of a malicious attack.
How our bounty program works
We welcome the contributions of the security research community, and have implemented our bug bounty program to encourage coordinated reporting of security issues with our services.
We especially want to hear about problems with our payment flows or the protection of data at rest. You can receive a reward of at least $250 if we confirm these vulnerabilities.
Important: You must not use this program to access or obtain sensitive or protected data, for example, cardholder data or personal information.
What is the scope of the program?
The bug bounty program applies to the following services:
Important: We review submissions that are associated with in-scope services only. For the purposes of this bug bounty program, *.cayan.com is not considered an in-scope service.
Note: We use Geo-IP Blocking to prevent connections from outside the US and Canada.
- If you are outside these regions, you need to use a proxy or originate your connection from the US or Canada.
- Our security team may block you during penetration testing, and terminate your connection. This is in line with our Incident Response Policy. To resume testing, change your IP address, ensuring that it originates in the US or Canada.
: At our sole discretion, Cayan will provide test credentials and portal login credentials upon request to established members of our Hackerone program
, subject to the terms of Cayan's Bug Bounty Program. These test accounts are configured to use our Test Processor
, and will allow you to meaningfully exercise our portals and APIs, but will not allow you to perform any actual credit or debit card authorizations. The Test Processor is configured to return fake stand-in authorization codes, and does not communicate with any credit card networks or issuing banks.
To help us identify legitimate security research as opposed to malicious attacks against our services, we promise not to take legal action against researchers who:
- share the full details of any problems found with us;
- do not share the issue with others until we have had reasonable time to address it;
- do not intentionally harm the experience or usefulness of the service to others;
- never attempt to view, modify, or damage other people’s data;
- do not attempt a Denial-of-Service (DoS) attack, and;
- do not carry out any research or testing which breaks the law.
Our security team determines the value of your bounty based on the severity of the vulnerability you report. Bounties start at $250. We award bounties entirely at our discretion; if you provide research that is more complete, with proof-of-concept code, and detailed write-ups you may receive a bonus percentage on top of the bounty we award. However, we may pay less for vulnerabilities which cannot be used as an attack vector, which require complex interactions, or if the impact of the security risk is minor.
In some cases, we may consolidate bounties into a single payout. For example, we may consolidate bounties into one payout, if you report a single vulnerability that:
- compromises the security across several areas of one of our services; or
- compromises the security across several of our services.
Note: Our services are genius.merchantware.net, transport.merchantware.net, ps1.merchantware.net and portal.merchantware.net.
We may reduce or decline bounties if there is evidence of abuse, such as data exfiltration or withholding reports in order to chain multiple issues together.
Eligibility and coordinated disclosure
You are eligible for a bounty only if you are the first person to disclose an unknown issue to us. Our security team and associated development teams have 30 days to respond to your report and up to 90 days to implement a fix based on the severity of the report. Please allow us to complete this process before you publically disclose the vulnerability.
Note: You will forfeit any reward/bounty and risk immediate removal from this program if:
- you post details or conversations about a report before we approve it for public release,
- you post details that reflect badly on this program and the Cayan brand.
Important: The following people are not eligible for participation in the bounty program:
- Current or former Cayan (or Merchant Warehouse) employees
- Immediate family members of current or former employees, vendors, and contractors
What type of vulnerabilities are we looking for?
We are looking for anything that could negatively affect the security of our merchants as described in this section.
OWASP Top 10
The following table contains the top ten risks as described by OWASP Top 10 Application Security Risks - 2013. The bounty program has an API only scope, not all of the risks shown in the following table are applicable, but they do provide a framework to identify and describe vulnerabilities, which you may uncover within our API.
|A1 - Injection
||Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
||SQL, LDAP Injection
|A2 - Broken Authentication and Session Management
||Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
||Authentication Bypass, Escalated Privilege, Session Replay, Exposure of administrative functions to unauthorized callers
|A3 - Cross-Site Scripting (XSS)
||XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
|A4 - Insecure Direct Object References
||A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
|A5 - Security Misconfiguration
||Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
|A6 - Sensitive Data Exposure
||Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
|A7 - Missing Function Level Access Control
||Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
|A8 - Cross-Site Request Forgery (CSRF)
||A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
|A9 - Using Components with Known Vulnerabilitites
||Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known
The following table contains additional vulnerabilities we are especially interested in identifying and fixing:
|B1 - Server-Side Request Forgery (SSRF)
||SSRF occurs when attackers can influence a network connection made by the application server. The network connection will originate from the application server internal IP, attackers are able to use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.
|B2 - XML External Entity Attacks (XXE)
||XXE attacks enable attackers to reveal normally protected files from a server or connected network. An attack occurs when a weakly configured XML parser processes an XML input containing a reference to an external entity. The attack can lead to the disclosure of confidential data, DoS, SSRF, port scanning from the perspective of the machine where the parser is located, etc.
|B3 - Open Redirect Vulnerabilities
||An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. Phishing attacks use open redirects to get users to visit malicious sites without realizing it.
|B4 - Remote Code Execution (RCE)
||Attacker executes their choice of arbitrary code on a target machine or target process.
Capture the flag (file)
We will pay a bounty if you can find the hackerone-flag.txt. Please note the following:
- The hackerone-flag.txt file contains a 32 character UUID
- The SHA256 digest of the flag is: a35eb8614dc3afa714107b09796f22146104bf046d718ed8b2beb0b28af08c40
Important: To claim the bounty, you must tell us how you found the file.
Computing the SHA256 message digest
We are publishing the digest of the flag to allow you to confirm you have found the right file. To view the digest of the flag, we ran the following command:
echo [32 characters] | sha256sum
You can run the same command on your terminal. You may need to install sha256sum or use an alternative method.
For example, if the value of the token was:
Then you would get the following response:
~ echo -n fb3f8fe63cc107c1977855c95633fb13 | sha256sum
Note: The values listed above are not genuine and are for example only.
What type of vulnerabilities are we not looking for?
We do not consider the following severe enough for reward as part of our bug bounty program:
- Vulnerabilities affecting users of outdated browsers or platforms:
- Internet Explorer prior to version 9
- Chrome prior to version 40
- Firefox prior to version 35
- Safari prior to version 7
- Opera prior to version 13
- Concerns about best practices
- Highly speculative reports about theoretical damage
- Vulnerabilities reported by automated tools or scans without additional analysis as to how they are an issue
- DoS Attacks
- Reflected File Download (RFD)
- Issues related to Window.opener
- Social engineering attempts (this includes phishing attacks against our employees)
- Content injection issues
- Non-validated reports from automated web vulnerability scanners (Acunetix, Vega, etc.)
- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)
- Missing cookie flags on non-security sensitive cookies
- Issues which require physical access to a victim’s computer
- Fraud issues
- Banner grabbing issues (figuring out what web server we use, etc.)
- Brute force attacks without proof that Cayan failed to lock out or otherwise disable a valid account after a number of unsuccessful login attempts
- Open ports without an accompanying proof-of-concept demonstrating vulnerability
- Issues related to software that is not under our control
- Any physical attempts against our property or our data centers
- The presence of autocomplete attribute on web forms
- Missing HTTP security headers (unless you deliver a proof-of-concept that takes advantage of their absence)
- Clickjacking on widgets intended to be embedded in other pages
- Reports of insecure SSL/TLS ciphers (unless you have a working proof-of-concept, and not just a report from a scanner such as SSL labs)
- An oracle that discloses whether a given username, email address, or phone number is associated with an actual account. (However, please do submit anything that allows you to recover usernames as a whole.)
- Bugs that we are already fixing or that someone else has previously reported
- Underspecified reports, where the information provided is insufficient to reproduce the vulnerability
- Functionality bugs which do not compromise the security of our users’ accounts or personal information
- Bugs that have been disclosed publicly or to third parties (brokers) by you or others
- Vulnerabilities on sites that are not owned or operated by us
- Testing a suspected vulnerability in a way that violates any law or compromises data that is not your own
- Informational-based or reconnaissance-based reports that:
- are best practices
- do not lead to real-world threat vectors
- could not be used to exploit the target systems
- We want to limit the security testing to the scope provided above, for more information see What is the scope of the program?
- We do not allow any pivoting from the initial point of compromise; this is to ensure we protect external systems and third parties.
- Do not extend the scope of the testing from the scope.
Submitting a bug report
If you think you have found a security vulnerability, please report it to us at firstname.lastname@example.org.
Attributes of a good report
You should include the following information when reporting a vulnerability to us:
- Detailed steps on how to reproduce the bug, please include the following:
- Any links you clicked
- Any pages you visited, etc.
- Description of the versions of all relevant components of the attack, for example, browser, OS, mobile app version, etc.
- Provide context, describe the specific scenario, and how the bug/vulnerability will affect us.
Encrypting email communications
You can encrypt email communications to email@example.com using our PGP key below.
SHA256 (HEX) Fingerprint: A0753D2CC520F41B9404E354550C339DB8F7619A3495B91059D868637552DCD3
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG C# v22.214.171.124
-----END PGP PUBLIC KEY BLOCK-----
Terms and Conditions
- Participants are responsible for paying any taxes associated with rewards.
- Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information. Your testing must not violate any law, or disrupt or compromise any data that is not your own.
- We reserve the right to modify the terms of this program or terminate this program at any time.
- By participating in this program, you agree to be bound by these rules.