原文链接：https://sites.cs.ucsb.edu/~vigna/publications/2011_CCS_EAR.pdf
项目地址： https://github.com/adamdoupe/find_ear_rails
本文发表在CCS’11，第一作者是来自加州大学圣塔芭芭拉分校的Associate Professor , Adam Doupé，研究方向很广泛，Web、物联网等都有涉猎：
主要内容
在现代Web应用程序中存在一些逻辑漏洞，但是并不为开发者和安全研究人员所关注，EAR漏洞就是其中之一。所以在本篇论文中，作者对EAR漏洞进行了分类，并对9种比较流行的Web框架的重定向机制进行了分析。为了研究以Ruby on Rails为框架的Web应用程序中存在的EAR漏洞，作者开发了一款工具来检测EAR漏洞，最后在18,127个应用程序中，共发现了3,944处存在重定向后执行问题。
EAR全称是Execution After Redirect，重定向后执行，以一个简单的Listing 1为例：
line 4判断当前用户是否为admin，如果不是就将用户重定向到首页/，但是并程序会继续执行，因为Ruby的redirect_to函数并不支持halt-on-redirect，程序向下执行，导致了@topic被更新。正确的做法是在line 5的后面进行return操作。但是这样也不能完全防住EAR漏洞，以Listing 3为例：
在ensure_admin函数中，判断了当前用户非admin用户，redirect_to重定向之后，调用了return返回，但是在delete()函数中可以看到，在第9行调用了ensure_admin，如果当前用户非admin用户，重定向后程序继续执行到return就会返回到当前delete函数，所以用户还是会被删除。
EAR漏洞通常没有回显，这导致了很难利用黑盒测试去挖掘相关的漏洞。但如果EAR漏洞导致了信息泄露，也就是information leakage EAR，这种EAR漏洞是可以用黑盒测试去挖掘漏洞的。以Listing 3为例：
调用header()函数进行重定向之后，并没有终止程序，第6行被执行，导致了信息泄露。
设计与实现
Detection Algorithm
作者采用了静态分析来判断代码在重定向之后是否会被继续执行，流程图如下图所示：
a. Building the Control Flow Graph
首先利用Furr的工具（The Ruby intermediate language.）将Ruby程序转化成Ruby Intermediate Language (RIL)，然后再生成CFG图。但生成的CFG可能是不完整的，因为这个工具不支持Ruby的动态特性，以及一些特殊语法，比如eval，利用eval函数生成runtime code。
b. Finding Redirection
这一步主要是寻找redirect函数及其调用redirect函数的caller，将其放到一个interesting method集合中，递归寻找interesting method set中函数的caller，知道找不到caller为止。
c. Prune Infeasible Paths
进行剪枝操作，减去一些不存在EAR漏洞的路径。比如Listing 4这个例子：
第4行调用了redirect_to进行了重定向，但是return false会继续执行，所以ensure_logged_in会返回false，在第11行，调用了ensure_logged_in()函数，因为返回的是false，所以执行了第12行的return，所以这个例子是不存在EAR漏洞的。
这个例子对应的CFG为：
redirect_to()重定向函数返回的值永远是true，所以返回false的那一分支（标记为虚线的(1)）是可以剪掉的。在redirect_to函数之后，继续执行return false，所以在redirect_to被调用之后，ensure_logged_in函数返回的值只可能是false，所以返回true的那一分支（标记为虚线的(2)）也是可以被剪掉的。
d. Detecting EARs
这一步比较简单，程序对CFG进行一个遍历，判断在调用了interesting method之后，后续的代码是否可能被执行。如果有，那就是潜在的EAR漏洞。
e. Distinguishing Between Benign and Vulnerable EARs
作者还设计了一种方法来判别Benign EAR和Vulnerable EAR。通过寻找从interesting method到修改数据库操作的函数路径来判断该EAR是benigh的还是vulnerable的，如果存在该路径，就说明是vulnerable EAR。这些数据库操作函数是作者从Rails的文档上找的14个函数。
Limitations
不支持Ruby语言的一些动态特性，比如利用
eval来调用redirect_to函数。比较幸运的是在Ruby on Rails框架中，使用这种特性的情况比较少。可能会产生误报，有两种类型的误报：
- false EARs
原因可能是因为
- false vulnerable EARs
原因是因为作者在第5步进行benign/vulnerable EAR判断的时候，并没有进行深入的分析，比如找到delete函数，可能是其他对象的操作函数，并不一定就是对database进行操作的delete函数。
实验评估
作者从github上收集了18,127款基于Ruby on Rails框架的Web应用程序。实验实在Intel Core i7，12GB RAM的配置上进行的，每个应用程序程序的扫描时间不超过2.5s，效率还是很高的。
实验发现在1,173个项目中存在重定向后执行问题，其中343个项目中包含至少一个vulnerable EAR漏洞。在这343个应用程序中，一共发现了855个vulnerable EAR漏洞。
为了验证实验结果的准确性，作者对找到的855个vulnerable EAR漏洞进行了人工分析。结果如下图所示：
结果表明，在被工具判定为Vulnerable的855个EAR中，经过人工分析，发现只有485个是真的vulnerable EAR，tp=59.9%，而且其中有45个并非EAR问题。结合Limitations中提到的两种误报情况为：
- false EAR：45/855 = 5.3%
- false vulnerable EAR：325/855 = 40.1%
总体评价
作者设计并实现了一款工具来寻找以Ruby on Rails为框架的Web应用程序中的Execution After Redirect漏洞。工具的基本思路就是对CFG进行遍历，递归一层一层寻找调用redirect函数的caller，将这些函数加入到一个集合中，然后判断在重定向之后，集合中的函数之后的代码是否会继续执行。这种思路其实也适用于PHP应用程序，但是PHP和Ruby一样，存在一些特殊语法和动态调用，相比在Ruby中，PHP中的动态调用情况更加普遍。
思维导图
