一次SQL注入导致的"越权"

原文来自SecIN社区—作者：tkswifty

相关背景

  在实际的业务开发中，SQL交互往往是业务系统中不可或缺的一项。在Java中提供了类似Mybatis、Hibernate、SpringData JPA等来满足相关的数据库交互需要。但是由于种种原因，开发人员在处理应用程序和数据库交互时，使用字符串拼接的方式构造SQL语句，导致了SQL注入问题。那么有时候面对大量的接口存在SQL注入，迭代困难的时候，过滤器/拦截器便是很多开发人员的首选，通过过滤相关的SQL关键字，避免SQL注入得到进一步利用。

  针对上述场景，很多时候需要加检查过滤器设计是否严谨，检查是否有漏网之鱼，导致SQL注入漏洞被攻击者进行利用。前段时间审计某项目时发现一处SQL注入导致的"越权"，以下是相关的过程。

挖掘过程

  系统基于SpringMVC进行开发，业务主要是与简历编辑相关。相关的问题接口主要在修改个人简历处。一般来说，这种修改个人信息的业务，除了修改内容以外，主要传递两个关键信息：

• 当前用户的身份凭证userId
• 当前用户的业务编号(这里是简历)，resumeId

  在进行接口业务请求时，将业务相关的关键参数userid聪当前用户的身份凭证（一般是session）获取，绑定个人用户身份，然后从前端获取需要修改的resumeId，最后在保存信息进行SQL交互时，从会话在获取的userId再与resumeId进行二次绑定，保证userId对应的用户仅能修改自己的简历。类似的SQL语句如下：

UPDATE user_resume SET content='test',user_name='test'{省略相关内容} where userId = $userId and resumeId=$resumeId;

  如下是相关的代码：

  首先是Controller，在Controller层对用户的输入进行相关的封装（这里是简历的相关信息），通过自动绑定的处理方式，直接将用户的输入绑定到resume对象里，然后通过当前登录会话获取当前用户的userId，通过调用service的update方法进行简历内容的更新：

	@ResponseBody
	@RequestMapping(value = "/updateResume", method = RequestMethod.POST)
	public PagedResult<ResponseRes> updateResume(Resume resume) {
		String userId = （String）session.getAttribute("userid");
		PagedResult<ResponseRes> pageResult = this.resumeService
				.update(resume,userid);
		return pageResult;
	}

  查看service层实现，调用的是resumeService的update方法：

public PagedResult<ResponseRes> updateResume(Resume resume,String userid) {
		String rusumeId = resume.getId();
  	if(resumeId!=null){
				boolean updateStatus = resumeDao.update(resume, userid,resumeId);
				if(updateStatus){
				//更新成功，封装返回结果
						......
				}else{
				//更新失败
						......
				}
    }else{

    }
		return updateResule;
	}

  讲封装好的简历内容以及userId跟ResumeId传入resumeDao的update方法进行处理，这里使用的是mybatis框架进行处理，查看mapper的具体实现：

		UPDATE user_resume SET
		......
		<if test='resume.address!=null'>
			,address=${resume.address},
		</if>
			......
		where userId=${userId} and resumeId=${resumeId};
	</select>

  所以整个简历更新的流程如上描述，因为在进行SQL交互时，通过update对简历表进行维护，通过userId和resumeId限定要更新的行。因为userId跟用户会话进行绑定，所以用户仅能更新自己对应的简历，防止了越权问题。

  但是这里由于在Mybatis中使用了$进行注解，存在SQL注入风险。那么进一步检查是否存在相关的防护措施。这里发现相关的过滤器措施，应该是系统注入太多了，所以开发统一通过过滤器对用户输入进行处理，检查过滤器的具体实现。

  同样的过滤器还是检查如下几点：

