Issues with Chrome "prefetching" our IdP pages

[alessandro at avagliano.berlin]

> Technically I suppose Chrome isn't doing anything wrong because it's a
> GET request which it's free to request whenever it feels like it, but
> it'd be good if there were a way to opt out through headers. I'll try
> various responses to the requests with the "Purpose: prefetch" header.
>
>

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")

Now it might be possible to:

- ignore the issue at all and ask the user to open the SP URI again (...)
- disable this behavior in chrome (obviously not feasible for those who
have publicly exposed SP/IDPs)
- open a discussion on the topic with google
- disabling replay attack detection as mentioned by Scott (although he
is not recommending it)

or try in some other ways. The approach I'm testing is by "ignoring" the
"prefetch" requests on the IDP side by detecting the header that Chrome
uses while it performs those requests in the background, preventing the
request from reaching the shibboleth back-end and consequently avoiding
the further round-trip that IDP<--->SP perform after the replay attack
error. Its relatively easy to test if you have an NGINX/Apache in front
of your jetty instance.

I have no other possible/better work-around/solutions in mind at the
moment, ping me if you do :D

Best,
Alessandro

** When Chrome has no tcp connection to the SP open, and the user has no
session on the SP, which will cause a redirect to the SP

> Nick
>
> ------------------------------------------------------------------------
> *From:* users <users-bounces at shibboleth.net> on behalf of Feyaerts
> Vincent <vincent.feyaerts at uantwerpen.be>
> *Sent:* 26 September 2018 10:12:41
> *To:* users at shibboleth.net
> *Subject:* Issues with Chrome "prefetching" our IdP pages
>  
>
> Hi,
>
>  
>
> We have a set-up consisting of ADFS+Shibboleth 3 IdP. ADFS is the
> slave SP. Both are load balanced behind a Big-IP F5 LTM. Our problem
> is not really related to this set-up. I think it might occur in any
> normal IdP deployment.
>
>  
>
> The Shibboleth IdP back-end logs are full of messages like:
>
>  
>
> /org.opensaml.messaging.handler.MessageHandlerException: Rejecting
> replayed message ID 'id-f7e02f5c-843f-4d3d-88af-168b8a79653e' from
> issuer http://url/adfs/services/trust/
>
> /        at
> org.opensaml.saml.common.binding.security.impl.MessageReplaySecurityHandler.doInvoke(MessageReplaySecurityHandler.java:157)/
>
>  
>
> I checked our logs of the load balancer, the client does indeed
> request the URL with the SAMLRequest referencing that ID twice. Now,
> it appears one of those requests has a header “Purpose prefetch”. This
> is a Google Chrome header. Now, I have no idea why it would prefetch
> these pages but it does.
>
>  
>
> Technically speaking this might be a Chrome problem, but it interferes
> with a normal Shibboleth IdP from working, and I hope somebody else
> has found a way to fix this on the IdP, because I can’t change Chrome.
>
>  
>
> I tried sending a 403 as a response to the Prefetch request, but then
> Chrome just stops and won’t ask again.
>
>  
>
> Regards
>
> Vincent Feyaerts
>
>  
>
>  
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181016/e8b8867b/attachment.html>