Whatbox Logo

Security Policy > Primary website

Reporting discoveries

security@whatbox.ca

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.

  1. A cross site logout increases the security of the user, by restricting the potential for further exploit.
  2. 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:

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:

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.