对于某些敏感的系统例如支付、交易需要为其加固,有必要将可能的攻击情况考虑进来加以防范,于是有了这么一个简易的安全框架。在前辈的代码上( 详见 :http://blog.csdn.net/zhongweijian/article/details/8680737)我大幅度重构,更好地理解 Java Web 安全实施措施。
源代码在:http://git.oschina.net/sp42/ajaxjs/tree/master/ajaxjs-security?dir=1&filepath=ajaxjs-security
该框架基于 Sevlet 过滤器和若干 HttpServletRequest/HttpServletResponse 覆盖的方式增加一些输入输出的过滤。如下表格显示了可支持的哪些攻击。
作用 | 对应类名 | 加载方式 | init-param |
---|---|---|---|
XSS过滤 | com.ajaxjs.web.security.wrapper.XSS_Request/XSS_Response | wrapper | enableXSSFilter |
Header CLRF 过滤 | com.ajaxjs.web.security.wrapper.CLRF_Response | wrapper | enableCLRF_Filter |
Cookies Key 验证和大小验证 | com.ajaxjs.web.security.wrapper.CookieRequest/CookieResponse | wrapper | cookieWhiteList(配置白名单) |
文件上传后缀验证 | com.ajaxjs.web.security.wrapper.UploadRequest | wrapper | uploadfileWhiteList(配置白名单) |
CSRF 攻击 | com.ajaxjs.web.security.filter.CSRF | filter | encryCookieKey(配置 key) |
Session 通过加密存储到 cookie | com.ajaxjs.web.security.filter.EncrySessionInCookie | filter | encryCookieKey(配置 key) |
POST 白名单/黑名单机制验证 | com.ajaxjs.web.security.filter.Post | filter | postWhiteList/postBlackList(配置白名单/黑名单) |
Referer 来路检测 | com.ajaxjs.web.security.filter.RefererFilter | filter | RefererFilter(配置 key) |
所有检测都由 ConfigLoader 负责读取配置和启动。是否启动某项功能取决于配置有否,只要有配了的话,该功能点就生效,反之则不启用。如表格上的 init-param 对应的是 web.xml 里面配置的内容。
加载方式指的是在 filter 中主动检测,一般是执行 check() 方法,传入 request/response 即可;而 wrapper 是指被动方式检测、过滤,具体说是对 Java API 方式覆盖来包含检测手段,类似于设计模式的 Template 模版方法,使得调用者在不改变 API 的前提下又能加入新的逻辑。特别地可以了解下 HttpServletRequestWrapper/HttpServletResponseWrapper 这两个原生 API。
使用方法:引入 jar 包并添加 web.xml 配置。
<!-- 防御 --> <filter> <filter-name>SecurityFilter</filter-name> <filter-class>com.ajaxjs.web.security.ConfigLoader</filter-class> <!-- 是否启动 XSS 过滤 --> <init-param> <param-name>enableXSSFilter</param-name> <param-value>true</param-value> </init-param> <!-- 是否启动 CLRF 过滤 --> <init-param> <param-name>enableCLRF_Filter</param-name> <param-value>true</param-value> </init-param> <!-- Session 通过加密存储到 cookie --> <init-param> <param-name>encryCookieKey</param-name> <param-value>1234567887654321</param-value> </init-param> <!-- Cookies 白名单机制验证和大小验证 --> <init-param> <param-name>cookieWhiteList</param-name> <param-value>id,JESSIONID,name,clrf</param-value> </init-param> <!-- 文件上传后缀白名单 过滤 --> <init-param> <param-name>uploadfileWhiteList</param-name> <param-value>jpg,png,doc,xls</param-value> </init-param> <!-- CSRF 攻击 过滤 --> <init-param> <param-name>CSRF_Filter</param-name> <param-value>true</param-value> </init-param> <!-- POST 白名单/黑名单机制验证(支持正则匹配) --> <init-param> <param-name>postWhiteList</param-name> <param-value>/d/sssecurity, /user/aaa/name*</param-value> </init-param> <init-param> <param-name>postBlackList</param-name> <param-value>true</param-value> </init-param> <!-- 配置 Security 异常发生后跳转 url 参数 --> <init-param> <param-name>redirectUrlt</param-name> <param-value>http://localhost:8080/[0-9A-Za-z]*,http://www.taobao.com/[0-9A-Za-z]*</param-value> </init-param> </filter> <filter-mapping> <filter-name>SecurityFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <!-- // -->
具体防御原理可参见我之前写的博客《 网络信息系统安全检测方案设计(上、下)》。
值得注意的是本方案没有考虑 SQL 注入,这是因为 SQL 注入在 DAO 层面已经完成了。