Google App Scripts warning

[synaesthesia]

Hi, the Edugeek Edit announcement this morning made me think I should pop this post up further to an issue I mentioned before half term, with regards to App Scripts.

If you use Google Workspace, or at least enough to make use of App Scripts and linked systems (Google Cloud Projects and of course the linked OAuth APIs) please note that app scripts are just as, if not more dangerous than the old Excel Macros we spent years worrying about, and default settings from Google are not enough to prevent attacks.

By default, all "internally created" app scripts are given full trust, and are able to request access to any oauth API without further checking. 

This hit us by means of student accounts being compromised, a script uploaded to their Drive (therefore "internal") and executed, giving permission for anonymous actors to use their account without authorisation as a spam relay. We were lucky - the very same script could be easily amended by someone with limited knowledge to gain access to any API including Drive, Classrooms or more.

Obviously with staff accounts or anything with higher privileges this type of attack should be pretty much stopped in it's tracks thanks to MFA, but with students this isn't quite so easy. Not to say MFA is infallible, as it isn't. It's therefore imperative to lock permissions down in Workspace admin.

 

This isn't just about attacks either, it also involves good practice with staff and the prevalence of "Sign in with Google" prompts. Also by default, anyone over 18 can visit a website, think "ooooh this looks nice", clicks "Sign in with Google", logs in with their school account and before you know it, that member of SLT has granted access to TheirFavouriteAdultEntertainmentSitewithDodgyPeopleOnTheSide.com for Email, Drive and Limited Google Admin because they just so happened to have access to reset student and staff passwords and didn't think twice about the permissions they were granting.

So as part of the same settings, it's very good practice to lock these all down.

 

1. Remove the automatic trust of local scripts.
2. Remove the ability for students to click "Log in with Google" on anything. If they should have that, you'd have already seen the DPIA or notified that it's been cleared, along with the site and you've already set up permissions.
3. Remove the ability to staff to allow any more than basic access to Log in with Google but allow them to request permission.

 

So when they sign up for TeacherResources.com, pay for it themselves, don't fill out a DPIA or do the necessary checks and come to you to ask why it isn't working, you now have a traceable record to hand to their line manager and Finance  Plus of course you then have an auditable log of what services have access to what data.

 

Hopefully this is of some help to people!

Edited June 2 by ZeroHour
Just some formatting - ZH

[jthompson]

Allowlisting third-party apps, including for the "Sign in with Google" scope, is important, yes. I have a feeling that the default stance for a new Worskpace tenancy is now helpfully less open by default in that regard now (don't quote me though).

The settings for that I think are Admin -> Security -> Access and data control -> Settings ("Unconfigured third-party apps" is where you're able to restrict use of Sign in with Google).

For Chrome extension allowlisting, you'd need Admin -> Devices -> Chrome -> Apps & extensions -> User app settings -> Allow/block mode.

 

Would recommend maintaining a separate list of which apps and extensions have been allowlisted and why.

 

I'd not considered the option for not trusting internal apps (i.e. covering internal Apps Script projects), but will have to consider that now after reading your anecdote. We make heavy use of Apps Script amongst staff here, so would be a bit of a job to maintain.

Edited June 2 by jthompson

[synaesthesia]

4 minutes ago, jthompson said:

I'd not considered the option for not trusting internal apps (i.e. covering internal Apps Script projects), but will have to consider that now after reading your anecdote. We make heavy use of Apps Script amongst staff here, so would be a bit of a job to maintain.

Yes, this was a nightmare - especially as the vast majority of people just make the script from a copy & paste job, click save and off they go. Nearly always called "Untitled Project" - so imagine the fun when I removed permissions for every single Untitled Project for the trust! (We asked them to rename them, with instructions, first). It's a royal pain in the bum for existing/long standard tenants  It doesn't of course mean that's the only problem, there's nothing stopping a bad actor from calling their dodgy script "Completely_Normal_MIS_Sync_Project_Honest.json"

 

I'm not sure how widespread this particular issue is, it feels sort of targeted in our case but no real way of knowing and there isn't a huge amount in the wild when searching for it!

[jthompson]

Interesting.

 

Gemini provides this tip to simplify the allowlisting required.

 

## 💡 Pro-Tip for Easier Long-Term Management

If your team writes a lot of internal Apps Scripts, mapping individual default client IDs can become a massive administrative headache.

**The Best Practice:** Link your important Apps Script projects to a **Standard Google Cloud Project** instead of using the default automatic ones.

* By creating a central "Internal Tools" project in the Google Cloud Console, you can link multiple Apps Scripts to it.
* This gives you a single, permanent OAuth Client ID to approve in Google Admin once, and any script tied to that GCP project will automatically be trusted.

[synaesthesia]

Oooh, I'll have a look into that. I take anything Gemini says with a pinch of salt, even when it is regarding Google's own products - ironically it seems to be more accurate at feeding me 365 information than Google stuff!  Google's own support were aware of it being a possible issue but were not forthcoming with any best practices, so this is definitely worth putting some time into. Particularly considering how difficult it is to match up project ID's with the entirely different ID it generates for oauth requests  - that's one thing Gemini could do better than Google's own support though!

[jthompson]

It doesn't look like you can allowlist particular deployments of an Apps Script project though, as in the fixed versions that you can create that then can't be altered. I use those whenever I've got something automated with triggers, so that nothing in production gets broken when fiddling around with the code to make improvements.

Edited June 2 by jthompson