Issues with Chrome "prefetching" our IdP pages

[Howes, Nick]

Thanks all - I'll either see if ADFS would be able to use a POST binding for its request, or I'll teach our F5s to bounce away the prefetch requests as Alessandro describes. Currently our requests from ADFS are signed so there is something to be subverted if we were to allow replays.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Tuesday, October 16, 2018 1:04:33 PM
To: Shib Users
Subject: RE: Issues with Chrome "prefetching" our IdP pages

> Actually I think that chrome is indeed doing something "wrong" here, as typing
> an SP URI in Chrome browser will cause a background "prefetch" request to the
> SP which under certain circumstances** will cause subsequent prefetch to the
> IDP followed by a Replay Attack warning (in the IDP logs) once the user finishes
> typing the SP URI and presses enter (header is: "Purpose: prefetch")

But the point is that in HTTP a GET is supposed to be idempotent, and SSO protocols with message IDs and replay checking break that rule. Really the best thing to do is use POST for requests and that is perfectly allowed in SAML.

But as Nate said, my opinion on replay checks is about usability, not security. There is no good outcome that will ever be possible from a replay, and it's simply a matter of opinion what the "best" bad option is for usability.

We should have exposed an option to disable the checking but I don't think it ever got filed as a RFE so I never got around to it. It's possible, just not clean.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181017/36f00428/attachment.html>