avatar
Bug bounty
Public

KOMOJU - Public Bug Bounty Program

Degica provides KOMOJU, 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
3

Supported languages
English

Hacktivity

Reports
143
1st response
< 1 day
Reports last 24h
2
Reports last week
18
Reports this month
62

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

Scopes

ScopeTypeAsset value
https://yeswehack.staging.komoju.com web-application
Critical
Low
$50
Medium
$600
High
$3,000
Critical
$7,000
https://multipay-staging.test.komoju.com other
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

Non-qualifying vulnerabilities

  • Tabnabbing
  • Missing cookie flags
  • Content/Text injections
  • Mixed content warnings
  • Clickjacking/UI redressing
  • Denial of Service (DoS) attacks
  • Known CVEs without working PoC
  • Open ports without real security impact
  • 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
  • Outdated libraries without a demonstrated security impact
  • Any hypothetical flaw or best practices without exploitable PoC
  • Expired certificate, best practices and other related issues for TLS/SSL certificates
  • Unexploitable vulnerabilities (ex: XSS or Open Redirect in HTTP Host Header)
  • Reports with attack scenarios requiring MITM or physical access to victim's device
  • Missing security-related HTTP headers which do not lead directly to a vulnerability
  • Unauthenticated / Logout / Login and other low-severity Cross-Site Request Forgery (CSRF)
  • Invalid or missing SPF (Sender Policy Framework), DKIM, DMARC records
  • Session expiration policies (no automatic logout, invalidation after a certain time or after a password change)
  • Disclosure of information without direct security impact (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets)
  • CSV injection
  • HTTP Strict Transport Security Header (HSTS)
  • Subdomain takeover without a full working PoC
  • Blind SSRF without direct impact (e.g. DNS pingback)
  • Lack of rate-limiting, brute-forcing or captcha issues
  • User enumeration (email, alias, GUID, phone number)
  • Password requirements policies (length / complexity / reuse)
  • Ability to spam users (email / SMS / direct messages flooding)
  • Disclosed / misconfigured Google API key (including Google Maps)
  • Recently disclosed 0-day vulnerabilities (less than 90 days since patch release)
  • Password reset token leak on trusted third-party website via Referer header (eg Google Analytics, Facebook…)

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.