Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to "prevent reuse of a $messageId to stop replay attacks"? #164

Open
hagabaka opened this issue Oct 22, 2018 · 1 comment
Open

How to "prevent reuse of a $messageId to stop replay attacks"? #164

hagabaka opened this issue Oct 22, 2018 · 1 comment

Comments

@hagabaka
Copy link

hagabaka commented Oct 22, 2018

In the README, it says

            $messageId = $event->getSaml2Auth()->getLastMessageId();
            // your own code preventing reuse of a $messageId to stop replay attacks

My first thought is to have a table storing past messageIds and reject the request is the messageId is already found. But the table would continue to grow larger, as long as users keep getting logged in. If I can access the message's NotOnOrAfter date, I can safely delete messages that are past their valid date. But the library doesn't seem to provide an easy way to access that. Would I have to use Saml2User::getRawSamlAssertion() and parse it with php-saml?

@darynmitchell
Copy link
Contributor

OneLogin says readme, in its brief section Replay Attacks,

Messages expires and will be invalidated due that fact, you don't need to store those IDs longer than the time frame that you currently accepting.

So it appears that if you add a getter to Saml2Auth that returns the result of OneLogin\Saml2\Auth::getLastAssertionNotOnOrAfter(), then you can use that time plus a drift constant (see below)* to expire the message in your own record, because OneLogin's Response::isValid() function will reject the message replay if it arrives after its 'NotOnOrAfter' time.

* OneLogin\Saml2\Constants::ALLOWED_CLOCK_DRIFT adds 3 minutes leeway (current implementation), so you need to add that to the message expiry time when deciding on the minimum how long to store the message.


As for how you could deal with the expiry, Laravel's built-in file cache accepts an expiry time parameter, as described in section 'Storing Items In The Cache' of Cache Usage

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants