近两年，百度的OpenRASP在安全业内大火，各大厂的安全团队都在纷纷跟进研究，捣鼓自己的IAST/RASP产品。作为一支有追求的安全团队，自然要推动这类新兴技术在行内落地。但想要大面积覆盖全行应用中，项目的推广、适配、运维方面的挑战都是不小的。这里分享我们实践的一个新思路，能有效的达到了快速部署的目的
。 0x00. 挑战 IAST/RASP的原理这里就不介绍了，其主要优点就是检测精准。技术是好技术，但要在企业中大规模部署，它的缺点也很明显：- 要实现大规模部署，我行几千应用系统、几万服务器的适配、测试、部署、维护…这推广、维护工作太重。
- 虽然在c0debreak大佬团队的努力下，RASP Agent对服务器的性能影响已可控制到3%左右。但在银行交易系统中，我们也不敢轻易“玩火”，只能将目标锁定在后管类系统上。
理想一定要有，万一实现了呢。 平安银行应用安全团队然后，就有了以下这个思路： 实现也很简单，一些APM应用监控平台(如CAT、WiseAPM、Dapper等，我行使用的是CAT，本文以CAT为例)的客户端同IAST/RASP Agent实现原理一致，用的是Java字节码技术，通过插桩记录程序运用时的堆栈数据，来分析应用健康度。而它所监控的数据就有安全所感兴趣的，比如说原生SQLlog、关联的接口信息、服务器信息等等。一般此类APM都是由架构运维部门负责，且基本能够覆盖绝大数业务系统，已完成从0到1的大面积推广及运维保障。如果安全赋(寄)能(生)在它们的Agent上，就能解决我们的问题。
CAT架构 要基于CAT的Agent实现IAST/RASP的漏洞检测能力，规则放在客户端运行，CAT那边肯定是不会同意的，且可能对应用影响较大，不建议介入太深。只能看看安全关心的应用数据，然后再进行离线分析就可以了。当然具体能检测哪些问题，还是要看CAT做了哪些函数的插桩埋点，这里就不再赘述。下面以SQL注入为例，介绍下我们的实践过程。 0x02.技术实现 为什么要从SQL注入入手。原因有两点：- 此类APM平台，基本上都有SQL性能分析，所以基本上都可以提供原生SQL数据，这是现成的。而其他漏洞可能还需要增加埋点。
- 去年我们团队搞了大半年的被动扫描器，由于SQL注入黑盒测试造成大量脏数据，以及准确率等问题，一直比较头疼。正好借此机会来优化一下。
由于依赖于CAT，我们的项目代号为BlackCAT(黑猫警长?)。上图中，被动扫描器只在主动式IAST场景下的充当无脑发包器，对抓的所有流量进行全量标记盲打，与BlackCAT分析引擎无需联动。有溯源必要时，可在Request中加一些特征标识，如在URL后或Header中追加BlackCAT参数，通过Catlog同步通知BlackCAT即可。 以MyBatis项目监测情况为例，#{param}和${param}插桩JDBC记录到的SQL是不一样的。预编译的SQL的入参是占位符“？”，而使用拼接的SQL可以看到入参内容。 --预编译： select*from t_user where username =？ --拼接： select*from t_user where username ="helen" 但在真实复杂的应用场景中，还无法仅凭是否有占位符来判断是否存在SQL注入，很多情况下，应用内部的SQL也有很多，所有要确认是存在漏洞，还需要找到用户入口。 0x03.检测逻辑 理清了数据以及确定目标，就可以去设计离线检测策略了。目前我们共实现三种检测逻辑：Mark标识位、黑名单检测、入参比对，分别对应测试环境中IAST漏洞扫描以及生产环境中RASP攻击监测(RASP暂时只实现告警)。1. Mark标识位(主动式 IAST)：
在被动扫描器上新增一个IAST插件，对测试区全部流量进行参数注入，在Value后拼接上一个标记字符串。 POST /xxx/abc/custInfo.do HTTP/1.1 Host: 192.168.1.100:80 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 Accept: */* Referer: http://192.168.1.100/admin Accept-Language: zh-CN,zh;q=0.9 Cookie: token=123456789 username=helenMarkedbyscan BlackCAT异步监控分析全行应用的执行SQL。如在发现某些SQL中有标识位进入，则可判断该属主应用使用了拼接SQL且存在用户入口，存在安全漏洞。 select*from t_user where username ="helenMarkedbyscan"
标识位检测日志2. 黑名单检测(RASP攻击告警)
这里目前实施了两种方式：通过黑名单规则检索SQL中的可疑的payload，这点参考WAF策略。相较于WAF，好在如果发现有payload进入SQL，那就存在漏洞且攻击成功。但由于都是维护黑名单规则，即可能存在误报漏报。
统计在SQL中检索单引号数量，判断总数是否为奇数引号。一般如出现奇数引号，可能为人为注入测试，可判断有潜在攻击者，且已发现漏洞。
3. 入参比对(被动式IAST及RASP攻击告警)
入参比对是将 Request 中的入参值与关联的 SQL 的入参进行比对。
如发现二者入参数存在一致的Value，则可确认存在漏洞，因为用户输入参数被拼接带入了SQL中去。 在此基础上，再判断是否为攻击，可通过Value是否被带入未转义的特殊字符(如空格，引号，斜杠等等)，Value是否包含除字符串以外的其他元素。如为真，存在攻击；也可以直接提取原生SQL的查询条件Value，分析对比请求入参是否能在提取的Value中找到。如为假，则存在攻击。 0x04.效果 到此为止，我们就基于CAT初步实现了IAST/RASP能力了，虽然初期检测逻辑还略显粗糙，但在实际应用中，还是取得了不错的效果。测试区上线短短1周内，自动发现SQL注入30多例，内部安全同事的SQL注入测试百余起。后期就是继续增加埋点和优化策略，来增加检测的漏洞类型。
测试区IAST漏洞扫描
生产区RASP攻击检测告警 这种基于于这种美其名曰安全赋能，实着抱大腿的合作模式，其好处就在于可以快速、无感地推动IAST/RASP能力的大规模覆盖，且无需担心对应用有任何影响。当然，这样的IAST/RASP能力覆盖面取决于应用监控CAT的推广程度。在我行，全行绝大数应用都已集成CAT，其中包括各类重要核心应用。现在无论是生产还是测试，都不用考虑那些头疼的推广适配、部署运维，只要牢牢的抱住大腿… 参考： h ttps://github.com/baidu/openrasp ---------------------------------------------------------《企业安全建设指南：金融行业安全架构与技术实践》购买链接，支持作者。
----------------------------------------------------------------------
企业安全建设，离不开“守望相助”。金融业企业安全建设微信群，入群方式：请加以下微信为好友，备注：姓名-公司-负责领域。销售从业人员暂时不邀请入群，不保证每位申请者入群，敬请谅解。
扫一扫，加入企业安全建设实践群
由于各种原因不能加入金融企业安全建设实践群的，可以加入知识星球看群周报沉淀，还可以给我提问。
知识星球：金融企业安全建设实践
附注：
聂君，信息安全从业人员，十余年金融行业信息安全从业经历，默默无闻。好读书，不求甚解。性格开朗，爱好足球。
本订阅号文章是个人对工作生活的一些体验和经历分享，站在不同角度和立场解读会有偏差，见仁见智，不求正确统一，但求真、善、美。
右下角点个在看，也是支持