This commit mitigates rate limit bypasses in the configuration
docs by normalizing the email throttle key. (The normalization process
used is the same as used by the Clearance gem.)
---
Often an authentication process normalizes email addresses and usernames
before look up, say by downcasing and removing any whitespace.
Throttles that do not perform the same normalization are vulnerable
to rate limit bypasses.
For example, an attacker can bypass a vulnerable throttle by using
unlimited case and whitespace variants for the same email address:
- Variant 1: `victim@example.org`
- Variant 2: `victim@example. org` (one whitespace)
- Variant 3: `victim@example. org` (two whitespaces)
- Variant 4: `ViCtIm@eXaMpLe.org`
- etc, etc.
All of these variants resolve to the same email address, but allow
an attacker to bypass a vulnerable throttle. To mitigate, the email
throttle key should be normalized using the same logic the
authentication process uses for normalizing emails.
(cherry picked from commit 03926e0b75)
* Clarify Calling HTTP_ header in example
In trying to track down a bug here turns out I was trying to reference the wrong header shown in the readme.
Printing our `request.env` it becomes clear this is just the full request object:
```
{"rack.version"=>[1, 3],
"rack.errors"=>#<IO:<STDERR>>,
"rack.multithread"=>true,
"rack.multiprocess"=>false,
"rack.run_once"=>false,
"SCRIPT_NAME"=>"",
"QUERY_STRING"=>"",
"SERVER_PROTOCOL"=>"HTTP/1.1",
"SERVER_SOFTWARE"=>"puma 4.3.5 Mysterious Traveller",
"GATEWAY_INTERFACE"=>"CGI/1.2",
"REQUEST_METHOD"=>"POST",
"REQUEST_PATH"=>"/api/v1/....",
"REQUEST_URI"=>"/api/v1/...",
"HTTP_VERSION"=>"HTTP/1.1",
"HTTP_HOST"=>"example.com",
"HTTP_APIKEY"=>"secret_key",
"CONTENT_TYPE"=>"application/json",
"HTTP_USER_AGENT"=>"PostmanRuntime/7.25.0",
"HTTP_ACCEPT"=>"*/*",
"HTTP_CACHE_CONTROL"=>"no-cache",
...
```
* Update README.md
(cherry picked from commit f92889b360)
This commit mitigates rate limit bypasses in the configuration
docs by normalizing the email throttle key. (The normalization process
used is the same as used by the Clearance gem.)
---
Often an authentication process normalizes email addresses and usernames
before look up, say by downcasing and removing any whitespace.
Throttles that do not perform the same normalization are vulnerable
to rate limit bypasses.
For example, an attacker can bypass a vulnerable throttle by using
unlimited case and whitespace variants for the same email address:
- Variant 1: `victim@example.org`
- Variant 2: `victim@example. org` (one whitespace)
- Variant 3: `victim@example. org` (two whitespaces)
- Variant 4: `ViCtIm@eXaMpLe.org`
- etc, etc.
All of these variants resolve to the same email address, but allow
an attacker to bypass a vulnerable throttle. To mitigate, the email
throttle key should be normalized using the same logic the
authentication process uses for normalizing emails.
* Clarify Calling HTTP_ header in example
In trying to track down a bug here turns out I was trying to reference the wrong header shown in the readme.
Printing our `request.env` it becomes clear this is just the full request object:
```
{"rack.version"=>[1, 3],
"rack.errors"=>#<IO:<STDERR>>,
"rack.multithread"=>true,
"rack.multiprocess"=>false,
"rack.run_once"=>false,
"SCRIPT_NAME"=>"",
"QUERY_STRING"=>"",
"SERVER_PROTOCOL"=>"HTTP/1.1",
"SERVER_SOFTWARE"=>"puma 4.3.5 Mysterious Traveller",
"GATEWAY_INTERFACE"=>"CGI/1.2",
"REQUEST_METHOD"=>"POST",
"REQUEST_PATH"=>"/api/v1/....",
"REQUEST_URI"=>"/api/v1/...",
"HTTP_VERSION"=>"HTTP/1.1",
"HTTP_HOST"=>"example.com",
"HTTP_APIKEY"=>"secret_key",
"CONTENT_TYPE"=>"application/json",
"HTTP_USER_AGENT"=>"PostmanRuntime/7.25.0",
"HTTP_ACCEPT"=>"*/*",
"HTTP_CACHE_CONTROL"=>"no-cache",
...
```
* Update README.md
