AppEngine安全测试思路

  • A+
所属分类:WooYun-Zone

安全测试内容主要是检查是否可以未授权进行资源访问、不同应用间的相互影响、应用本身对云平台的安全影响。

1、系统架构

第一步了解appengine的自身架构,了解其各个请求处理流、数据流的过程,尤其关注其中的每个逻辑判断点和实现方式,根据这些特点,了解分析其基础架构和系统模型上的固有弱点。(例如路由用户请求是根据HOST,而HOST本身依赖于用户提交,这里如果使用太过强大的语义分析做解析,就可能存在问题。例如引入lua、yaml等的语言注射)

第二步是了解其用户代码执行环境的沙盒实现方式,是否做到了隔离(fastcgi就是一个理论上没有做到不同用户代码运行在不同进程空间的好例子。可大部分appengine都是这么实现的)?控制点在哪里做的(语言编译器级别?虚拟机级别?语言库级别?控制点方位的不同,就可以结合下文中的语言特性进行绕过)?

2、资源访问

资源访问根据appengine提供的服务不同而不同,通常有以下几类:

文件(一般情况下,本程序目录可读、tmp可读写、其他目录不允许读写)

命令操作(一般不允许)

数据库(一般只允许本应用访问本应用的,不可跨应用访问)

网络资源(一般需要通过代理访问外界,不允许访问内部网络)

API接口(要求强认证,通常OAuth方式)

CPU、内存(这些计算资源主要是用来做统计,并不是做限制,但要有预防措施可以及时防止某应用突发高占用影响其他应用。)

针对这几类资源访问,需要根据策略结合下文所说的语言特性一一复查其是否能够真正做到统一的隔离和最靠近底层原子级别的限制。有可能还检查一下是否有独占资源或抢占资源的问题。

3、语言特性

AppEngine通常支持的不只是一种语言。每种语言根据其本身原理,有着不同的语言特性。我们这里主要关注的语言特性主要是包括一些动态代码执行或加载(eval、imp.load_source)、是否能通过一些特殊操作加载未经授权的代码(内存直接注入)、一些隐性的资源流访问(php的协议支持、部分第三方模块的资源访问、fdopen、xml中的资源文件读取)、隐性的进程线程创建(命令执行、调用外界程序)、隐性的cpu、内存消耗等。很多appengine对一些资源访问的控制手段也是根据语言自身提供的一些特性做出的,因此需要对这每一个特性的可靠性进行检查。(例如PHP disable_function,Java的Security Manager)

4、初始环境

appengine本身是一个沙盒环境,因此会在这个环境中设置一些初始化和为了方便提供的环境设置。而沙盒本身很可能对这些环境就无条件信任并带入关键逻辑了。因此就需要对这一块的检查和可修改性进行检查处理。

另外需要关注一点就是这些关键信息是否可以轻易的被泄露给除开发人员之外的第三方或者最终用户。如果泄露,可能对开发者本身造成影响。

公共库(是否可读写?读可能泄露一些敏感信息和内部实现,写可能导致恶意代码写入到其他应用中执行。)

环境变量(是否可读写?如果可覆盖,是否能够通过覆盖某些关键变量突破沙河限制?)

关键变量传递方式(是否可修改可偷取?)

5、业务相关

对于建立在其中的站点,是否有内容上涉及黄、赌、毒的地方,是否页面中存在挂马、黑链、钓鱼网站等等。这些不在本文的考虑范围内,暂略。

  1. 1#

    rayh4c | 2012-04-06 13:33

    = =!有没有更高端的,直接ROOT。

  2. 2#

    xti9er | 2012-04-06 14:01

    各种层面的隔离是重点

  3. 3#

    Mujj (为何我的眼中饱含泪水?因为我装逼装的深沉) | 2012-04-06 17:58

    开发者获取root权限后,即可进行软件安装等操作。使用时的注意事项有如下:
    1. 不能擅自修改或升级底层lib库。
    2. 如果需要用到新库,请统一安装在各自的软件路径下,编译时设定参数进行连接。
    3. 不能擅自修改/etc/和/proc/下的文件及系统参数,特别是hosts和resolv.conf文件,否则将会干扰总体部署环境。可以修改nginx.conf文件对user_00用户的写属性。
    4. 不能擅自修改iptables设置。
    5. 不能擅自添加其他进程的s位,如果有需求(如apache),第三方请联系腾讯运维支持处理。
    6. 不能擅自修改/tmp, /data等系统公共或关键路径的属主及权限,否则可能会导致数据无法写入的问题,导致子系统(例如安全,罗盘等需要进行数据上报的子系统)功能受影响。

    腾讯开放平台部署说明

  4. 4#

    GaRY | 2012-04-06 18:05

    @rayh4c @Mujj 你们在说个啥。。。。。非要我把标题改成PaaS才行么?

  5. 5#

    Mujj (为何我的眼中饱含泪水?因为我装逼装的深沉) | 2012-04-06 18:15

    @GaRY @GaRY  概念分的太清晰了,提供一台虚拟机和提供一个运行在虚拟机上的应用环境没有多大差别

  6. 6#

    xsser | 2012-04-06 18:56

    @Mujj 厄 这个理论,个人感觉还是有点区别的

  7. 7#

    Mujj (为何我的眼中饱含泪水?因为我装逼装的深沉) | 2012-04-07 11:53

    @xsser 从技术上来说是有区别的,但是其对于开发者来说本质都是差不多的,您所所的 架构、资源、语言、环境、业务 在众多的服务商中没有完全工业化的标准,在同一个服务上可能牵涉到多个概念,所以对厂商来说要清晰的界定的话不好做。

  8. 8#

    pentest | 2012-04-08 16:24

      

  9. 9#

    xiya | 2012-04-08 16:53

    学习…

  10. 10#

    GaRY | 2012-04-08 20:43

    @Mujj 请问你所说工业化的标准,PaaS、IaaS、SaaS的区分就是标准的一种,这些还是可以界定的吧?无论对开发者对平台提供商,这三者都是不同的。

  11. 11#

    小浪 (空) | 2012-04-09 20:56

    云安全联盟CSA出了个安全指南,不知道那个还与时俱进嘛

  12. 12#

    Mujj (为何我的眼中饱含泪水?因为我装逼装的深沉) | 2012-04-13 17:19

    @GaRY 从底层架构来说没有任何不同,虚拟化的不同应用面的产品或服务,具体的区别在于开发者的可自定程度和开发流程的简化度,开发者的一个产品可能需要平台厂商的多个产品或者服务

  13. 13#

    神刀 (www.shellsec.com_小明同学) | 2012-04-18 10:47

    关注关注

  14. 14#

    ubuntu (一切皆有可能) | 2012-07-27 11:38

    收藏

  15. 15#

    xsjswt | 2012-07-27 12:54

    赶来膜拜