T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- index.py:29
- Finding
- Overprivileged Gmail Access Through Domain-Wide Delegation## Vulnerability Details **File Location**: `index.py`, lines 29–33 **Vulnerability Type**: Excessive delegated permissions and violation of least privilege **Risk Level**: High ### Vulnerable Code ```python SCOPES = ['https://www.googleapis.com/auth/gmail.modify'] credentials = service_account.Credentials.from_service_account_info( self.service_account, scopes=SCOPES, subject=self.user_email ) self.gmail = build('gmail', 'v1', credentials=credentials) ``` ### Technical Analysis The application creates Google Workspace credentials using a service account with domain-wide delegation and impersonates the user specified by `self.user_email`. It requests the broad `gmail.modify` OAuth scope. The implemented workflow sends messages and searches for bounce and unsubscribe messages. It does not need general mailbox modification privileges. The delegated `gmail.modify` scope permits substantially more access than required, including reading mailbox content and modifying mailbox state. Because domain-wide delegation bypasses ordinary per-user consent, compromise or unauthorized use of the service-account credential would allow an attacker to assume the configured user's delegated Gmail privileges. Whether other domain users could also be impersonated depends on the Google Workspace delegation policy and service-account authorization configured outside this repository. ### Attack Path 1. An attacker obtains access to the Google service-account credential used by the application. The configured credential location is disclosed in `config/settings.json`, although the credential itself is not included in the audited project. 2. The attacker constructs delegated Google credentials using the service account and an authorized Workspace user as the impersonation subject. 3. The attacker requests the already authorized `gmail.modify` scope. 4. The attacker uses Gmail API operations beyond the application's legitimate sending and search requirements. 5. Within the per ...[truncated 916 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `gmail.modify` with the minimum scopes required: - Use `https://www.googleapis.com/auth/gmail.send` for message delivery. - Add only the narrowest Gmail read or metadata scope that supports the required bounce and unsubscribe searches. 2. If Gmail's available narrow scopes cannot support the search workflow, separate sending and inbox processing into distinct identities or services so the bulk sender does not retain mailbox-modification access. 3. Restrict Google Workspace domain-wide delegation to explicitly approved OAuth scopes and dedicated campaign identities. 4. Use a dedicated campaign mailbox rather than a general-purpose employee mailbox. 5. Store the service-account credential in a managed secret store with strict filesystem and IAM controls. Do not expose it through source control, logs, command output, or broadly readable paths. 6. Rotate the service-account key and review Google Workspace audit logs for unauthorized impersonation or mailbox activity. 7. Where supported, replace long-lived service-account keys with workload identity federation or another short-lived credential mechanism. 8. Add automated tests or deployment checks that reject OAuth scopes broader than the documented operational requirements.