Bugs in `Authorization: Bearer …` header parsing
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- authentication
Research direction
Start at the headers::authorization::Bearer implementation and run the test_invalid_auth_header example from the issue. Check parsing of malformed values, restricted token characters, extra spaces, and case-insensitive auth schemes; done means invalid headers fail and valid tokens are returned without surrounding whitespace.
Written by the indexing model from the issue text.
Description
The following test exposes a few issues in headers::authorization::Bearer:
#[cfg(test)]
mod tests {
#[test]
fn test_invalid_auth_header() {
// Malformed, should not parse.
let value = http::HeaderValue::from_str("Bearer foo, Bearer bar").unwrap();
use headers::authorization::Credentials;
let decoded = headers::authorization::Bearer::decode(&value);
println!("decoded = {:?}", decoded);
println!("if decoded succeeded, the token was: {:?}", decoded.as_ref().map(|b| b.token()));
// The header is malformed, so parsing should fail:
assert!(decoded.is_none());
}
}
Basically, Bearer's implementation will strip the leading string "Bearer " from the value, and return the remainder for as a token. This isn't valid according to the grammar for the Bearer authn scheme. (The grammar of the token itself is restricted to a certain set of characters, for example.) In fact, the code only checks that the header starts with Bearer in debug mode (as it is done w/ a debug_assert!), so in a release build, any value will parse, including, e.g., Basic <a basic headers' credentials>.
Even where the header is valid, and should parse, the .token() determines the token by simply removing "Bearer ".len() characters from the front of the header value, which itself is not correct: Bearer foobar (n.b., the double space; this is permitted by the grammar for the header, but is not part of the token) parses as it should, but .token() returns " foobar".
Last, the debug-mode-only debug_assert! asserts that the value starts with Bearer — but auth schemes in HTTP are case insensitive, so this too will reject valid inputs. (Note: the Basic auth-scheme parser shares its own version of this issue, too.)
- Dominant language
- Rust
- Stars
- 200
- Forks
- 107
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hyperium/headers
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Link support Open
Difficulty 4/5 3-5 days Newbie friendliness 38/100
All issues in hyperium/headers
Similar issues
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
n0-computer/iroh#4550 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
paritytech/zombienet-sdk#591 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
farion1231/cc-switch#7638 · 1 comment ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100