• 过滤器的顺序
• 获取数据的方式是否覆盖全面
• 过滤的规则内容

  这里由两个过滤器组成，分别负责xss以及SQL注入的输入检测。因为都是直接检测到恶意输入就直接返回通用报错页面，所以这里不存在顺序问题导致的filter绕过。

  其次是获取数据的方式,这里通过MultipartHttpServletRequest multiReq = multipartResolver.resolveMultipart(request);对当前文件上传进行转换，转换成普通的request对象后再进行相关的输入检查，防止multipart提交导致的bypass：

	private CommonsMultipartResolver multipartResolver = new CommonsMultipartResolver();
 	public void doFilter(ServletRequest req, ServletResponse res, FilterChain filterChain)
 			throws IOException, ServletException {
 		public static String[] MULTI_FILE_WHITE_LIST = new String[]{"/manager/uplode"};
 		HttpServletRequest request = (HttpServletRequest) req;
 		HttpServletResponse response = (HttpServletResponse) res;
 		String pathInfo = request.getPathInfo() == null ? "" : request.getPathInfo();
 		String url = request.getServletPath() + pathInfo;

 		String contentType = request.getContentType();// 获取请求的content-type

 		//如果是文件上传接口不需要进行转换，需要在接口处直接进行输入检查
 		...

 		// 文件上传请求 *特殊请求
 		if (multipartResolver.isMultipart(request)) {
 			MultipartHttpServletRequest multiReq = multipartResolver.resolveMultipart(request);
 			request = multiReq;
 		}
 		//SQL注入检查
 		......

  此外针对更新简历接口，其提交的数据类型为正常的key-value形式，所以这里filter获取数据的方式是覆盖全面的。

  最后是相关的过滤规则，这里要结合数据库类型进行判断。系统使用的是mysql的数据库，过滤规则如下：

String badSqlStr ="'|and|exec|execute|insert|select|delete|update|count|drop|*|%|chr|mid|master|truncate|char|declare|sitename|net user|xp_cmdshell|;|or|-|+|,|like'|and|exec|execute|insert|create|drop|table|from|grant|use|group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|sleep|order|by|count|*|chr|mid|master|truncate|char|declare|;|--|+|,|like|//|/|%|#";

  过滤了大部分的SQL关键字，包括select这种SQL注入拖取内容必须的关键字，还有xp_cmdshell这类敏感的SQL函数。针对更新简历接口，其中的SQL注入乍一看应该是无法进行获取数据库敏感信息等恶意操作了。

  通过上述分析，更新简历接口的越权跟SQL注入问题貌似暂时得到了缓解。实际上这里可以通过SQL注入，来“越权”修改他人的简历。

  可以查到相关update语句的条件为where userId=${userId} and resumeId=${resumeId}，其中userId从当前会话获取，用户不可控，resumeId为前端传递，用户可控。那么也就是说，当前端传递的resumeId为1 or userId=2时，即可在更新当前用户简历同时，更新userId=2的用户的简历内容，达到越权的效果。

  提交的参数内容如下(因为过滤器中并未过滤or关键字，所以该逻辑可以绕过过滤器安全检查)：

address=xxxxx&{相关简历内容}&resumeId=10001 or userId=2

  最终执行的SQL语句大致如下：

UPDATE user_resume SET content='test',user_name='test'{省略相关内容} where userId = $userId and resumeId=$resumeId or userId=2;

   这里结合数据库表进一步说明具体效果，为了方便说明，将数据库内容简化成如下结构,userId代表用户身份，resumeId代表对应的简历，最后content代表简历的内容：

  正常情况下，假设登录了userId为1的账户，尝试更新其resumeId为10000的简历，对应执行的SQL语句为(这里把内容test修改为test111)：

UPDATE user_resume SET content='test111' where userId = 1 and resumeId=10000;

  执行后对应的user_resume表内容变化如下：

  根据前面的分析，因为resumeId存在SQL注入且用户可控，此时尝试提交resumeId=1 or userId=2，尝试越权将userId=2的用户简历内容修改为Access-Control-Bypass，对应执行的SQL语句如下：

UPDATE user_resume SET content='Access-Control-Bypass' where userId = 1 AND resumeId=1 OR userId = 2;

  成功利用SQL注入"越权"修改他人用户的简历信息：

  针对SQL注入的修复，通过过滤器/拦截器对用户的输入进行检查并不是最佳的选择。在满足特定的场景情况下，可能会导致例如上述的“越权”问题。

  与此同时，很多开发人员存在误区，认为使用JPA、HQL进行SQL交互后便不会存在SQL问题了，SQL注入的本质是在处理应用程序和数据库交互时，使用字符串拼接的方式构造SQL语句，同时相关的敏感参数可控，只要满足即存在SQL注入风险，只是使用了HQL后，由于其特点无法直接执行原生SQL，及写文件，执行命令等操作，也不支持跨库查表等敏感操作。但是依旧可以结合实际的场景，尝试达到上述的“越权”危害。