Implement replay attack mitigation for SAML auth.
Review Request #12476 — Created July 18, 2022 and submitted
SAML is generally quite secure by design, but if there's a man in the
middle, it is susceptible to replay attacks (within a short limited time
frame). The way this is mitigated is by giving every message and
assertion a unique ID. The service provider can then store these IDs and
make sure that they haven't already been used.This change implements that. The used IDs are kept in the cache, and
checked before we proceed. While using the cache for this isn't 100%
reliable, given the very short message lifetime, it's good enough for
our purposes.
- Ran unit tests.
- Verified that I could still log in with SAML.
- Crafted a replay and saw that it was successfully blocked.
Summary | ID |
---|---|
d2a809773ca78f6fc3ebd1360bb521711c33b842 |
Description | From | Last Updated |
---|---|---|
Can get rid of this TODO. Should we be checking the request ID too? |
maubin | |
The docstring says POST but the method is GET. |
maubin | |
Here we're checking the message and request, but in the other view we check the message and assertion. What's the … |
maubin | |
Can get rid of this. |
maubin | |
True is a literal here, but False is not. |
chipx86 | |
Can we go with the usual form of Testing <thing> with <conditions>? Same below. |
chipx86 |
- Commits:
-
Summary ID 6bca24e462426e7467deb486235a2cd112f49e74 2c51fb62c47a4ad4613791ee7d50abd730bb9a29
Checks run (2 succeeded)
- Commits:
-
Summary ID 2c51fb62c47a4ad4613791ee7d50abd730bb9a29 326f734aaebef26c736d1e8cc03d8186417c7a94