问题
I am pretty sure my understanding is correct but since I cannot find any Google documentation that explicitly highlights this I wanted to ask here.
Per https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
And we know that when you create a trigger it will ask to authorize for all the scopes the script uses.
Then, that means that anyone with edit access to the script could leverage the Google identity of the user used to create the trigger to access the scopes the trigger is authorized for.
For example:
- User 1 creates a Google Apps Script that uses GmailApp to send an e-mail
(i.e.
GmailApp.sendEmail("one@example.com", "test subject", "email body");
) - User 1 creates a trigger to run said script every hour and authorizes it with the appropriate GmailApp scopes
- User 1 gives User 2 edit access to said script
Now, User 2 can go into said script and make changes to the code and access User 1's Gmail account. For example, user 2 could change the code to:
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
All they would have to do is make changes to the code and save; they wouldn't need to re-create the trigger since it already exists. And the next time the trigger runs it would run the newer/updated code.
I was able to confirm this behavior by creating a test script on one of my accounts and giving another account edit access.
So my question is, what is the official/recommended way to mitigate this risk? The obvious answer is to not give anyone else edit access but what if that is not an option -- what if for support purposes multiple people need to be able to access the script, then what?
回答1:
As you say, the only official/recommend way is to limit editing access to trusted persons.
In your particular example, User 1 could have chosen MailApp instead of GmailApp. The two seemingly redundant services are available separately because MailApp has very limited privledges exposed compared to GmailApp. (For instance, User 2 cannot search the victims Gmail with the MailApp service.)
You can collaborate while avoiding giving direct access to your script file using clasp
and git
. Only you push with clasp
to the script. Everyone else submits changes through git
. You can setup the system to be fully automatic (i.e. a git push
triggers a clasp push
) or manual (i.e. you review all changes first), bit either way you have good records of who did what, when with git
.
回答2:
There's inherent trust when you provide edit access to the script project. You either trust the person or don't trust them. There's no inbetween.
Some "theoretical" ways you may still protect the data:
- Create and use different Google accounts.
Install Triggers at the specific deployment/not at
Head
:- Possible only if done manually. Installable triggers created programmatically can only be used at
Head
- When you deploy a web-app/api, You can deploy it a specific version.
- This deployment version can then be provided, When you create a new trigger for a project here.
- There is no need for a working web-app/api. We're only looking to get a deployment id.
- In this way, even if user changes the script, your trigger will only run at the old version deployed.
- Deployed versions can be seen at Publish> Deploy from manifest.
- Possible only if done manually. Installable triggers created programmatically can only be used at
As the previous answer states,
git
would be a better call.
For all practical purposes, any data you share with a malicious entity should be considered compromised.
来源:https://stackoverflow.com/questions/57492862/securing-a-google-apps-script-linked-to-an-authorized-trigger-so-others-can-edit