Security researchers are invited to investigate vulnerabilities in Glints, so long as their research follows this responsible research and disclosure policy.
If you find an issue involving security, please let us know as soon as possible, and we’ll make every effort to correct the problem quickly if it’s validated. It’s against the Glints policy not to disclose information about a problem outside of the program without the Glints team’s explicit permission.
By ensuring you agree to be bound by these rules by participating in this program:
- Any User data and Glints proprietary data are not leaked, manipulated, altered, modified and/or destroyed in any way.
- Only test against accounts you own yourself or with the explicit permission of the account holder.
- Automated/scripted account creation is not permitted.
- If customers need to be enumerated in bulk, reduce the amount of information you collect. A small sample will suffice for proving the concept.
Rewards
Impact-based rewards are our reward strategy. Thus, for example, we will offer a relatively high reward for a vulnerability that may leak sensitive user data, but very little to no reward for a vulnerability that might allow an attacker to deface a microsite. Our reward meetings have always included one question: If someone uses this in a malicious manner, how bad will it be? We assume the worst and pay out the bug accordingly.
In the event that we receive several reports for the same issue, we award the bounty to the earliest report with sufficient actionable information. We don’t want to encourage people to spam us with vague issues in an effort to be first.
In the event that a single fix fixes multiple vulnerabilities, we treat it as a single vulnerability. As an example, if you find three vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, you will receive a single bounty, as always determined by impact.
The payout ranges on this page are guidelines for expressing roughly how we think about the severity of different types of issues. These are not exact rules. Depending on their severity, bugs may have different attributes, which can affect payouts.
Ultimately, all reward amounts are at our discretion, but we strive to be fair. Some researchers will disagree with some of our decisions, but we pay out according to our ethical obligations and trust that most will consider their rewards fair and in many cases generous. The program will be tailored as it continues.
💰 We try our best to cycle bounty payouts on Fridays.
Severity | Bounty | Examples |
---|---|---|
Critical | 400 - 700 SGD |
|
High | 200 - 400 SGD |
|
Medium | 100 - 200 SGD |
|
Low | 50 - 100 SGD |
|
Trivial | No Rewards |
|
Scope
Out-of-Scope Vulnerabilities
In this section, you will find issues that will not be accepted under this program due to their malicious nature or low security impact and will be immediately marked as invalid.
There are certain findings that are explicitly excluded from the bounty program:
- Error messages defined as descriptive (eg.
stacktraces
, errors in applications and servers). - Host header issues without an accompanying proof-of-concept demonstrating vulnerability.
- Leakage of possibly sensitive query parameters (e.g. tokens with limited lifetime) to trusted third parties, including but not limited to: Google, Facebook, Amplitude, Front App, LinkedIn and Hotjar.
- Open redirects, most open redirects pose no security risks. Nevertheless, we do want to hear about the most severe cases, e.g. stealing authorization tokens.
- Login panels that are publicly accessible without any evidence that they have been exploited.
- Without a proven proof of concept, reports that claim software is out of date or vulnerable.
- Broken Links.
- Fingerprinting and banner disclosure for public services.
- List of publicly available files and directories (for example,
robots.txt
). - Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking.
- CSV injection.
- A security issue requiring physical access to the device.
- CSRF in forms that are available to anonymous users (e.g. the contact form).
- Login & Logout CSRF.
- Path Disclosure.
- WordPress username enumeration.
- Autocomplete or password saving functionality in the application or browser.
- Lack of Secure/HTTPOnly flags on non-security-sensitive Cookies.
- Weak Captcha / Captcha Bypass.
- Login or Forgot Password page brute force and account lockout not enforced.
OPTIONS
HTTP method enabled.- Content injection issues.
- HTTPS Mixed Content Scripts.
- Content Spoofing without embedded links/HTML.
- Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console).
- Reflected File Download (RFD).
- XSS issues that affect only outdated browsers (like Internet Explorer).
- Flashed based XSS (XSF).
- Best practices concerns.
- Wordpress XMLRPC issues.
window.opener
related issues.-
Missing HTTP security headers, specifically, For e.g:
Strict-Transport-Security
X-Frame-Options
X-XSS-Protection
X-Content-Type-Options
Content-Security-Policy
X-Content-Security-Policy
X-WebKit-CSP
Content-Security-Policy-Report-Only
-
Infrastructure vulnerabilities, including:
- Certificates/TLS/SSL related issues.
- DNS issues (i.e. MX records, SPF records, etc.).
- Server configuration issues (i.e., open ports, TLS, etc.).
- All vulnerabilities within our performance testing, unit test, or staging environments.
- Physical or social engineering attempts (this includes phishing attacks against Glints employees)
- Microsites with little to no user data.
- Issues requiring user-interaction.
- Outdated WordPress instance
- Denial of service.
- Spamming.
Fraud issues
If you wish to report fraud, please email [email protected]
. Despite the importance of these types of issues, our current rewards program cannot support this type of issue. The bug
bounty program does not currently consider these to be a part of its scope unless they show a specific technical vulnerability in our software. Verifying phone numbers, credit cards, etc., is fraud-related and not covered by the bug bounty
program.
Report Eligibility
Glints reserves the right to determine whether the minimum severity threshold is met and whether it has previously been reported.
Known issuesPlease be aware that the Glints Security Team actively searches for vulnerabilities across all assets internally. If the reported issue is already familiar to us, we will close it as a duplicate.
Once we have made our final decision, we ask for your kind cooperation in respecting that decision and refraining from multiple negotiations.
AcquisitionsNewly acquired sites are subject to a 12-month blackout period. Early reports of bugs are certainly appreciated, but will not be rewarded.
Recently disclosed 0-day vulnerabilitiesJust like everyone else, we need time to patch our systems - please give us two months before reporting these types of issues. We will appreciate anyone alerting us to new CVEs, but these reports will not qualify for a reward.
Vulnerabilities found in third-party/vendorsGlints' bounty program does not cover vulnerabilities affecting assets outside its scope. We will work with the vendor or third party on a best-effort basis to resolve any vulnerability that directly affects Glints if it is found. In rare, exceptional cases, we may decide to reward. However, the decision to reward will remain at our discretion.
Frequently Asked Questions
-
Can I blog about my bug?
Certainly, but we ask you to wait until the issue is both resolved and paid before you publish the blog post.
-
What is your policy on chaining bugs and privilege escalation?
Bug chains are welcome and we enjoy seeing clever exploit chains! However, if you have managed to compromise a Glints-owned server, we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. In the event that you get access to the Glints server, please notify us of that, and you will be rewarded with a bounty taking into account the severity of what could be accomplished. Combining a CSRF vulnerability with a self-XSS? Well done! Using AWS access keys to dump user information? This is a no-no.
-
Do you provide test accounts?
Currently, we do not have a good system for creating test accounts for our bug bounty reporters. Create an account as you would normally, and test with that account or accounts. Test against yourself whenever possible, never against another user. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution.
-
What about public disclosure?
Do you know of an interesting or clever bug in a Glints service? We’re more than happy to publicly disclose your bug once our developers have resolved it. Glints reserves the right to request additional time in some cases to investigate an issue internally and ensure that it is properly addressed across all services. Public disclosure before Glints has had time to remediate an issue is grounds for immediate forfeiture of any reward as well as possible removal from the bug bounty program.
-
What is a Glints microsite?
The Glints microsite is an unspecified website made by a Glints employee and owned by Glints but not explicitly listed above. Microsites include Glints city job sites, blogs, and partner sites etc.
Glints uses microsites to communicate programs, offers, and policies. Because they have smaller audiences, they should not contain much or any user data, and they are not part of our core services, the impact of issues on these sites would be significantly less severe. Since we are primarily interested in vulnerabilities that could lead to the exfiltration of customer information, vulnerabilities in microsites will not be rewarded except in extraordinary circumstances. In general, you might want to invest your time elsewhere instead of microsites.