avatar
Bug bounty
Public

KOMOJU - Public Bug Bounty Program

KOMOJU provides a versatile payment solution, along with cross-border payment support services.

Reward

Bounty
Hall of fame
$50
Low
$50
Medium
$600
High
$3,000
Critical
$7,000

Program

Avg reward
-
Max reward
-

Scopes
2
Supported languages
English

Hacktivity

Reports
626
1st response
< 1 day
Reports last 24h
2
Reports last week
20
Reports this month
8

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)

Staging Komoju

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,

f0d30bfc-36be-4264-b0b8-fa827fd249b2-staging komoju 1.png

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.

admin-login.png

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

api-key.png

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-session.png

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)

Multipay Staging

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

4c56f52c-caf3-46e8-a8c2-cae236c8ca30-multipay.PNG

KOMOJU Hosted Fields

Endpoint(s)

Doc komoju

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
Low
CVSS
Medium
CVSS
High
CVSS
Critical
Critical
$50$600$3,000$7,000
High
$50$400$800$1,500

Systemic issues

1st report100%
2nd report100%
3rd report75%
4th report50%
5th report25%
6th+ report10%

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

ScopeTypeAsset value
https://yeswehack.staging.komoju.com
Web application
Critical
Low
$50
Medium
$600
High
$3,000
Critical
$7,000
https://doc.komoju.com/docs/fields-overview
Other
High
Low
$50
Medium
$400
High
$800
Critical
$1,500

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:

Type of leak
Source of leak is in-scope
Source of leak belongs to the Organization and is out-of-scope
Source of leak does not belong to the Organization and is out-of-scope
Impact is in-scope (e.g. valid credentials on an in-scope asset)
checked Eligible
checked Eligible
checked Not eligible
Impact is out-of-scope (e.g. valid credentials for an out-of-scope asset)
checked Eligible
checked Not eligible
checked Not eligible

Hunting requirements

Account access


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.

To submit a vulnerability report, you need to login with your hunter account.