mybatis SQL注入攻击 以及XSS攻击csrf攻击

mybatis SQL注入攻击 以及XSS攻击csrf攻击

以上攻击形式跟原理不多做介绍,此处记录处理方案

SQL注入

问题:系统在经过安全扫描是,被告知存在SQL注入的封信,mybatis的预编译是不存在注入风险的,但是在排序字段的处理上,没法使用预编译,同时,在个别字段,存在使用$取值等不规范的操作,以上操作均会出现注入的风险
注入代码实例:
字段添加如下信息,虽然报错,但是会暴露出数据库用户跟数据库IP的信息。

extractvalue(1,concat(0x7e, (user()),0x7e))

解决方式:
对于排序字段,采用抢控,即排序字段在set方法里边,一旦检测出,存在SQL关键字,就将整个排序字段值销毁掉,特别的,干掉有“()”的字符串。
对于正常字段,根据正则表达式过滤,一旦字段值存在异常,则抛出异常,正则参考如下内容(次正则还需校验)

=====================正则表达式=============================
\b(and|or)\b.{1,6}?(=|>|<|\bin\b|\blike\b)| 
\/\*.+?\*\/|
\bEXEC\b|
UNION.+?SELECT|
UPDATE\s.+?SET|
INSERT\s+INTO.+?VALUES|(SELECT|DELETE)\s.+?FROM|(CREATE|ALTER|DROP|TRUNCATE)\s+(TABLE|DATABASE)|
.?().?

======================样例=============================
 and AAA =/ in / like
/*A*/
 EXEC 
union AAA select
update.set
insert	info AAA VALUES
select/delect	FROM
CREATE TABLE
user()

过滤点:
自定义过滤器实现继承HttpServletRequestWrapper类,重写getParameter方法,过滤字段的值。

public class ParamReqWrap extends HttpServletRequestWrapper{

	private Map<String, String[]> params;
 
    public ParamReqWrap(HttpServletRequest request, Map<String, String[]> newParams) {
        super(request);
        this.params = newParams;
    }
 
    @Override
    public Map<String, String[]> getParameterMap() {
        return params;
    }
 
    @Override
    public Enumeration<String> getParameterNames() {
        return new Vector<String>(params.keySet()).elements();
    }
 
    @Override
    public String getParameter(String parameter) {
        //parameter为字段名,从params中取出值后过滤
    }
    
    @Override
    public String[] getParameterValues(String parameter) {
        
	}  
    
    @Override
    public String getHeader(String name) {  
        String value = super.getHeader(name);  
        if (value == null)  
            return null;  
        return cleanXSS(value);  
    }
 
    
	
	/**
	 * 防CSRF、XSS和SQL注入方法
	 */
    private String cleanXSS(String value) {  
		//
        return value;
    }
}

自定义的

@Component
public class CommonFilter implements Filter {
	public void doFilter(ServletRequest arg0, ServletResponse arg1,
			FilterChain chain) throws IOException, ServletException {
			//处理MULTIPART/FORM-DATA格式的请求
			String contentType = request.getContentType();
			if (contentType != null && contentType.toUpperCase().contains("MULTIPART/FORM-DATA")) {
			MultipartResolver resolver = new CommonsMultipartResolver(request.getSession().getServletContext());
			MultipartHttpServletRequest multipartRequest = resolver.resolveMultipart(request);
			// 将转化后的 request 放入过滤链中
//			logger.info("[判断完成]multipartRequest:"+JSON.toJSONString(multipartRequest));
			request = multipartRequest;
//			logger.info("[判断完成request]multipartRequest:"+JSON.toJSONString(request));
		}
			//将自己的过滤器放进过滤链中
			ParamReqWrap paramReqWrapDTO = new ParamReqWrap(
				(HttpServletRequest) request, paramsMap);
			chain.doFilter(paramReqWrapDTO, response);
				
			}
}

以上需要注意的是:改完之后扫描发现, 正产的个postget请求是拦截住了,但是对于MULTIPART/FORM-DATA格式的却没有拦住,后发现,这种格式的请求,虽然属于post但是整个请求体都不一样了,因此需要处理见代码注释

XSS 攻击:
还是如上的过滤器:同样处理掉HTML和js的特殊字段,正常逻辑应该是正则表达式匹配,但是后来同事给了一个有意思的思路,将标签<替换成中文格式的《,其实觉着这个挺好的,即省事,又不会完全破坏原来字符的意思。


版权声明:本文为sinat_31396769原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
THE END
< <上一篇
下一篇>>