RASP - Runtime Application Self ProtectionRASP 意思是应用运行时自我保护，算是相对"比较"新的安全技术了
顾名思义嘛，RASP 就是在应用运行时检测"并阻止"应用级别的攻击，可以类比成集成在应用程序上的 IPS/IDS
RASP 防御的核心就是在 Web App 执行关键代码前做检测和防御逻辑
那说到 RASP 就不得不提 WAF，有些乙方会说" RASP 是颠覆WAF的存在，RASP 是下一代 WAF"，这个肯定是推销的话术咯~不过 RASP 倒确实能和 WAF 互为补充，作为纵深防御中的两个环节
WAF VS RASPWAF 其实就是个专注于HTTP(S)协议的防火墙，根据写好的安全规则检查入站流量
这里的安全规则是 WAF 的核心，入站流量命中了安全规则，WAF可能会做出一些自动化响应，但是我们知道，安全规则是有滞后性的，这就像一定是先有病毒才有杀毒软件，安全规则必然是一直追着"敌人"跑；同时，WAF 的误报率一直是居高不下，这对于安全运营来说也是很大的压力
接下来需要举例子来说明 RASP 的优势：我们都知道 WAF 是有被绕过的概率的，无论是编码、注释、通配符混淆和宽字节等等，运用这些技术有机会绕过写好的 SQL 防注入 WAF 规则；而 RASP 技术可以做到：对Web App 拼接的 SQL 到数据库执行之前进行拦截或检测
这意味着无论攻击者使用什么方式渗透到了应用程序执行 SQL 阶段，这个 SQL 总要执行的，那在执行之前做检测是最短路径，也是最有效的方式之一
接下来再举一个例子：你项目中用到了 Struts 框架，假设一个 Struts 的 0day 出来了，由于 WAF IDS 这些层并没有提前写相关规则（0day也没法写啊），攻击者可以轻易绕过他们，这时候假设你们落地了 RASP，RASP 观察到的现象就是，自己运行了一段 OGNL 代码，然后莫名其妙地产生了未预期的代码执行，比如运行系统命令...这时候 RASP 就一定有告警，而且告警基本不存在误报
上面的两个例子都能很好的展示 RASP 的优势，它作为应用程序内部的保护机制，不依赖于外部的规则库来判断恶意攻击行为，而是通过实时检测应用程序的行为和上下文来判断是否有高危行为
更进一步来说，RASP 这种内在集成方式更准确、更主动
虽然 WAF 在防御已知攻击方面仍有很不错的效果，而 RASP 提供了一种更深入、更细致的安全防护措施，特别是在对抗那些复杂或尚未被广泛识别的安全问题时效果更显著
因此，WAF + RASP 才是比较好的纵深
RASP 的优势首先，RASP 基本不存在误报：无论是入侵检测系统还是防火墙，这类处于安全边界的防御手段都是基于请求特征检测攻击，因此对于外部使用 Zap、Sqlmap之类工具产生的扫描，处于边界的防御手段都会产生大量的告警
但 RASP 不同以上，可以认为它运行在应用的内部，这意味着入侵者操作失败就一定不会触发检测逻辑，因此每一条告警都是准确的（这里不能钻牛角尖，你要说研发写代码的时候乱搞触发了 RASP 的告警怎么办？确实存在这种情况）
安全边界处会产生大量安全警报，例如有人扫描你的/git、/.ssh、/.env等等，这些扫描都是攻击者使用自动化工具产生的，但你要知道，攻击者几乎都是大批量无脑扫描的，扫描不到漏洞攻击者压根就不会对你的系统有下一步动作了
由于 WAF 本身不知道你 Web 应用内部信息，它没办法判断这次扫描的危害性有多大，因此为了保险起见他选择告警给你看
例如你的技术栈压根不涉及 WordPress 或 PHP，但扫描的人会扫这里的漏洞，WAF 检测到了就一定会告警...其次，RASP 能通过上下文更好的追踪入侵者的行为：简单来说，假设入侵者绕过了 WAF，拼接了 SQL 并要求应用程序执行，在执行阶段 RASP 是能看到完整 SQL 的，通过 SQL 向上关联很容易能找到 WAF 究竟是哪里漏过了这条 SQL
最后，RASP 可以对抗很多"未知"漏洞：对于未知的漏洞，网络安全边界的防御手段不一定能识别到，例如某天 log4j 又爆出来了新的漏洞，入侵者无视你的外部防御手段直达 Web App，此时你的 RASP 使用调用栈检测方式发现，JNDI 触发了系统命令调用，这时候系统就会产生告警或者直接抛异常阻止执行
RASP 为什么会产生这次告警或者阻止这次行为？因为它发现应用做了正常情况下不应该做的事情
什么是正常情况下不应该做的事情？比如命令执行、文件读取、文件上传、SSRF 等都是
这里的关键在于，WAF 看到的流量特征几乎是无穷无尽的，但是应用的行为类型是可以穷举的
从应用行为异常的角度去检测，范围可以大幅收敛到有限的类型，这也是 RASP 可以无视流量特征并且不依赖规则更新就可以防御几乎全部 0day 的根本原因
无论外部来的流量特征怎么变，漏洞利用的本质都是让应用来做一些不安全的动作
劣势呢？第一点就是可能会拖慢服务器性能，服务器性能就是钱呀，假设 RASP 要占一台服务器的 20% CPU，这成本就是无法接受的；但是如果只占 3% 那就属于可接受范围；虽然很多产品宣称自己对系统性能的影响低于3% 5%，但在实际落地的过程中，还是会出现很多因为系统、应用差异，而导致性能恶化的情况
第二点是泄露敏感信息，可以以日志打印太多暴露敏感信息为类比；第三点是复杂度或者说上线成本可能有点高，无论你用开源的、商业化或者自研方案，都面临长期大量的稳定性测试，而当你后端技术栈太复杂时，又是go又是java又是rust的，要针对每一个技术栈都做 RASP，这样复杂度就又上一个台阶
以上三点只能说是技术上的难点，但想要做 RASP 有一个超级大坑：推广难度为什么？要知道，安全部门做个 WAF、做个入侵检测或者做个终端安全策略，最多也就需要运维部门帮忙
以上内容实际上并不需要研发参与，或者说不需要研发有太多的工作量；而 RASP 不同，RASP 和应用是强关联的，RASP 的推广实际上是安全意识的推广，所以难度系数真的很高
落地小公司大概率玩不转，具体实现思路就是通过 JavaAgent 的形式将 RASP 运行在 JVM 上，然后借助 Instrumentation 来 Hook 关键的类和方法
不过我的建议是，如果非要自研可以以 BTrace 为底来做基础的检测，别做 Protection，先做 Detection，小步快跑迭代，这里面最头疼的还是热更新
如果不执著追求自研，开源的方案还是蛮多的，百度的OpenRASP、jrasp、AppSensor等有很多
如果还是嫌麻烦，直接去买商业化方案就行咯
多说一句，RASP 这概念倒是提出的蛮早，大概十几年前就在说，不过实际落地案例还不够多，大家都是边做试验边落地的初期阶段...绕过有了 RASP 就能高枕无忧了吗？很遗憾，并不能...大佬们师傅们还是能绕过的，但难度上升了一个量级