上一篇文章已经提到，如果想这个类作为沙盒安全认证的基础类，就必须继承java.lang.SecurityManager，并且当前运行环境中，可以查到当前的SecurityManager对象，以及具体的类名等。可以执行 System 类的静态方法 getSecurityManager( )，如果在运行 Java 程序时使用-D java.security.manager 命令行选项指定了使用默认的安全管理器，或自己定义的安全管理器，则将返回该安全管理器。

    

即使是非常简单的STRUTS2应用都不可用，还有很多其他框架，也都有自己操作classLoader的情况，如果不支持JAVA框架，这样的SAE，还有啥存在的价值呢？所以这些权限，不止简单的禁止了事，它后面还有很多东西要做。没有可用性的安全，不是真的安全，这样的安全处理方案，早晚要在业务的压力下消失不见，要保证可用性，也要保证安全，这才是真正的安全。所以，坐等SAE对classLoader的限制消失，一切回归于0。

    经过努力，作者已经打到了第三关，这一关叫做“命令执行关”。也不知道是因为作者描述不清楚，还是SAE的理解出现偏差，我们没有直接沟通过，只是作者写篇文章，先交给那边“审核”，“审核”通过后，才发布了，所有的交流，都仅限于文章本身。这种沟通的障碍，是此次绕过安全防御的起始。

    (此漏洞新浪已修补) 本次bypass，是利用了SAE上的沙盒权限允许“crackClassLoader”做到的，绕过权限后，作者调用了系统命令，去读取其他云用户的源代码。沙盒，尤其是用在云上的沙盒，安全配置是很重要的，很多权限并不是可以随便交给用户的，这次有了crackCLassLoaer，基本上是一个最好用的提权办法了，其实还有很多其他的权限，都是很不安全的。这要仔细斟酌以后，才能开给用户，否则就是一个灾难。

    SAE在设计的时候就考虑了安全性，并且防护非常严密，在易用性和安全性中实现了一个优雅的平衡，但是我们也可以看到对于paas的设计来讲，由于需要允许用户的代码尽量友好高效的运行，所以很容易在一些安全策略实现的细节当中出现一些问题，作为paas应用上下文的特殊性，其他的paas厂商在实现和设计的时候更应该严格注意这些安全问题，避免给平台和用户造成安全损失。

    想在sae中做一个豆瓣我说功能的同步.. 后来发现sae只提供了sina微博很友好的OAuth接口. 而对于其他的OAuth服务.我们不得不来用非常简陋的SaeFetchurl来实现. 再我参考了他的一些源码后.下面的代码已经完成了OAuth验证.测试正常. 注:下面的代码我只提供了使用API的时候授权的方法.你要问我怎么授权.有了这些还不够吗?