上一篇文章主要是OAuth流程上的一些漏洞，然后本文就是对历史上的OAuth的RCE漏洞进行分析学习
漏洞简介
OAuth在处理异常的时候，调用了SpelView导致表达式注入
环境搭建
下载http://secalert.net/research/cve-2016-4977.zip，用idea导入maven项目，在WhitelabelErrorEndpoint和OAuth2Exception下个断点
CVE-2016-4977
访问http://127.0.0.1:8080/oauth/authorize?response_type=token&client_id=acme&redirect_uri=${999-1}，因为这里uri有问题，直接进入OAuth2Exception，错误信息为invalid redirect：${999-1}……
生成ModelAndView对象，forward到/oauth/error
DispatcherServlet做分发
其中提取错误信息的model对象，写入request的attribute
/oauth/error这里从request中取出了error，并得到详细信息，然后生成新的MV对象，View是SpelView，model是详细错误信息
第一次渲染SpelView，发现${errorSummary}，然后进入resolvePlaceholder函数
errorSummary就是我们错误的详细信息，EL解析完即可得到我们的恶意payload
这里判断如果解析完的值不为空的话，递归调用parseStringValue函数
得到999-1，表达式解析完得到998
最后是正常的调用，弹出计算器
CVE-2018-1260
其实跟上一个漏洞是一样的表达式注入，只是在不同地方
全局搜一下SpelView，可以发现在/oauth/confirm_access中还有一个调用点
访问http://127.0.0.1:8080/oauth/authorize?response_type=code&client_id=acme&redirect_uri=http://localhost&scope=%24%7BT%28java.lang.Runtime%29.getRuntime%28%29.exec%28%22calc.exe%22%29%7D，来到validateScope函数，这里需要client的scope设为空，不然会过不了
跳转到/oauth/confirm_access
取出model中的scope拼进template中
用template生成一个SpelView对象，然后后面就跟之前一样了
