对Google App Engine安全的一点思考

只是管中窥豹，因为google没有公开什么安全方面的文档，我也没有深入研究和测试GAE对各项攻击的防范，只是作为一个google的用户简单讲讲。

首先，底层肯定是构建在GFS上，使用分布式存储，存储所有的数据，也就是google 的云存储。

往上，可能就是计算平台，包括任务调度、SQL 引擎， Key-Value 引擎的。

App Engine 构架于这些基础服务之上，对外提供服务。

Sandbox: GAE目前支持 java 和 python 代码的运行，两者都是有sandbox的（java 用 securitymanager）。通过 sandbox 的保护，能够限制一些恶意代码直接操作系统文件，执行命令。

Datastore: 这不是一个真正的数据库，应该只是基于GFS的key value 对，而且模拟的 GSQL 也是按照类似“绑定”的做法来传递变量的，没有拼凑，所以注入是不可能的。也不会有传统的类似备份、导出等获得shell的方法。

Account: 默认可以使用google的账户体系，从google sso到 appspot。 好处是即使发生XSS，攻击者获取了cookie，也无法登录到用户的google帐户，因为跨域了。


Access Control: 不知道google的细节。问题就是能否在内部从app A 跨越到 app B去操作数据。类似传统的旁注。如果想突破，只能寄望于一些内部存储上的逻辑漏洞，比如一个文件的链接分配给别的应用，文件删了，但是链接还在。google现阶段似乎还没有提供跨app的业务需求，所以这方面可能都是把每个app给独立开了。


DDOS: 网络层和传输层的DDOS由google保证，应用DDOS方面（CC），由于GAE的 quotas 限制是用来收费的，所以很容易达到上限，就会停掉服务。 不过可以通过一些技术手段来缓解应用DDOS的压力，类似apache 的 mod_evasive 做的事情。 但是最终的方案可能还是需要google提供防火墙级别的block ip 的API，才能比较好的解决这个问题。


获取webshell？从上面的分析看来，非常难了。唯一有可能的就是 sandbox被绕过。这可能是java或者python的某个库的漏洞会造成这种问题，如果google没有再特别设计过的话，还是有机会突破到系统层去的。


盲人摸象，以后有时间再去慢慢研究google的安全吧。