JULO encourages the responsible disclosure of security vulnerabilities in our services or on our website. In order to facilitate the responsible disclosure of security vulnerabilities, we agree that if, in our sole discretion, we conclude that a disclosure meets all of the guidelines of the JULO Bug Bounty Reward Program, JULO will not bring any private or criminal legal action against the disclosing party.

Our team of dedicated professionals works vigilantly to help keep customer information secure. We recognize the important role that security researchers and our user community play in helping to keep JULO and our customers secure. If you discover a site or product vulnerability please notify us using the guidelines below.

Please note that your participation in the Bug Bounty Program is voluntary and subject to the terms and conditions set forth on this page (“PROGRAM TERMS”). By submitting a site or product vulnerability to JULO you acknowledge that you have read and agreed to these PROGRAM TERMS.

These PROGRAM TERMS supplement the terms of JULO Terms Of Service Agreement and Privacy Policy and any other agreement in which you have entered with JULO. The terms of those JULO agreements will apply to your use of, and participation in, the Bug Bounty Program as if fully set forth herein. If any inconsistency exists between the terms of the JULO Universal.

Terms Of Service Agreement, Privacy Policy and these PROGRAM TERMS, these PROGRAM TERMS will control, but only with regard to the Bug Bounty Program. To encourage responsible disclosures, JULO commits that, if we conclude, in our sole discretion, that a disclosure respects and meets all the guidelines of these PROGRAM TERMS, Privacy Policy and Universal Terms Of Service Agreement, JULO will not bring a private action against you or refer a matter for public inquiry.

As part of your research, do not modify any files or data, including permissions, and do not intentionally view or access any data beyond what is needed to prove the vulnerability.

To be eligible for the Bug Bounty Program, you must not:

• Must not be an employee, or immediate family member of an employee of JULO or its subsidiaries or affiliates.
• Vulnerabilities must be reproducible and verifiable.
• Vulnerabilities must pose a security risk (e.g., not purely theoretical or requiring improbable circumstances).
• Reports must include detailed steps to reproduce the vulnerability, including any necessary code or tools.
• Participants must not disclose the vulnerability to the public or any third party until we have resolved it or given explicit permission from JULO.
• Participants must not exploit the vulnerability beyond what is necessary to demonstrate it.
• Participants must not use the vulnerability to access, modify, harm, or extract data from the JULO or its users.
• Participants must not violate any laws in the process of discovering or reporting vulnerabilities.
• Participants must not disrupt or compromise the integrity of the JULO data or services.
• When reporting vulnerabilities classified as Remote Code Execution (RCE), SQL Injection (SQLI), or Server-Side Request Forgery (SSRF), participants must provide detailed information about their testing process. This includes the IP address from which the testing was conducted.
• After submitting a vulnerability report, participants must remain available for further communication to provide additional details, clarifications, or assistance in reproducing the vulnerability if requested by JULO.
• If a participant fails to respond within the specified 30-day or cannot be contacted by JULO using the contact information provided in their submission, the participant may be disqualified from the bug bounty program. As a result, may be disqualified from the program and may not receive any rewards.
• Any participant found to be in violation of the program's terms, including but not limited to the eligibility requirements, may be disqualified from the program and may not receive any rewards.

JULO will make a best effort to adhere to the following response targets:

• julo.co.id
• api.julofinance.com
• api.julo.co.id
• crm.julo.co.id
• https://play.google.com/store/apps/details?id=com.julofinance.juloapp
• Any domains or applications not listed above are not in-scope.

JULO will accept a report of any vulnerability that substantially affects the confidentiality or integrity of any eligible JULO service. Eligible vulnerabilities include, but are not limited to:

• Remote Code Execution (RCE)
• Authentication or authorization bypass.
• Code injections (JS, SQL, PHP, Bash, …)
• Bypass Authorization Schema (Vertical or Horizontal)
• Disclosure of sensitive or personally identifiable information
• Significant security misconfiguration with a verifiable vulnerability
• OTP Bypass (Untrusted Devices)
• XSS Injection
• Business logic vulnerability with real security impact
• Cross-site Request Forgery (CSRF) with real security impact
• SSRF with real security impact
• Local files access and manipulation (LFI, RFI, XXE)
• Indirect Direct Object Reference (IDOR)

Any domain not listed in policy scope is out of scope for the purposes of the Bug Rewards Program, as is all hosted customer content and third-party programs and plug-ins.

The following actions do not qualify for the Bug Rewards Program and should not be tested by researchers participating in the Program:

• Findings from applications or systems that are not listed in the ’Scope’ section.
• Physical attack such as office access (eg open doors, tailgating).
• Social engineering (eg phishing, vishing).
• Functional, UI and UX bugs and misspellings (typos).
• Denial-of-service (DoS or DDoS) vulnerabilities at the network level.
• Disclosure of information without security impact (Stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets etc.)
• Click-jacking and problems that are only exploited through it.
• CSRF on a form available to anonymous users (eg contact form).
• Login / Logout CSRF.
• Presence of an application or an ’auto-complete’ or ’save password’ function in a web browser.
• Lack of Secure and HttpOnly flags on cookies.
• Lack of security speed bumps when leaving the website.
• Weak captcha or bypass captcha.
• Enumerate username/msisdn via Login,Forgot Password,Registration page.
• Brute force on the login page or on the forgot your password page and result in account lockout.
• HTTP TRACE option enabled.
• SSL attacks such as BEAST, BREACH, or around a renegotiation vulnerability.
• SSL forward secrecy.
• SSL which supports cipher suite algorithms is not secure.
• Missing security-related HTTP headers which do not lead directly to a vulnerability.
• Invalid or missing SPF (Sender Policy Framework) records or related to other e-mails (SPF / DKIM / DMARC).
• Automated scanning results using tools such as vulnerability scanners (Nessus, nikto, Qualys, OpenVAS, Core Impact, Acunetix, Nexpose, SecureCheq, Retina, MBSA, HIAB, and so on) even though the results include a potential security risk.
• Lack of rate-limiting or Captcha on all endpoints.
• Incomplete reports missing one or more of the following elements: clear textual description of the vulnerability, proof of exploitation, complete steps with the necessary information to reproduce the exploit.
• Reports describing hypothetical attack scenarios that are not demonstrable.
• Recently disclosed 0-day vulnerabilities (less than 90 days since patch release).
• Self XSS.
• Security best practices without demonstrated security impact.
• Vulnerable/outdated software/libraries without demonstrated security impact.
• Vulnerabilities affecting outdated versions - we only consider reports in the latest versions of our application that are currently in Google Play.
• Out of Scope bugs for mobile application:
  • Any URIs leaked because a malicious app has permission to view URIs opened.
  • Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries.
  • Absence of certificate pinning.
  • Path disclosure in the binary.
  • Lack of SSL Pinning/binary protection/code obfuscation/jailbreak or root detection/anti-debugging controls etc.
  • User data stored unencrypted on the file system/external storage.
  • Sensitive data in URLs/request bodies when protected by TLS.
  • Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceiver (exploiting these for sensitive data leakage is commonly in scope).
  • Any kind of sensitive data stored in the app private directory.
  • Runtime hacking exploits that are only exploitable on your own device using tools such as Frida/ Appmon (exploits only possible in a rooted environment).
  • Issues that require physical access to a victim’s mobile device
  • Use of a known-vulnerable library (without proof of exploitability).
  • Vulnerabilities reported on modified APK through an unofficial system

• Any bug that relies upon an outdated browser
• Infrastructure vulnerabilities, including:
• Issues related to SSL certificates
• DNS configuration issues
• Server configuration issues (e.g. open ports, TLS versions, etc.)
• Bugs require exceedingly unlikely user interaction.
• Insecure password complexity requirements
• Email verification/validation issues
• Quality and business logic bugs which do not pose real risk and do not impact business and customers in a way which could lead to unauthorised access to data or systems, also when there is no possibility to take advantage of the bug to couse some sort of damage to company systems or data.

Required information

For all submissions, please include:

• Full description of the vulnerability being reported, including the exploitability and impact
• Evidence and explanation of all steps required to reproduce the submission, which may

include:

• Videos or Step by step screenshots
• Exploit code
• Traffic logs
• Web/API requests and responses
• Email address or user ID of any test accounts
• IP address used during testing
• For RCE submissions, see below

Failure to include any of the above items may delay or jeopardize the Bounty Payment.

Failure to meet the below conditions and requirements could result in a forfeiture of any potential Bounty Payment.

• Source IP address
• Timestamp, including time zone
• Full server request and responses
• Filenames of any uploaded files, which must include “bugbounty” and the timestamp
• Callback IP and port, if applicable
• Any data that was accessed, either deliberately or inadvertently

Allowed Actions:

• Directly injecting benign commands via the web application or interface (e.g. whoami, hostname, ifconfig)
• Uploading a file that outputs the result of a hard-coded benign command

Failure to meet the below conditions and requirements could result in a forfeiture of any potential Bounty Payment.

• Uploading files that allow arbitrary commands (i.e. a webshell)
• Modifying any files or data, including permissions
• Deleting any files or data
• Interrupting normal operations (e.g. triggering a reboot)
• Creating and maintaining a persistent connection to the server
• Intentionally viewing any files or data beyond what is needed to prove the vulnerability
• Failing to disclose any actions taken or applicable required information

To demonstrate impact on RCE/SQLi/SSRF, please use only permitted commands or artifacts listed below in your PoC. If these given commands or artifacts do not apply to the specific testing that you are doing, please reach out to us. If we would like you to go further, we will mention it directly on your report

• RCE -> id / whoami / hostname / ifconfig / date (or equivalent).
• SQLI -> send us the version and/or the database diagram or equivalent benign queries.
• SSRF -> screenshots content page or specific behavior or provide SSRF canaries.
• Discovered vulnerabilities must not have any impact on other users’ activities or modify the application. For example: stored XSS should use console.log() instead of the usual alert(), confirm(), prompt()

*nb: Provide detailed information including your IP when you report these vulnerabilities. Failure to provide the required participant being disqualified from the bug bounty program.