从spring历史漏洞学框架审计(1)

感觉审计web框架和审计cms等web应用有挺大差别，说实话没啥思路，最近打算学习下spring历史漏洞锻炼下自己。

本篇是第一篇文章，CVE-2016-4877 spring security oauth Spel RCE

漏洞复现

直接起的vulhub环境。poc很简单：

http://localhost:8080/oauth/authorize?response_type=${T(java.lang.Runtime).getRuntime().exec(%22calc%22)}&client_id=acme&scope=openid&redirect_uri=http://test

值得注意的是这里对exec里面做了点处理，相当于过滤了空格的Spel注入。

spring路由分发

spring路由分发一般由这两个类来处理
FrameworkServlet –> DispatherServlet
其中后者是前者的子类。看意思也很好理解，分发者Servlet。
关键在于DispatcherServlet的doDispatch方法。

感觉分发逻辑在这里面，经过层层跟进来到了AuthorizationEndpoint这个类，中间好多层不写了。

如图，这是spring的默认路由。在处理完后会进行render。

很明显这里在处理responseTypes会报Exception，但是先别急，很多时候忽略了Exception的审计，到这就不看了。这是不对的，很有可能就会错过漏洞点。

异常处理审计

spring在捕获Exception后会来到/oauth/error这个路由，又是经过一大串的filter，来到这里：

这里render用的是SpelView渲染，如果参数可控，很大概率有漏洞。

随便跟两层：

到此处就不必多说了。

总结思路：

异常处理的审计

默认路由审计

spring路由源码阅读

审计框架，如果有表达式处理的组件如OGNL，Spel等，想办法让框架报错看看怎么处理的。是一个很好的思路。

参考：

https://docs.spring.io/spring-security/site/docs/5.6.3/api/org/springframework/security/oauth2/core/endpoint/OAuth2AuthorizationResponseType.html

Vulhub