OIDC fails from omnibox
Reported by
rkogelhe...@pingidentity.com,
May 9 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce the problem: To reproduce, a web app using cookies that are set and cleared at precise times is necessary. In this case the flow follows OIDC Basic Client Profile (https://openid.net/specs/openid-connect-basic-1_0.html) and in particular makes use of the state parameter described in 2.1.1.1 - "state - Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie." What is the expected behavior? When a user accesses a RP web site that uses OIDC, the user is redirected to the OP for authentication along with a state parameter. Upon return to the original site via callback, the state is compared to browser cookies in a conventional CSRF pattern. The browser should be performing this flow once. What went wrong? When this flow is performed via a link, there's no problem, when performing the flow by entering the RP URL into the omnibox, the process sometimes fails. Often it fails because the cookie necessary to verify the state is missing. Analysis via Fiddler shows that Chrome redirects twice to the OP at the same time. One for prerender and one "normal". When a failure occurs, the prerender has finished first and removed the required CSRF "nonce" cookie, preventing the RP from verifying that the state is correct. Prefetch / prerender should stop at the first redirect or the "real" request should "take over" from where prerender has reached at the time the user finishes in the omnibox. Chrome should likely not be performing two overlapping OIDC authentication flows. In the attached network log, the RP is https://f5af2.fmr.com/. The OP is https://pfprd.fmr.com/. The prefetch is in 96153 and the "real" request in 96175. 96153 completes the flow, but 96175 does not due to the CSRF cookie being cleared by 96153. Did this work before? No Chrome version: 66.0.3359.117 Channel: stable OS Version: Windows 7 Flash Version:
,
May 10 2018
rkogelheide@ Thanks for the issue. Request you to provide a sample file/test case where this issue can be reproduced and a screen cast of the steps followed will be helpful in further triaging of the issue. Thanks..
,
May 10 2018
Thanks for the analysis. Not sure exactly where to route this, but I am hoping the loader people would know who currently owns prerender.
,
May 11 2018
The issue could likely be replicated by an application that sets a cookie, redirects to itself with the cookie in a query parameter, then compares the cookie to the query parameter. If they're the same, it clears the cookie, if the cookie is not present, it displays an error. Something like that. It wouldn't reproduce the issue every time though. It would depend on timing. Perhaps it would also need to add a delay or several redirects to have a better chance of reproducing the issue. If I was to provide such a sample app, what should it be? A WAR? What would be preferred?
,
May 11 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 14 2018
rkogelheide@ Thanks for the update. This issue seems to out of scope of triaging from TE end. Hence as per comment #3, adding 'TE-NeedsTriageHelp' label and requesting someone from Blink>Loader team to look into this issue and hep in further triaging. Thanks..
,
May 15 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, May 10 2018