Question

我在Chrome（桌面和移动）/ Firefox（桌面和移动）/ Safari（桌面）/卷曲（桌面）中使用App Engine和身份识别代理看到一些奇怪的行为

我使用这些设置在App Engine上启动了一个静态文件站点

的app.yaml：

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /(.*)
  static_files: index.html
  upload: index.html
  secure: always

的index.html：

<html>
<body>
Hello World!
</body>
</html>

然后我使用云控制台启用身份识别代理。

正如预期的那样，我被要求使用访问该页面所需的Google帐户登录。一切都好。

但是，有时我可以从没有凭据的浏览器访问该网站，甚至可以从curl访问该网站，我觉得这绝对不可能？

它需要一堆刷新/重试，但一旦它被复制，我可以使用Chrome，Firefox，Opera和curl无需身份验证就可靠地获取索引页。

问题：

我做的事情是完全愚蠢的吗？即使在隐身/私密模式下，或使用curl，有时也可以访问该网页吗？
我知道App Engine提供的静态文件有一个默认的10分钟缓存标头，这是如何影响的？
curl如何在这一切中混淆？除了提出请求的UA（以及Google内部的内部）之外，任何人都无法缓存AFAIK https？我的计算机上是否有一个缓存，所有这些来源都与我不了解？
这是我的计算机/手机上的问题（即，一旦页面被缓存，该设备上的所有UA都可以看到该页面而无需进行身份验证）？
这是Google的问题吗？

为了完整性，这是curl -v

的输出

curl -v https://xxxxxxxxxxxx.appspot.com
* Rebuilt URL to: https://xxxxxxxxxxxx.appspot.com/
*   Trying 172.217.22.180...
* TCP_NODELAY set
* Connected to xxxxxxxxxxxx.appspot.com (172.217.22.180) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.appspot.com
*  start date: Mar 28 14:17:04 2018 GMT
*  expire date: Jun 20 13:24:00 2018 GMT
*  subjectAltName: host "xxxxxxxxxxxx.appspot.com" matched cert's "*.appspot.com"
*  issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff81780a400)
> GET / HTTP/2
> Host: xxxxxxxxxxxx.appspot.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 20 Apr 2018 17:43:10 GMT
< expires: Fri, 20 Apr 2018 17:53:10 GMT
< etag: "8wDEQg"
< x-cloud-trace-context: 8e9c1b6803383aac532d48d9f0ac5fc2
< content-type: text/html
< content-encoding: gzip
< server: Google Frontend
< cache-control: public, max-age=600
< content-length: 54
< age: 371
< alt-svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35"
<
���(�ͱ�I�O���
* Connection #0 to host xxxxxxxxxxxx.appspot.com left intact
I-.Q�ч�l�!����Z�_$%

上面的输出应该显示302重定向到IAP的登录页面，但如前所述 - 它并不总是这样做！

TL; DR为什么我可以在不允许访问的上下文中访问计算机上受IAP保护的App Engine静态页面？

谢谢！

Answer 1

啊，你遇到了一个有趣的角落案件！在https://cloud.google.com/iap/docs/concepts-best-practices - TL有一些相关的文档; DR，App Engine对与IAP交互不良的static_files进行了一些缓存。如果要保护static_files，该页面有一些可以应用的指令。 --Matthew，Google IAP Engineering

Google Cloud Identity Aware Proxy（App Engine） - 奇怪的网络浏览器行为？

1 个答案: