Security Policy > Primary website
Reporting discoveries
Scope
These rewards apply to whatbox.ca only. No subdomains.
Rewards
Rewards will be sent via PayPal only.
Category | Cash | Service credit |
---|---|---|
XSS | 0 USD | 0 USD |
Missing or Incorrect HTTP Headers | 0 USD | 0 USD |
Missing or Incorrect DNS Records | 0 USD | 0 USD |
Weak TLS Ciphers | 0 USD | 0 USD |
SSL Certificate Errors | 0 USD | 0 USD |
CSRF | 0 USD | 0 USD |
Spoofing | 0 USD | 0 USD |
Phishing | 0 USD | 0 USD |
Confusion | 0 USD | 0 USD |
Internal Server Errors | 0 USD | 0 USD |
Denial of Service | 0 USD | 0 USD |
Rate Limits | 0 USD | 0 USD |
Resource Use | 0 USD | 0 USD |
Credential stuffing | 0 USD | 0 USD |
XSS (bypassing CSP) | 2,000 USD | 8,000 USD |
Authentication bypass | 2,500 USD | 10,000 USD |
SQL Injection | 15,000 USD | 60,000 USD |
Remote code execution | 10,000 USD | 40,000 USD |
Unauthenticated file read | 10,000 USD | 40,000 USD |
Unauthenticated file write | 15,000 USD | 60,000 USD |
Recently rejected
No CSRF token on /logout
While the lack of a CSRF token means an attacker can trick a user into logging out of their Whatbox account, we consider this a non-issue.
- A cross site logout increases the security of the user, by restricting the potential for further exploit.
- If CSRF tokens were employed, an expired token could prevent a user from logging out successfully and accidentally leaving a valid session open when they intentionally clicked "Logout".
Username enumeration or Email enumeration
Due to the requirements for unique usernames and unique email addresses, enumeration is possible in four areas:
- Registration
- Registration hints
- Password recovery
- Email change
We employ rate limiting on these endpoints to prevent enumerating more than a trivial number of possibilties. Further reports must demonstrate unbounded enumeration from a static IP for consideration.
Host header injections
We do not consider this a real vulnerability.
An attacker cannot make a victim's browser submit an invalid Host header without directly controlling the browser/computer which forms the trusted computing base for a website. If the attacker already has this much control, no counter-measure can keep a potential victim safe.
Some researchers have pointed out that some websites use the Host value in generated page content. We don't use the Host value in our code, preferring domain-relative URLs.
Unless you can construct an HTML proof of concept that triggers this in an unmodified web browser, we will reject all reports of this type.
No password complexity rules
This is more subjective than most of our security choices. The composition of passwords has been an ongoing debate for several years, and we fall into the camp that believes in allowing as many types of passwords as possible.
People don't want the cognitive load of remembering more complex passwords, so if you require lower + upper + number they will change their password from "password" to "Password1" which is not better.
A password that consists entirely of lowercase letters or only numbers can still be stronger (more entropy) than one with uppercase letters, symbols, etc., simply due to length. Passwords of any length can also be useless if they're reused across many websites and become known to an attacker.
We have experimented with the HaveIBeenPwned API in the past. This denylist can catch all passwords known to attackers (and would statistically block all the easy ones like "123456"). Unfortunately, we have refrained from deploying this because people find it upsetting when you tell them their password is known to blackhat attackers.
For some of the discussions we've watched over the years:
- Short complex password, or long dictionary passphrase?
- Are password complexity rules counterproductive?
The best hope for the future of password security is built-in browser password managers, which generate random, unique passwords for every website.
We also intend to implement biometric based logins for supported devices, helping users use strong, unique identifiers with minimal cognitive load.
An account that nobody knows the password to is the most secure of all, but it's not very useful to anyone. We need to balance the need for high-entropy unique passwords against unreliable human memory.
No DNSSEC
DNSSEC has been on our radar for several years, but we remain concerned about the impact on reliability.
DNSSEC looks like a "footgun" to us.
Similar to HTTP Public-Key-Pinning before it, it does provide a security improvement, but has a very unforgiving implementation where the slightest human error can cause outages that are impossible to resolve. There's no "undo" with DNSSEC, and it frequently brings major domains offline for weeks at a time.
We intend to wait this one out for several more years. Either DNSSEC v2 will address some of the pitfalls, or the combined experience of many engineers across many organizations will create a well-documented set of best practices we can follow.
Citation: An incomplete list of major outages caused by DNSSEC.
HTTP Feature-Policy header
We like the Feature-Policy header, but it is Chromium-only as of this writing. We will adopt it after Chrome, Firefox and Safari all implement support.
Password autocomplete enabled
Humans can not remember high entropy unique passwords as well as a good password manager. Disabling autocomplete is a reduction in security, not an improvement.