If you’ve configured our Google Apps Login plugin, you will know that you need to create an OAuth2 ID and Secret through Google’s Cloud Developer Console. The project you create can contain your ‘product name’ and company or website logo so users understand who is behind your site when they come to Google’s authentication page where they grant permissions to your site to access their data.
Google has faced some problems recently where attackers have been using projects like these to trick users into authenticating to their malicious sites that spread themselves further to contacts in users’ Gmail address books. Some have even posed as Google Docs itself, which can easily fool people into believing a file has been shared with them, and that they are just clicking through to Google Drive.
New verification processes have recently been enforced by Google in an attempt to make it harder to create these projects for malicious use. Projects that intend to access Google Drive, for example, now need to be verified by Google’s review team. Some users (typically paid G Suite accounts) seem to be pre-authorized to create projects that don’t need to be submitted for review, but others will face an ‘Invalid Scope’ error when they try to ‘Add Google File’ through the Google Drive Embedder plugin.
Our Invalid Scope instructions explain how to cope with this. For testing purposes, users can join a Google-owned Group called ‘Risky Access By Unreviewed Apps’. To allow the wider audience to authenticate with your app, you will need to fill in Google’s form and wait for approval.
While we welcome Google taking steps to address the phishing problems, these steps cause issues for WordPress plugins or other products where customer installation requires many individual customers to create their own Google Cloud project with their own OAuth 2.0 Client IDs.
Many such products are asking people to blindly join the ‘Risky Access By Unreviewed Apps’ Google Group – leaving them open to attacks from elsewhere, just as before. The complication of filling in the form means that some products will now be even more inclined to rely on an ID/secret that is issued by the developer, and thus has the ID/secret pair exposed to the general public. These ID/secret pairs can be commandeered by phishers without any further verification checks.
To make things easier and safer for legitimate users who need to create Google applications, these are our recommendations to Google:
UPDATE: Google says they are rolling out improvements similar to some of the suggestions we made below, although we haven’t seen these changes in effect as of 19 July 2017: https://gsuite-developers.googleblog.com/2017/07/new-security-protections-to-reduce-risk.html
- Allow users to authenticate against an OAuth ID they created using the same account as the one being used to access the app
- Allow admins to whitelist specific ID/Secrets on their domain, and also allow any regular Gmail account to whitelist for their own use
- A clearer error message where unverified apps encounter ‘Invalid Scope’
- Documentation explaining the new verification processes they have rolled out
- A more robust and selective solution than joining the ‘Risky’ Group (Google already confirmed to us they are aware this cannot be a permanent solution)
To deter attackers, we recommend:
- Well-publicised reporting system for leaked ID/secrets – if anyone can provide an ID/secret for an ID they wish to report then no further checks really need to be made before disabling it
- Community trust/verification system – a big red warning on the authentication page of apps that are new and have a low number of users
- Better solution than joining the Group since this exposes many users to unverified apps