fix(ctap2): check status code in getNextAssertion#199
Open
AlfioEmanueleFresta wants to merge 2 commits into
Open
fix(ctap2): check status code in getNextAssertion#199AlfioEmanueleFresta wants to merge 2 commits into
AlfioEmanueleFresta wants to merge 2 commits into
Conversation
ctap2_get_next_assertion was the only CTAP2 method that did not match the response's status byte before parsing data. A non-OK status (e.g. CTAP2_ERR_NOT_ALLOWED when the 30-second window expires) was masked as PlatformError::InvalidDeviceResponse, and undefined trailing bytes after a non-OK status could be parsed as a valid assertion. Add the standard status_code match block and a regression test that asserts a non-OK status surfaces the correct CtapError variant.
AlfioEmanueleFresta
force-pushed
the
fix/ctap2-get-next-assertion-status-check
branch
from
e400d4b to
9f194fe
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every other CTAP2 method already checks the status byte and surfaces non-OK as a typed
CtapError;ctap2_get_next_assertionwas the lone exception. Without the check, a device returningCTAP2_ERR_NOT_ALLOWED(the spec-defined error when no further assertion is available within the 30-second window) is silently masked asInvalidDeviceResponse; worse, any bytes the device puts after a non-OK status byte (per CTAP 2.2 §8 they are undefined) would be parsed as a valid assertion.Changes
match cbor_response.status_codeblock at the top ofctap2_get_next_assertionso non-OK status codes surface asError::Ctap(<variant>)instead of being silently parsed.ctap2_get_info,ctap2_make_credential,ctap2_get_assertion,ctap2_get_next_assertion,ctap2_client_pin,ctap2_selection,ctap2_authenticator_config,ctap2_bio_enrollment,ctap2_credential_management) so a future contributor can't accidentally regress the pattern.References