常见安全漏洞和解决方案

年4月19日常见安全漏洞和解决方案文档仅供参考身份认证安全弱密码密码长度6个字符以上密码字符必须包含大写字母、小写字母和数字，并进行密码复杂度检查强制定期更换密码密码存储安全密码存储必须使用单向加密单纯的md5,sha1容易被破解，需要添加随机的盐值salt涉及支付及财产安全的需要更高的安全措施，单纯的密码加密已经不能解决问题。能够考虑手机验证码、数字证书、指纹验证。密码传输安全密码前端加密用户名、密码传输过程对称加密，能够使用密钥正确对称加密，前端使用公钥加密，后端使用私钥解密。前端加密示例引入脚本，rsa加密工具和md5加密工具...<scriptsrc="${resourcepath}/jsencrypt/bin/jsencrypt.min.js"type="text/javascript"></script><scriptsrc="${resourcepath}/jshash-2.2/md5-min.js" type="text/javascript"></script>...前端加密脚本，省略了提交步骤…<script>... //rsa加密, varpublicKey='${rsaPublicKey}'; varencrypt=newJSEncrypt(); encrypt.setPublicKey(publicKey); //加密 varusername=encrypt.encrypt($('input[name=username]').val()); varpassword=encrypt.encrypt($('input[name=password]').val());...</script>…注意：前端密码加密如果还用了md5加密的，先md5加密再rsa加密。后端解密，省略了其它验证步骤ShiroUserServiceImpl.java… publicShiroUsergetUser(Stringname,IntegeruserType,IntegerloginType){ name=RSAUtils.decryptBase64(name);… }… publicbooleandoValidUser(ShiroUsershiroUser,Stringpassword){ password=RSAUtils.decryptBase64(password);… }启用https协议登录页面、支付页面等高危页面强制https协议访问。前端加密和https能够结合使用SQL注入描述SQL注入攻击是黑客对数据库进行攻击的常见手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。可是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户能够提交一段数据库查询代码，根据程序返回的结果，获得某些她想得知的数据，这就是所谓的SQLInjection，即SQL注入。解决办法养成编程习惯，检查用户输入，最大限度的限制用户输入字符集合。不要把没有检查的用户输入直接拼接到SQL语句中，断绝SQL注入的注入点。SQL中动态参数全部使用占位符方式传参数。正确...List<Object>params=newArrayList<Object>();Stringsql="select*fromuserwherelogin_namelike?";params.add(username);...正确...Map<String,Object>params=newHashMap<String,Object>();Stringsql="select*fromuserwherelogin_namelike:loginname";params.put("username",username);...错误...Stringsql="select*fromuserwherelogin_name='"+username+"'";...如果不能使用占位符的地方一定要检查SQL中的特殊符号和关键字，或者启用用户输入白名单，只有列表包含的输入才拼接到SQL中，其它的输入不能够。Stringsql="select*from"+SqlTools.filterInjection(tablename);应急解决方案nginx过滤规则naxsi模块axsi_nbs.rules##Enableslearningmode#LearningMode;SecRulesEnabled;#SecRulesDisabled;DeniedUrl"/50x.html";##checkrulesCheckRule"$SQL>=8"BLOCK;CheckRule"$RFI>=8"BLOCK;CheckRule"$TRAVERSAL>=4"BLOCK;CheckRule"$EVADE>=4"BLOCK;CheckRule"$XSS>=8"BLOCK;标红部分就是SQL注入过滤规则启用级别。基础滤规则已经级别定义省略，可自己定义。跨站点脚本攻击（XSS）描述XSS（CrossSiteScripting，跨站脚本漏洞），是Web应用程序在将数据输出到网页的时候存在问题，导致攻击者能够将构造的恶意数据显示在页面的漏洞。解决办法养成编程习惯，检查用户输入，最大限度的限制用户输入字符集合。不要把用户输入直接显示到页面，不要相信用户的输入。编码把用户输入编码后输出正确...<c:outvalue="${用户输入}"></c:out>...错误...${用户输入}"...富文本编辑器和直接显示编辑的HTML，项目总尽量不要开放，如果开放就要严格检查XSS敏感HTML片段，而且严格控制用户权限，做好IP限制这些安全措施。注意：所有XSS过滤器如果要保证过滤后HTML能正常浏览，都只能过滤部分已知的XSS攻击，开发HTML编辑始终存在风险和隐患。应急解决方案web过滤器web.xml... <!--跨站点脚本过滤 参数：excludeUrl排除链接，不参与过滤的链接，支持ant风格的通配符 参数：strict是否严格模式，严格模式基本只要有大于小于都会拦截，宽松模式只拦截script这些已知的攻击脚本 --> <filter> <filter-name>IllegalCharacterFilter</filter-name> <filter-class> com.wondersgroup.wssip.framework.web.filter.IllegalCharacterFilter </filter-class> <init-param> <param-name>excludeUrl</param-name> <param-value>/resource/*,/**/*.images</param-value> </init-param> <init-param> <param-name>strict</param-name> <param-value>false</param-value> </init-param> </filter> <filter-mapping> <filter-name>IllegalCharacterFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>...注意：这种方式效率低下，对应大数据提交响应很慢，不推荐。HTML编辑器会被这个过滤器拦截，需要特殊处理。nginx过滤规则naxsi模块axsi_nbs.rules##Enableslearningmode#LearningMode;SecRulesEnabled;#SecRulesDisabled;DeniedUrl"/50x.html";##checkrulesCheckRule"$SQL>=8"BLOCK;CheckRule"$RFI>=8"BLOCK;CheckRule"$TRAVERSAL>=4"BLOCK;CheckRule"$EVADE>=4"BLOCK;CheckRule"$XSS>=8"BLOCK;标红部分就是XSS注入过滤规则启用级别。基础滤规则已经级别定义省略，可自己定义。默认的规则8级只要带<>符号的通通拦截。跨站请求伪造（CSRF）描述CSRF（CrossSiteRequestForgery,跨站域请求伪造）是一种网络的攻击方式，该攻击能够在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作，有很大的危害性。解决办法验证HTTPReferer字段在请求地址中添加token并验证服务器生成token，输入界面获取token，提交是带上token，服务器验证token注意！关键操作，还需要加入用户交互操作比如付款，转账这样的操作一定要用户再次输入密码(或者独立的支付密码)，在加上可靠的图片验证码或者手机验证码。在HTTP头中自定义属性并验证应急解决方案web过滤器web.xml... <!--CSRF（CrossSiteRequestForgery,跨站域请求伪造）过滤 参数：excludeUrl排除链接，不参与过滤的链接，支持ant风格的通配符 参数：refererUrl允许的referer，支持ant风格的通配符 --> <filter> <filter-name>CsrfFilter</filter-name> <filter-class> com.wondersgroup.wssip.framework.web.filter.CsrfFilter </filter-class> <init-param> <param-name>excludeUrl</param-name> <param-value>/resource/*,/**/*.images</param-value> </init-param> <init-param> <param-name>refererUrl</param-name> <param-value>:9080/**/*,:4443/**/*</param-value> </init-param> </filter> <filter-mapping> <filter-name>CsrfFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>...注意：修改允许的referer白名单refererUrl。X-Frame-Options未配置解决办法apachehttp.conf...#setX-Frame-Options<IfModulemod_headers.c>HeaderalwaysappendX-Frame-OptionsSAMEORIGIN</IfModule>...注意：apache24默认就配置了nginxnginx.conf...add_headerX-Frame-OptionsSAMEORIGIN;...能够加在location...location/{add_headerX-Frame-OptionsSAMEORIGIN;}...服务器启用了TRACE方法解决办法apache2.0.55版本以后http.conf...TraceEnableoff...2.0.55版本以前http.conf...LoadModulerewrite_modulemodules/mod_rewrite.so...在各虚拟主机的配置文件里添加如下语句：...RewriteEngineOnRewriteCond%{REQUEST_METHOD}^(TRACE|TRACK)RewriteRule.*-[F]...nginxnginx.conf...#限制访问的方法if($request_method!~^(GET|HEAD|POST)$)