KOMOJU - Public Bug Bounty Program
KOMOJU provides a versatile payment solution, along with cross-border payment support services.
Reward
Program
Hacktivity
About
KOMOJU by Degica
Degica is the company behind KOMOJU, a developer friendly API to integrate online payments.
KOMOJU is a payment gateway which supports all major payment methods in Japan, Korea and Europe. The service offers a RESTful API and a Hosted Page for easy integrations.
Program Rules
Testing Policy and Responsible Disclosure
Please adhere to the following rules while performing research on this program:
- Denial of service (DoS) attacks on Degica applications, servers, networks or infrastructure are strictly forbidden.
- Avoid tests that could cause degradation or interruption of our services.
- Do not use automated scanners or tools that generate large amount of network traffic.
- Do not leak, manipulate, or destroy any user data or files in any of our applications/servers.
- Do not copy any files from our applications/servers and disclose them.
- No vulnerability disclosure, full, partial or otherwise, is allowed.
- Do not send form inquiries from our websites.
Reward Eligibility
We are happy to thank everyone who submits valid reports which help us improve the security of KOMOJU, however only those that meet the following eligibility requirements may receive a monetary reward:
- You must be the first reporter of a vulnerability.
- The vulnerability must be a qualifying vulnerability (see below).
- The report must contain the following elements:
- Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and Degica, and remediation advice on fixing the vulnerability
- Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
- Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc
- You must not break any of the testing policy rules listed above
- You must not be a former or current employee of KOMOJU or one of its contractors.
Reward amounts are based on:
- Reward grid of the report's scope
- CVSS scoring and actual business impact of the vulnerability upon performing risk analysis
Complements about our scopes
KOMOJU
We have different types of users :
- Merchant : basic access to basic features, ...
- Admin : advanced access to basic features and workflows
- Super Admin : privileged access and approval rights
For a guide on how to test our scopes please see our Bug Bounty Onboarding Guide
Note, yeswehack.staging.komoju.com database is reset every weekend on Sunday. Old payment information will be wiped.
KOMOJU Payment Gateway
Endpoint(s)
Overview
KOMOJU is a payment gateway which supports many payment methods in Japan, Korea and Europe. KOMOJU offers an online web dashboard and RESTful API endpoints for merchants to create online payments.
Merchants (store owners) can integrate with KOMOJU using our JSON API or Hosted Page API to create payments.
Technology Stack
- AWS
- Ruby on Rails
How it works
KOMOJU is a payment gateway where merchants can sign up on our platform to start accepting payment online. Here is a typical flow for a first-time merchant,
- Merchant register their account at https://yeswehack.staging.komoju.com/en/sign_up
- Merchant completes KYC onboarding form after signing up
- Merchants KYC application is approved and can start accepting payments using our API
After a merchant is approved they can start using our system to accept payments online through our API or one of our supported EC plugins.
Admin Dashboard
We provide an admin dashboard for our merchants to manage their payments online. This includes features like searching for payments, adding users, making refunds, etc.
The dashboard is also used by our support team internally to support and monitor payments being created.
Pentesters can access the admin dashboard here https://yeswehack.staging.komoju.com/admin using the credentials provided in our bug bounty program.
User Roles
KOMOJU has three basic user roles in the platform:
-
Merchant Users - These are credentials that have been provided in the bug bounty
-
Admin Users - Advanced access to basic features and workflows
-
Super Admin Users - Privileged access and approval rights
As part of the bug bounty program we provide credentials for “Merchant Users” only
Getting your API Secret
After creating your account, you can login and get API keys for interacting with the KOMOJU API to create payments.
Make sure you’re in “Test Mode”, and navigate to the “Settings” section. Copy your merchant “Secret Key” and “Publishable Key” for interacting with the API
Creating a Test Payment
With your API key, you can then create test payments using the following cURL command or API client of your choice,
curl -X POST https://yeswehack.staging.komoju.com/api/v1/sessions \
-u sk_test_d4kipfbxl7hl28k194j4t3ra: \
-d "return_url=https://example.com" \
-d "amount=1000" \
-d "default_locale=en" \
-d "currency=JPY"
Note: The -u parameter should be replaced by your secret key.
After making a payment using the API, the response should contain a session_url value. Navigate to this URL and then proceed to make a test payment.
{
...
"session_url":"https://yeswehack.staging.komoju.com/sessions/73tusla4vgt0srrp835lf9gdj"
...
}
Payment Details
A list of test payment details for Credit card payment can be found below,
https://doc.komoju.com/docs/test-cards#credit-card-numbers
For other payment methods any dummy values can be used to create test payments.
KOMOJU MultiPay
Endpoint(s)
Overview
KOMOJU MultiPay is a Javascript library which merchants can embed in their websites.
The purpose of the library is to securely capture credit card input from a customer rather than allowing the merchant’s website to handle sensitive cardholder information and instead be hosted securely on our own servers allowing for PCI DSS compliance.
Once the user enters their card information the secure iFrame returns an API token which can be used to create a payment from the KOMOJU API.
Live Demo
You can interact with a live demo on our API documentation page,
https://docs.komoju.com/en/multipay/overview/#integrating
Sequence Diagram
KOMOJU Hosted Fields
Endpoint(s)
Technology Stack
- Javascript
Overview
KOMOJU Hosted Fields are a secure way to collect card holder information. The library works by embedding iframes for the customer field input when capturing credit card information.
The library is frontend only and interacts with our Sessions API to create payments using a publishable key.
Reward
| Asset value | CVSS | CVSS | CVSS | CVSS |
|---|---|---|---|---|
| $50 | $600 | $3,000 | $7,000 | |
| $50 | $400 | $800 | $1,500 |
Systemic issues
We appreciate all valid reports submitted to our program that enhance our security. However, please note that if a similar issue (see definition in 'More info') has already been reported, by you or any other hunter, the reward will be decreasing according to these percentages.
Scopes
| Scope | Type | Asset value | Expand rewards grid |
|---|---|---|---|
https://yeswehack.staging.komoju.com | Web application | ||
Low Medium High Critical | |||
https://doc.komoju.com/docs/fields-overview | Other | ||
Low Medium High Critical | |||
Out of scopes
- All domains or subdomains not listed in the above list of 'Scopes'
- Account squatting, or registering accounts to prevent others from signing up, is out of scope.
Vulnerability types
Qualifying vulnerabilities
- SQL Injection (SQLi)
- Cross-Site Scripting (XSS)
- Remote Code Execution (RCE)
- Insecure Direct Object Reference (IDOR)
- Horizontal and vertical privilege escalation
- Authentication bypass & broken authentication
- Business Logic Errors vulnerability with real security impact
- Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
- Cross-Origin Resource Sharing (CORS) with real security impact
- Cross-site Request Forgery (CSRF) with real security impact
- Open Redirect
- Exposed secrets, credentials or sensitive information on an asset under our control and affecting at least one of our scopes
- Only race conditions leading to sensitive information disclosure (e.g. PII, credentials, authorization bypass)
Non-qualifying vulnerabilities
- Broken Link/Social media Hijacking
- Tabnabbing
- Missing cookie flags
- Content/Text injections
- Clickjacking/UI redressing
- Denial of Service (DoS) attacks
- Recently disclosed CVEs (less than 30 days since patch release)
- CVEs without exploitable vulnerabilities and PoC
- Open ports or services without exploitable vulnerabilities and PoC
- Social engineering of staff or contractors
- Presence of autocomplete attribute on web forms
- Vulnerabilities affecting outdated browsers or platforms
- Self-XSS or XSS that cannot be used to impact other users
- Any hypothetical flaw or best practices without exploitable vulnerabilities and PoC
- SSL/TLS issues (e.g. expired certificates, best practices)
- Unexploitable vulnerabilities (e.g. Self-XSS, XSS or Open Redirect through HTTP headers...)
- Reports with attack scenarios requiring MITM or physical access to victim's device
- Missing security-related HTTP headers which do not lead directly to an exploitable vulnerability and PoC
- Low severity Cross-Site Request Forgery (CSRF) (e.g. Unauthenticated / Logout / Login / Products cart updates...)
- Invalid or missing email security records (e.g. SPF, DKIM, DMARC)
- Session management issues (e.g. lack of expiration, no logout on password change, concurrent sessions)
- Disclosure of information without exploitable vulnerabilities and PoC (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets, EXIF Metadata, Origin IP)
- CSV injection
- Malicious file upload (e.g. EICAR files, .EXE)
- HTTP Strict Transport Security Header (HSTS)
- Subdomain takeover without a full exploitable vulnerability and PoC or not applicable to the scope
- Blind SSRF without exploitable vulnerabilities and PoC (e.g. DNS & HTTP pingback, Wordpress XMLRPC)
- Lack or bypass of rate-limiting, brute-forcing or captcha issues
- User enumeration (e.g. email, alias, GUID, phone number, common CMS endpoints)
- Weak password policies (e.g. length, complexity, reuse)
- Ability to spam users (email / SMS / direct messages flooding)
- Disclosed or misconfigured public API keys (e.g. Google Maps, Firebase, analytics tools...)
- Password reset token sent via HTTP referer to external services (e.g. analytics / ads platforms)
- Stolen secrets, credentials or information gathered from a third-party asset that we have no control over
- Exposed secrets, credentials or information on an asset under our control that are not applicable to the program’s scope
- Pre-account takeover (e.g. account creation via oAuth)
- GraphQL Introspection is enabled
- Vulnerabilities requiring physical access to a user’s smartphone
- Exploits that are only possible on Android version 8 and below
- Exploits that are only possible on IOS version 14 and below
- Exploits that are only possible on a jailbroken device
- Exploiting a generic Android or iOS vulnerability.
- Lack of code obfuscation
- Lack of binary protection / jailbreak and root detection / anti-debugging controls
- Crashing your own application
- Non important secrets (such as 3rd party secrets)
- SSL cypher suites
- Vulnerable version of libraries (for example ‘jquery’) without demonstrable attack vector SSL Pinning
- Race conditions NOT leading to sensitive information disclosure (e.g. PII, credentials, authorization bypass)
- Name squatting
Reports of leaks and exposed credentials
In the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program’s scope and policy. To summarize our policy, you may refer to the below table:
Hunting requirements
Account access
- https://yeswehack.staging.komoju.com will be tested in grey-box mode.
- You can self-register from https://yeswehack.staging.komoju.com/en/sign_up
- The rest of the scope will be tested in black-box mode.
Hunters collaboration
When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.
For more information, see help center.
Note: For reports that have already been rewarded, it is not possible to redistribute the rewards.