修复HTTP动词篡改导致的认证旁路问题的方法

本文于2016年4月完成，发布在个人博客网站上。

诡异的问题

分析AppScan扫描报告的时候，发现报告里提示“HTTP动词篡改导致的认证旁路”，一个名字很长，很怪异的问题。咨询度娘没有获取到必要的信息，于是只好按照AppScan报告里给出的重现步骤，实地操作来看看。

AppScan给出的复现步骤很简单，如下：

使用burpsuite拦截浏览器发出的HTTP请求，如下为样例：

 GET /index.jsp HTTP/1.1Host: 127.0.0.1:8080Cache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36Accept-Encoding: gzip, deflate, sdchAccept-Language: zh-CN,zh;q=0.8Connection: close

修改HTTP方法，比如把GET修改为BOGUS，然后点击Forward，把请求转发给Web服务器。

 BOGUS /index.jsp HTTP/1.1Host: 127.0.0.1:8080Cache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36Accept-Encoding: gzip, deflate, sdchAccept-Language: zh-CN,zh;q=0.8Connection: close

令人大跌眼镜的事情发生了，Web服务器居然返回了HTTP 200，同时正确的返回了页面；

顿时让人有点小郁闷。按照产品线要求，当前所在项目使用的是平台部门基于Apache Tomcat 7.0.x源码做过加固的版本，按理说不该存在类似的安全问题。

对照Tomcat加固要求，重新检查了$CATALINA_BASE/conf/web.xml，确认其中包含了如下配置，这说明已经屏蔽了不安全的HTTP方法，应该是没有问题才对。

<security-constraint><web-resource-collection><http-method>HEAD</http-method><http-method>PUT</http-method><http-method>DELETE</http-method><http-method>OPTIONS</http-method><http-method>TRACE</http-method><url-pattern>/*</url-pattern></web-resource-collection><auth-constraint><role-name></role-name></auth-constraint>
</security-constraint>

那么为什么AppScan扫描报告中出现了前述问题，Jackie一时有些想不明白。

项目的技术特点

当前所在项目使用了Spring+Struts2+iBatis，从技术组合上可以说非常传统，但在技术应用上存在很大不同，比如：

浏览器请求页面时，使用通用Action将请求重定向至对应的jsp页面；
页面上使用jQuery提供的ajax对象来加载呈现需要的数据；
为了实现项目国际化的需求，要求所有对jsp的请求都需要经过通用Action的转发；
页面代码使用Struts2的s标签来提取国际化信息；

这样的应用方式其实有不得以的苦衷，项目刚成立的时候，组内全是新人，对Struts2仅有名义上的理解，没有人在项目中实际运用中使用Struts2，另外项目进度压的很紧，没时间给大家去了解和学习；而使用ajax来实现页面与Web服务之间通信，实现和使用都简单，于是一直沿用至今。

Struts2的配置

Struts2在web.xml中的配置如下：

<filter><filter-name>struts2</filter-name><filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter><filter-mapping><filter-name>struts2</filter-name><url-pattern>/*</url-pattern>
</filter-mapping>

简化后的struts.xml配置文件，内容如下：

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC"-//Apache Software Foundation//DTD Struts Configuration 2.3//EN""http://struts.apache.org/dtds/struts-2.3.dtd"><struts><constant name="struts.enable.DynamicMethodInvocation" value="false" /><constant name="struts.devMode" value="true" /><constant name="struts.action.extension" value="jsp,action"/><constant name="struts.ui.theme" value="java"></constant><constant name="struts.objectFactory" value="spring" /><constant name="struts.i18n.encoding" value="UTF-8" /><package name="default" namespace="/" extends="struts-default"><interceptors><interceptor-stack name="myStack">  <interceptor-ref name="basicStack"></interceptor-ref>  </interceptor-stack> </interceptors>  <default-interceptor-ref name="myStack" /> <global-results><result name="error">/error.jsp</result></global-results><global-exception-mappings><exception-mapping exception="java.lang.Exception" result="error"/></global-exception-mappings><action name="*" class="MainAction"><result name="success">{1}.jsp</result></action></package>
</struts>

通用Action类，简化后的MainAction代码如下

import com.opensymphony.xwork2.ActionSupport;public class MainAction extends ActionSupport {private static final long serialVersionUID = 928135783255954591L;@Overridepublic String execute() throws Exception {return ActionSupport.SUCCESS;}
}

从配置上讲，中规中矩，并没有什么特别的地方。

分析过程

访问jsp页面的流程

按照前述配置，当用户在浏览器地址栏里输入后缀为.jsp的url，敲击回车后，发生的事件如下：

由于在struts.xml文件中有如下配置，用户请求先被Struts2拦截；
```
 <constant name="struts.action.extension" value="jsp,action"/>
```

由于在struts.xml中有如下配置，请求会被转发给MainAction来处理；

 <action name="*" class="MainAction"><result name="success">{1}.jsp</result></action>

由于MainAction类的execute方法只返回了"success"，于是请求又被重定向回了对应的jsp页面；
```
 @Overridepublic String execute() throws Exception {return ActionSupport.SUCCESS;}
```
这时，对jsp页面的访问就由Tomcat接管了；

与9.0.x版本的Tomcat做对比

按照上面的分析，在第4步，如果Tomcat遇到了异常的请求方法，应该拒绝响应才是，不应当返回HTTP 200和页面。那么会不会是Tomcat实现存在问题？

平台发布加固后的Tomcat版本时并没有附带源码，于是从官网获取Tomcat发布的9.0.x版本做对比验证。执行前述的复现步骤，Tomcat 9.0.x版本给浏览器返回了如下响应：

HTTP Status 405 - JSPs only permit GET POST or HEAD
type Status report
message JSPs only permit GET POST or HEAD
description The specified HTTP method is not allowed for the requested resource.

检查9.0.x版本Tomcat生成的servlet代码，发现在_jspService中增加了对HTTP方法有效性的校验，只允许jsp编译生成的servlet响应GET、POST或HEAD方法，如下。

  public void _jspService(final javax.servlet.http.HttpServletRequest request, final javax.servlet.http.HttpServletResponse response)throws java.io.IOException, javax.servlet.ServletException {final java.lang.String _jspx_method = request.getMethod();if (!"GET".equals(_jspx_method) && !"POST".equals(_jspx_method) && !"HEAD".equals(_jspx_method) && !javax.servlet.DispatcherType.ERROR.equals(request.getDispatcherType())) {response.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, "JSPs only permit GET POST or HEAD");return;}

生成上述代码的实现位于org.apache.jasper.compiler.Generator类中，如下所示

// Method check
if (!pageInfo.isErrorPage()) {out.printil("final java.lang.String _jspx_method = request.getMethod();");out.printin("if (!\"GET\".equals(_jspx_method) && !\"POST\".equals(_jspx_method) && !\"HEAD\".equals(_jspx_method) && ");out.println("!javax.servlet.DispatcherType.ERROR.equals(request.getDispatcherType())) {");out.pushIndent();out.printin("response.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, ");out.println("\"" + Localizer.getMessage("jsp.error.servlet.invalid.method") + "\");");out.printil("return;");out.popIndent();out.printil("}");out.println();
}