GITBOOK-655: No subject

pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-workflows-privesc.md

@@ -79,6 +79,44 @@ You can also check the output of previous executions to look for sensitive infor
 
 Note that even if you get an error like `PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` because you don't have that permission, the workflow has been generated.
 
+### Leak OIDC token (and OAuth?)
+
+According [**to the docs**](https://cloud.google.com/workflows/docs/authenticate-from-workflow) it's possible to use workflow steps that will send an HTTP request with the OAuth or OIDC token. However, just like in the case of [Cloud Scheduler](gcp-cloudscheduler-privesc.md), the HTTP request with the Oauth token must be to the host `.googleapis.com`.
+
+{% hint style="danger" %}
+Therefore, it's **possible to leak the OIDC token by indicating a HTTP endpoint** controlled by the user but to leak the **OAuth** token you would **need a bypass** for that protection. However, you are still able to **contact any GCP api to perform actions on behalf the SA** using either connectors or HTTP requests with the OAuth token.
+{% endhint %}
+
+#### Oauth
+
+{% code overflow="wrap" %}
+```yaml
+    - step_A:
+      call: http.post
+      args:
+          url: https://compute.googleapis.com/compute/v1/projects/myproject1234/zones/us-central1-b/instances/myvm001/stop
+          auth:
+              type: OAuth2
+              scopes: OAUTH_SCOPE
+```
+{% endcode %}
+
+#### OIDC
+
+```yaml
+    - step_A:
+      call: http.get
+      args:
+          url: https://us-central1-project.cloudfunctions.net/functionA
+          query:
+              firstNumber: 4
+              secondNumber: 6
+              operation: sum
+          auth:
+              type: OIDC
+              audience: OIDC_AUDIENCE
+```
+
 ### `workflows.workflows.update` ...
 
 With this permission instead of `workflows.workflows.create` it's possible to update an already existing workflow and perform the same attacks.