darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-07-19 05:53:51 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
d2784d0d8a823d0d9a6dcafe9a57f3e7876ad363
notifications-admin/tests/app/models/test_webauthn_credential.py

72 lines
5.2 KiB
Python
Raw Normal View History

Support registering a new authenticator This adds Yubico's FIDO2 library and two APIs for working with the "navigator.credentials.create()" function in JavaScript. The GET API uses the library to generate options for the "create()" function, and the POST API decodes and verifies the resulting credential. While the options and response are dict-like, CBOR is necessary to encode some of the byte-level values, which can't be represented in JSON. Much of the code here is based on the Yubico library example [1][2]. Implementation notes: - There are definitely better ways to alert the user about failure, but window.alert() will do for the time being. Using location.reload() is also a bit jarring if the page scrolls, but not a major issue. - Ideally we would use window.fetch() to do AJAX calls, but we don't have a polyfill for this, and we use $.ajax() elsewhere [3]. We need to do a few weird tricks [6] to stop jQuery trashing the data. - The FIDO2 server doesn't serve web requests; it's just a "server" in the sense of WebAuthn terminology. It lives in its own module, since it needs to be initialised with the app / config. - $.ajax returns a promise-like object. Although we've used ".fail()" elsewhere [3], I couldn't find a stub object that supports it, so I've gone for ".catch()", and used a Promise stub object in tests. - WebAuthn only works over HTTPS, but there's an exception for "localhost" [4]. However, the library is a bit too strict [5], so we have to disable origin verification to avoid needing HTTPS for dev work. [1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
import base64
Integrate with the API for adding and getting webauthn creds This links up the `get_webauthn_credentials_for_user` and `create_webauthn_credential_for_user` methods of the user api client to notifications-api. To send data to the API we need strings to be unicode, so we call decode('utf-8') on base64 objects. Co-authored-by: Leo Hemsted <leo.hemsted@digital.cabinet-office.gov.uk>
2021-05-13 15:54:05 +01:00
import pytest
Support registering a new authenticator This adds Yubico's FIDO2 library and two APIs for working with the "navigator.credentials.create()" function in JavaScript. The GET API uses the library to generate options for the "create()" function, and the POST API decodes and verifies the resulting credential. While the options and response are dict-like, CBOR is necessary to encode some of the byte-level values, which can't be represented in JSON. Much of the code here is based on the Yubico library example [1][2]. Implementation notes: - There are definitely better ways to alert the user about failure, but window.alert() will do for the time being. Using location.reload() is also a bit jarring if the page scrolls, but not a major issue. - Ideally we would use window.fetch() to do AJAX calls, but we don't have a polyfill for this, and we use $.ajax() elsewhere [3]. We need to do a few weird tricks [6] to stop jQuery trashing the data. - The FIDO2 server doesn't serve web requests; it's just a "server" in the sense of WebAuthn terminology. It lives in its own module, since it needs to be initialised with the app / config. - $.ajax returns a promise-like object. Although we've used ".fail()" elsewhere [3], I couldn't find a stub object that supports it, so I've gone for ".catch()", and used a Promise stub object in tests. - WebAuthn only works over HTTPS, but there's an exception for "localhost" [4]. However, the library is a bit too strict [5], so we have to disable origin verification to avoid needing HTTPS for dev work. [1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
from fido2 import cbor
from fido2.cose import ES256
Handle errors when registration fails Previously we would raise a 500 error in a variety of cases: - If a second key was being registered simultaneously (e.g. in a separate tab), which means the registration state could be missing after the first registration completes. That smells like an attack. - If the server-side verification failed e.g. origin verification, challenge verification, etc. The library seems to use 'ValueError' for all such errors [1] (after auditing its 'raise' statements, and excluding AttestationError [2], since we're not doing that). - If a key is used that attempts to sign with an unsupported algorithm. This would normally raise a NotImplemented error as part of verifying attestation [3], but we don't do that, so we need to verify the algorithm is supported by the library manually. This adds error handling to return a 400 response and error message in these cases, since the error is not unexpected (i.e. not a 500). A 400 seems more appropriate than a 403, since in many cases it's not clear if the request data is valid. I've used CBOR for the transport encoding, to match the successful request / response encoding. Note that the ordering of then/catch matters in JS - we don't want to catch our own throws! [1]: https://github.com/Yubico/python-fido2/blob/142587b3e698ca0e253c78d75758fda635cac51a/fido2/server.py#L255 [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/attestation/base.py#L39 [3]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/cose.py#L92
2021-05-14 09:17:12 +01:00
from app.models.webauthn_credential import RegistrationError, WebAuthnCredential
Support registering a new authenticator This adds Yubico's FIDO2 library and two APIs for working with the "navigator.credentials.create()" function in JavaScript. The GET API uses the library to generate options for the "create()" function, and the POST API decodes and verifies the resulting credential. While the options and response are dict-like, CBOR is necessary to encode some of the byte-level values, which can't be represented in JSON. Much of the code here is based on the Yubico library example [1][2]. Implementation notes: - There are definitely better ways to alert the user about failure, but window.alert() will do for the time being. Using location.reload() is also a bit jarring if the page scrolls, but not a major issue. - Ideally we would use window.fetch() to do AJAX calls, but we don't have a polyfill for this, and we use $.ajax() elsewhere [3]. We need to do a few weird tricks [6] to stop jQuery trashing the data. - The FIDO2 server doesn't serve web requests; it's just a "server" in the sense of WebAuthn terminology. It lives in its own module, since it needs to be initialised with the app / config. - $.ajax returns a promise-like object. Although we've used ".fail()" elsewhere [3], I couldn't find a stub object that supports it, so I've gone for ".catch()", and used a Promise stub object in tests. - WebAuthn only works over HTTPS, but there's an exception for "localhost" [4]. However, the library is a bit too strict [5], so we have to disable origin verification to avoid needing HTTPS for dev work. [1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
# noqa adapted from https://github.com/duo-labs/py_webauthn/blob/90e3d97e0182899a35a70fc510280b4082cce19b/tests/test_webauthn.py#L14-L24
SESSION_STATE = {'challenge': 'bPzpX3hHQtsp9evyKYkaZtVc9UN07PUdJ22vZUdDp94', 'user_verification': 'discouraged'}
CLIENT_DATA_JSON = b'{"type": "webauthn.create", "clientExtensions": {}, "challenge": "bPzpX3hHQtsp9evyKYkaZtVc9UN07PUdJ22vZUdDp94", "origin": "https://webauthn.io"}' # noqa
# had to use the cbor2 library to re-encode the attestationObject due to implementation differences
ATTESTATION_OBJECT = base64.b64decode(b'o2NmbXRoZmlkby11MmZnYXR0U3RtdKJjc2lnWEgwRgIhAI1qbvWibQos/t3zsTU05IXw1Ek3SDApATok09uc4UBwAiEAv0fB/lgb5Ot3zJ691Vje6iQLAtLhJDiA8zDxaGjcE3hjeDVjgVkCUzCCAk8wggE3oAMCAQICBDxoKU0wDQYJKoZIhvcNAQELBQAwLjEsMCoGA1UEAxMjWXViaWNvIFUyRiBSb290IENBIFNlcmlhbCA0NTcyMDA2MzEwIBcNMTQwODAxMDAwMDAwWhgPMjA1MDA5MDQwMDAwMDBaMDExLzAtBgNVBAMMJll1YmljbyBVMkYgRUUgU2VyaWFsIDIzOTI1NzM0ODExMTE3OTAxMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvd9nk9t3lMNQMXHtLE1FStlzZnUaSLql2fm1ajoggXlrTt8rzXuSehSTEPvEaEdv/FeSqX22L6Aoa8ajIAIOY6M7MDkwIgYJKwYBBAGCxAoCBBUxLjMuNi4xLjQuMS40MTQ4Mi4xLjUwEwYLKwYBBAGC5RwCAQEEBAMCBSAwDQYJKoZIhvcNAQELBQADggEBAKrADVEJfuwVpIazebzEg0D4Z9OXLs5qZ/ukcONgxkRZ8K04QtP/CB5x6olTlxsj+SXArQDCRzEYUgbws6kZKfuRt2a1P+EzUiqDWLjRILSr+3/o7yR7ZP/GpiFKwdm+czb94POoGD+TS1IYdfXj94mAr5cKWx4EKjh210uovu/pLdLjc8xkQciUrXzZpPR9rT2k/q9HkZhHU+NaCJzky+PTyDbq0KKnzqVhWtfkSBCGw3ezZkTS+5lrvOKbIa24lfeTgu7FST5OwTPCFn8HcfWZMXMSD/KNU+iBqJdAwTLPPDRoLLvPTl29weCAIh+HUpmBQd0UltcPOrA/LFvAf61oYXV0aERhdGFYwnSm6pITyZwvdLIkkrMgz0AmKpTBqVCgOX8pJQtghB7wQQAAAAAAAAAAAAAAAAAAAAAAAAAAAECKU1ppjl9gmhHWyDkgHsUvZmhr6oF3/lD3llzLE2SaOSgOGIsIuAQqgp8JQSUu3r/oOaP8RS44dlQjrH+ALfYtpAECAyYhWCAxnqAfESXOYjKUc2WACuXZ3ch0JHxV0VFrrTyjyjIHXCJYIFnx8H87L4bApR4M+hPcV+fHehEOeW+KCyd0H+WGY8s6') # noqa
Handle errors when registration fails Previously we would raise a 500 error in a variety of cases: - If a second key was being registered simultaneously (e.g. in a separate tab), which means the registration state could be missing after the first registration completes. That smells like an attack. - If the server-side verification failed e.g. origin verification, challenge verification, etc. The library seems to use 'ValueError' for all such errors [1] (after auditing its 'raise' statements, and excluding AttestationError [2], since we're not doing that). - If a key is used that attempts to sign with an unsupported algorithm. This would normally raise a NotImplemented error as part of verifying attestation [3], but we don't do that, so we need to verify the algorithm is supported by the library manually. This adds error handling to return a 400 response and error message in these cases, since the error is not unexpected (i.e. not a 500). A 400 seems more appropriate than a 403, since in many cases it's not clear if the request data is valid. I've used CBOR for the transport encoding, to match the successful request / response encoding. Note that the ordering of then/catch matters in JS - we don't want to catch our own throws! [1]: https://github.com/Yubico/python-fido2/blob/142587b3e698ca0e253c78d75758fda635cac51a/fido2/server.py#L255 [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/attestation/base.py#L39 [3]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/cose.py#L92
2021-05-14 09:17:12 +01:00
# manually adapted by working out which character in the encoded CBOR corresponds to the public key algorithm ID
UNSUPPORTED_ATTESTATION_OBJECT = base64.b64decode(b'o2NmbXRoZmlkby11MmZnYXR0U3RtdKJjc2lnWEgwRgIhAI1qbvWibQos/t3zsTU05IXw1Ek3SDApATok09uc4UBwAiEAv0fB/lgb5Ot3zJ691Vje6iQLAtLhJDiA8zDxaGjcE3hjeDVjgVkCUzCCAk8wggE3oAMCAQICBDxoKU0wDQYJKoZIhvcNAQELBQAwLjEsMCoGA1UEAxMjWXViaWNvIFUyRiBSb290IENBIFNlcmlhbCA0NTcyMDA2MzEwIBcNMTQwODAxMDAwMDAwWhgPMjA1MDA5MDQwMDAwMDBaMDExLzAtBgNVBAMMJll1YmljbyBVMkYgRUUgU2VyaWFsIDIzOTI1NzM0ODExMTE3OTAxMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvd9nk9t3lMNQMXHtLE1FStlzZnUaSLql2fm1ajoggXlrTt8rzXuSehSTEPvEaEdv/FeSqX22L6Aoa8ajIAIOY6M7MDkwIgYJKwYBBAGCxAoCBBUxLjMuNi4xLjQuMS40MTQ4Mi4xLjUwEwYLKwYBBAGC5RwCAQEEBAMCBSAwDQYJKoZIhvcNAQELBQADggEBAKrADVEJfuwVpIazebzEg0D4Z9OXLs5qZ/ukcONgxkRZ8K04QtP/CB5x6olTlxsj+SXArQDCRzEYUgbws6kZKfuRt2a1P+EzUiqDWLjRILSr+3/o7yR7ZP/GpiFKwdm+czb94POoGD+TS1IYdfXj94mAr5cKWx4EKjh210uovu/pLdLjc8xkQciUrXzZpPR9rT2k/q9HkZhHU+NaCJzky+PTyDbq0KKnzqVhWtfkSBCGw3ezZkTS+5lrvOKbIa24lfeTgu7FST5OwTPCFn8HcfWZMXMSD/KNU+iBqJdAwTLPPDRoLLvPTl29weCAIh+HUpmBQd0UltcPOrA/LFvAf61oYXV0aERhdGFYwnSm6pITyZwvdLIkkrMgz0AmKpTBqVCgOX8pJQtghB7wQQAAAAAAAAAAAAAAAAAAAAAAAAAAAECKU1ppjl9gmhHWyDkgHsUvZmhr6oF3/lD3llzLE2SaOSgOGIsIuAQqgp8JQSUu3r/oOaP8RS44dlQjrH+ALfYtpAECAyUhWCAxnqAfESXOYjKUc2WACuXZ3ch0JHxV0VFrrTyjyjIHXCJYIFnx8H87L4bApR4M+hPcV+fHehEOeW+KCyd0H+WGY8s6') # noqa
Support registering a new authenticator This adds Yubico's FIDO2 library and two APIs for working with the "navigator.credentials.create()" function in JavaScript. The GET API uses the library to generate options for the "create()" function, and the POST API decodes and verifies the resulting credential. While the options and response are dict-like, CBOR is necessary to encode some of the byte-level values, which can't be represented in JSON. Much of the code here is based on the Yubico library example [1][2]. Implementation notes: - There are definitely better ways to alert the user about failure, but window.alert() will do for the time being. Using location.reload() is also a bit jarring if the page scrolls, but not a major issue. - Ideally we would use window.fetch() to do AJAX calls, but we don't have a polyfill for this, and we use $.ajax() elsewhere [3]. We need to do a few weird tricks [6] to stop jQuery trashing the data. - The FIDO2 server doesn't serve web requests; it's just a "server" in the sense of WebAuthn terminology. It lives in its own module, since it needs to be initialised with the app / config. - $.ajax returns a promise-like object. Although we've used ".fail()" elsewhere [3], I couldn't find a stub object that supports it, so I've gone for ".catch()", and used a Promise stub object in tests. - WebAuthn only works over HTTPS, but there's an exception for "localhost" [4]. However, the library is a bit too strict [5], so we have to disable origin verification to avoid needing HTTPS for dev work. [1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
Fix app config leaking between tests We need to re-initialise the webauthn_server module with original app config, since this state is global across all tests. Since the behaviour of the original fixture wasn't specific to verifying the origin, I've renamed the fixture as part of making it global. In order to keep the fixture simple, I've rewritten the test for the webauthn_server module, so they don't touch the app fixture.
2021-05-17 11:37:47 +01:00
def test_from_registration_verifies_response(webauthn_dev_server):
Support registering a new authenticator This adds Yubico's FIDO2 library and two APIs for working with the "navigator.credentials.create()" function in JavaScript. The GET API uses the library to generate options for the "create()" function, and the POST API decodes and verifies the resulting credential. While the options and response are dict-like, CBOR is necessary to encode some of the byte-level values, which can't be represented in JSON. Much of the code here is based on the Yubico library example [1][2]. Implementation notes: - There are definitely better ways to alert the user about failure, but window.alert() will do for the time being. Using location.reload() is also a bit jarring if the page scrolls, but not a major issue. - Ideally we would use window.fetch() to do AJAX calls, but we don't have a polyfill for this, and we use $.ajax() elsewhere [3]. We need to do a few weird tricks [6] to stop jQuery trashing the data. - The FIDO2 server doesn't serve web requests; it's just a "server" in the sense of WebAuthn terminology. It lives in its own module, since it needs to be initialised with the app / config. - $.ajax returns a promise-like object. Although we've used ".fail()" elsewhere [3], I couldn't find a stub object that supports it, so I've gone for ".catch()", and used a Promise stub object in tests. - WebAuthn only works over HTTPS, but there's an exception for "localhost" [4]. However, the library is a bit too strict [5], so we have to disable origin verification to avoid needing HTTPS for dev work. [1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
registration_response = {
'clientDataJSON': CLIENT_DATA_JSON,
'attestationObject': ATTESTATION_OBJECT,
}
credential = WebAuthnCredential.from_registration(SESSION_STATE, registration_response)
assert credential.name == 'Unnamed key'
Integrate with the API for adding and getting webauthn creds This links up the `get_webauthn_credentials_for_user` and `create_webauthn_credential_for_user` methods of the user api client to notifications-api. To send data to the API we need strings to be unicode, so we call decode('utf-8') on base64 objects. Co-authored-by: Leo Hemsted <leo.hemsted@digital.cabinet-office.gov.uk>
2021-05-13 15:54:05 +01:00
assert credential.registration_response == base64.b64encode(cbor.encode(registration_response)).decode('utf-8')
Support registering a new authenticator This adds Yubico's FIDO2 library and two APIs for working with the "navigator.credentials.create()" function in JavaScript. The GET API uses the library to generate options for the "create()" function, and the POST API decodes and verifies the resulting credential. While the options and response are dict-like, CBOR is necessary to encode some of the byte-level values, which can't be represented in JSON. Much of the code here is based on the Yubico library example [1][2]. Implementation notes: - There are definitely better ways to alert the user about failure, but window.alert() will do for the time being. Using location.reload() is also a bit jarring if the page scrolls, but not a major issue. - Ideally we would use window.fetch() to do AJAX calls, but we don't have a polyfill for this, and we use $.ajax() elsewhere [3]. We need to do a few weird tricks [6] to stop jQuery trashing the data. - The FIDO2 server doesn't serve web requests; it's just a "server" in the sense of WebAuthn terminology. It lives in its own module, since it needs to be initialised with the app / config. - $.ajax returns a promise-like object. Although we've used ".fail()" elsewhere [3], I couldn't find a stub object that supports it, so I've gone for ".catch()", and used a Promise stub object in tests. - WebAuthn only works over HTTPS, but there's an exception for "localhost" [4]. However, the library is a bit too strict [5], so we have to disable origin verification to avoid needing HTTPS for dev work. [1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html [3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33 [4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server [5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69 [6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
credential_data = credential.to_credential_data()
assert type(credential_data.credential_id) is bytes
assert type(credential_data.aaguid) is bytes
assert credential_data.public_key[3] == ES256.ALGORITHM
Integrate with the API for adding and getting webauthn creds This links up the `get_webauthn_credentials_for_user` and `create_webauthn_credential_for_user` methods of the user api client to notifications-api. To send data to the API we need strings to be unicode, so we call decode('utf-8') on base64 objects. Co-authored-by: Leo Hemsted <leo.hemsted@digital.cabinet-office.gov.uk>
2021-05-13 15:54:05 +01:00
Fix app config leaking between tests We need to re-initialise the webauthn_server module with original app config, since this state is global across all tests. Since the behaviour of the original fixture wasn't specific to verifying the origin, I've renamed the fixture as part of making it global. In order to keep the fixture simple, I've rewritten the test for the webauthn_server module, so they don't touch the app fixture.
2021-05-17 11:37:47 +01:00
def test_from_registration_encodes_as_unicode(webauthn_dev_server):
Integrate with the API for adding and getting webauthn creds This links up the `get_webauthn_credentials_for_user` and `create_webauthn_credential_for_user` methods of the user api client to notifications-api. To send data to the API we need strings to be unicode, so we call decode('utf-8') on base64 objects. Co-authored-by: Leo Hemsted <leo.hemsted@digital.cabinet-office.gov.uk>
2021-05-13 15:54:05 +01:00
registration_response = {
'clientDataJSON': CLIENT_DATA_JSON,
'attestationObject': ATTESTATION_OBJECT,
}
credential = WebAuthnCredential.from_registration(SESSION_STATE, registration_response)
serialized_credential = credential.serialize()
assert type(serialized_credential['credential_data']) == str
assert type(serialized_credential['registration_response']) == str
Handle errors when registration fails Previously we would raise a 500 error in a variety of cases: - If a second key was being registered simultaneously (e.g. in a separate tab), which means the registration state could be missing after the first registration completes. That smells like an attack. - If the server-side verification failed e.g. origin verification, challenge verification, etc. The library seems to use 'ValueError' for all such errors [1] (after auditing its 'raise' statements, and excluding AttestationError [2], since we're not doing that). - If a key is used that attempts to sign with an unsupported algorithm. This would normally raise a NotImplemented error as part of verifying attestation [3], but we don't do that, so we need to verify the algorithm is supported by the library manually. This adds error handling to return a 400 response and error message in these cases, since the error is not unexpected (i.e. not a 500). A 400 seems more appropriate than a 403, since in many cases it's not clear if the request data is valid. I've used CBOR for the transport encoding, to match the successful request / response encoding. Note that the ordering of then/catch matters in JS - we don't want to catch our own throws! [1]: https://github.com/Yubico/python-fido2/blob/142587b3e698ca0e253c78d75758fda635cac51a/fido2/server.py#L255 [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/attestation/base.py#L39 [3]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/cose.py#L92
2021-05-14 09:17:12 +01:00
Rename "app_" fixture to "notify_admin" This naming was introduced in 2016 without explanation [1]. I find it confusing because: - It's reminiscent of "_app", which is a Python convention indicating the variable is internal, so maybe avoid using it. - It suggests there's some other "app" fixture I should be using (there isn't, though). The Python style guide describes using an underscore suffix to avoid clashes with inbuilt names [1], which is sort of applicable if we need to import the "app" module [2]. However, we can also avoid clashes by choosing a different name, without the strange underscore. [1]: https://github.com/alphagov/notifications-admin/commit/3b1d521c10a515dab85700a1103912cf47ed414c [2]: https://github.com/alphagov/notifications-admin/blob/78824f54fdf7288172387f8ed3b332d26d74e083/tests/app/main/views/test_forgot_password.py#L5
2021-05-12 14:57:21 +01:00
def test_from_registration_handles_library_errors():
Handle errors when registration fails Previously we would raise a 500 error in a variety of cases: - If a second key was being registered simultaneously (e.g. in a separate tab), which means the registration state could be missing after the first registration completes. That smells like an attack. - If the server-side verification failed e.g. origin verification, challenge verification, etc. The library seems to use 'ValueError' for all such errors [1] (after auditing its 'raise' statements, and excluding AttestationError [2], since we're not doing that). - If a key is used that attempts to sign with an unsupported algorithm. This would normally raise a NotImplemented error as part of verifying attestation [3], but we don't do that, so we need to verify the algorithm is supported by the library manually. This adds error handling to return a 400 response and error message in these cases, since the error is not unexpected (i.e. not a 500). A 400 seems more appropriate than a 403, since in many cases it's not clear if the request data is valid. I've used CBOR for the transport encoding, to match the successful request / response encoding. Note that the ordering of then/catch matters in JS - we don't want to catch our own throws! [1]: https://github.com/Yubico/python-fido2/blob/142587b3e698ca0e253c78d75758fda635cac51a/fido2/server.py#L255 [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/attestation/base.py#L39 [3]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/cose.py#L92
2021-05-14 09:17:12 +01:00
registration_response = {
'clientDataJSON': CLIENT_DATA_JSON,
'attestationObject': ATTESTATION_OBJECT,
}
with pytest.raises(RegistrationError) as exc_info:
WebAuthnCredential.from_registration(SESSION_STATE, registration_response)
assert 'Invalid origin' in str(exc_info.value)
Fix app config leaking between tests We need to re-initialise the webauthn_server module with original app config, since this state is global across all tests. Since the behaviour of the original fixture wasn't specific to verifying the origin, I've renamed the fixture as part of making it global. In order to keep the fixture simple, I've rewritten the test for the webauthn_server module, so they don't touch the app fixture.
2021-05-17 11:37:47 +01:00
def test_from_registration_handles_unsupported_keys(webauthn_dev_server):
Handle errors when registration fails Previously we would raise a 500 error in a variety of cases: - If a second key was being registered simultaneously (e.g. in a separate tab), which means the registration state could be missing after the first registration completes. That smells like an attack. - If the server-side verification failed e.g. origin verification, challenge verification, etc. The library seems to use 'ValueError' for all such errors [1] (after auditing its 'raise' statements, and excluding AttestationError [2], since we're not doing that). - If a key is used that attempts to sign with an unsupported algorithm. This would normally raise a NotImplemented error as part of verifying attestation [3], but we don't do that, so we need to verify the algorithm is supported by the library manually. This adds error handling to return a 400 response and error message in these cases, since the error is not unexpected (i.e. not a 500). A 400 seems more appropriate than a 403, since in many cases it's not clear if the request data is valid. I've used CBOR for the transport encoding, to match the successful request / response encoding. Note that the ordering of then/catch matters in JS - we don't want to catch our own throws! [1]: https://github.com/Yubico/python-fido2/blob/142587b3e698ca0e253c78d75758fda635cac51a/fido2/server.py#L255 [2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/attestation/base.py#L39 [3]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/cose.py#L92
2021-05-14 09:17:12 +01:00
registration_response = {
'clientDataJSON': CLIENT_DATA_JSON,
'attestationObject': UNSUPPORTED_ATTESTATION_OBJECT,
}
with pytest.raises(RegistrationError) as exc_info:
WebAuthnCredential.from_registration(SESSION_STATE, registration_response)
assert 'Encryption algorithm not supported' in str(exc_info.value)
Reference in New Issue Copy Permalink