常见安全漏洞和解决方案.docx
《常见安全漏洞和解决方案.docx》由会员分享,可在线阅读,更多相关《常见安全漏洞和解决方案.docx(13页珍藏版)》请在冰豆网上搜索。
![常见安全漏洞和解决方案.docx](https://file1.bdocx.com/fileroot1/2023-6/15/447b3a1f-13f1-4359-8193-e26ae8998558/447b3a1f-13f1-4359-8193-e26ae89985581.gif)
常见安全漏洞和解决方案
1.1身份认证安全
1.1.1弱密码
●密码长度6个字符以上
●密码字符必须包含大写字母、小写字母和数字,并进行密码复杂度检查
●强制定期更换密码
1.1.2密码存储安全
密码存储必须使用单向加密
单纯的md5,sha1容易被破解,需要添加随机的盐值salt
涉及支付及财产安全的需要更高的安全措施,单纯的密码加密已经不能解决问题。
可以考虑手机验证码、数字证书、指纹验证。
1.1.3密码传输安全
1.1.3.1密码前端加密
用户名、密码传输过程对称加密,可以使用密钥对的对称加密,前端使用公钥加密,后端使用私钥解密。
前端加密示例
引入脚本,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());
..。
…
注意:
前端密码加密如果还用了md5加密的,先md5加密再rsa加密。
后端解密,省略了其他验证步骤
ShiroUserServiceImpl。
java
…
ﻩpublic ShiroUsergetUser(Stringname,Integer userType,IntegerloginType) {
ﻩﻩname=RSAUtils。
decryptBase64(name);
…
}
…
public boolean doValidUser(ShiroUsershiroUser,Stringpassword) {
ﻩpassword=RSAUtils.decryptBase64(password);
…
}
1.1.3.2启用https协议
登录页面、支付页面等高危页面强制https协议访问。
前端加密和https可以结合使用
1.2SQL注入
1.2.1描述
SQL注入攻击是黑客对数据库进行攻击的常用手段之一.随着B/S模式应用开发的发展,使用这种模式编写应用程序的程序员也越来越多。
但是由于程序员的水平及经验也参差不齐,相当大一部分程序员在编写代码的时候,没有对用户输入数据的合法性进行判断,使应用程序存在安全隐患。
用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想得知的数据,这就是所谓的SQLInjection,即SQL注入。
1.2.2解决办法
1.养成编程习惯,检查用户输入,最大限度的限制用户输入字符集合.
2.不要把没有检查的用户输入直接拼接到SQL语句中,断绝SQL注入的注入点。
●SQL中动态参数全部使用占位符方式传参数.
正确
。
..
List〈Object> params=newArrayList〈Object>();
Stringsql = ”select*fromuser wherelogin_namelike?
";
params.add(username);
。
.。
正确
..。
Mapparams= newHashMap<String,Object>();
Stringsql ="select* from userwherelogin_namelike:
loginname";
params.put(”username”,username);
...
错误
。
.。
Stringsql= ”select*fromuser wherelogin_name='"+ username+"'";
.。
.
●如果不能使用占位符的地方一定要检查SQL中的特殊符号和关键字,或者启用用户输入白名单,只有列表包含的输入才拼接到SQL中,其他的输入不可以。
Stringsql= "select*from”+SqlTools.filterInjection(tablename);
1.2.3应急解决方案
nginx过滤规则naxsi模块
axsi_nbs.rules
##Enables learningmode
#LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl”/50x。
html";
##check rules
CheckRule "$SQL >=8" BLOCK;
CheckRule ”$RFI〉=8"BLOCK;
CheckRule”$TRAVERSAL〉=4"BLOCK;
CheckRule ”$EVADE〉= 4"BLOCK;
CheckRule"$XSS 〉= 8" BLOCK;
标红部分就是SQL注入过滤规则启用级别.
基础滤规则已经级别定义省略,可自己定义。
1.3跨站点脚本攻击(XSS)
1.3.1描述
XSS(Cross SiteScripting,跨站脚本漏洞),是Web应用程序在将数据输出到网页的时候存在问题,导致攻击者可以将构造的恶意数据显示在页面的漏洞。
1.3.2解决办法
1养成编程习惯,检查用户输入,最大限度的限制用户输入字符集合。
2不要把用户输入直接显示到页面,不要相信用户的输入。
●编码把用户输入编码后输出
正确
。
。
。
outvalue="${用户输入}"〉〈/c:
out〉
..。
错误
.。
.
${用户输入}”
...
●富文本编辑器和直接显示编辑的HTML,项目总尽量不要开放,如果开放就要严格检查XSS敏感HTML片段,并且严格控制用户权限,做好IP限制这些安全措施.
注意:
所有XSS过滤器如果要保证过滤后HTML能正常浏览,都只能过滤部分已知的XSS攻击,开发HTML编辑始终存在风险和隐患。
1.3.3应急解决方案
web过滤器
web。
xml
..。
ﻩ
—-跨站点脚本过滤
参数:
excludeUrl排除链接,不参与过滤的链接,支持ant风格的通配符
参数:
strict是否严格模式,严格模式基本只要有大于小于都会拦截,宽松模式只拦截script这些已知的攻击脚本
ﻩ-->
<filter>
ﻩ〈filter—name〉IllegalCharacterFilter〈/filter—name>
ﻩﻩ
ﻩﻩcom。
wondersgroup.wssip。
framework.web.filter。
IllegalCharacterFilter
ﻩ〈/filter-class>
〈init-param〉
ﻩ〈param—name>excludeUrl
ﻩﻩ〈param—value>/resource/*,/**/*。
images</param-value>
ﻩ</init—param>
<init—param〉
ﻩﻩﻩ〈param—name〉strict</param-name>
ﻩ〈param-value>false
ﻩ</init-param〉
ﻩ
ﻩﻩ<filter-name>IllegalCharacterFilter
<url-pattern〉/*〈/url-pattern〉
ﻩ</filter—mapping>
...
注意:
这种方式效率低下,对应大数据提交响应很慢,不推荐。
HTML编辑器会被这个过滤器拦截,需要特殊处理。
nginx过滤规则naxsi模块
axsi_nbs.rules
##Enableslearningmode
#LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl”/50x。
html”;
## check rules
CheckRule”$SQL>=8"BLOCK;
CheckRule”$RFI 〉= 8"BLOCK;
CheckRule”$TRAVERSAL 〉=4” BLOCK;
CheckRule ”$EVADE>= 4" BLOCK;
CheckRule"$XSS>=8"BLOCK;
标红部分就是XSS注入过滤规则启用级别.
基础滤规则已经级别定义省略,可自己定义。
默认的规则8级只要带<>符号的通通拦截。
1.4跨站请求伪造(CSRF)
1.4.1描述
CSRF(CrossSiteRequestForgery,跨站域请求伪造)是一种网络的攻击方式,该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作,有很大的危害性。
1.4.2解决办法
1.验证 HTTPReferer字段
2.在请求地址中添加 token并验证
服务器生成token,输入界面获取token,提交是带上token,服务器验证token
注意!
关键操作,还需要加入用户交互操作
比如付款,转账这样的操作一定要用户再次输入密码(或者独立的支付密码),在加上可靠的图片验证码或者手机验证码。
3.在HTTP头中自定义属性并验证
1.4.3应急解决方案
web过滤器
web.xml
。
..
—- CSRF(CrossSiteRequestForgery,跨站域请求伪造)过滤
参数:
excludeUrl排除链接,不参与过滤的链接,支持ant风格的通配符
参数:
refererUrl 允许的referer,支持ant风格的通配符
-->
ﻩ〈filter>
<filter-class>
ﻩcom.wondersgroup。
wssip.framework.web。
filter.CsrfFilter
ﻩﻩfilter-class〉
ﻩ<param-name>excludeUrl
ﻩﻩﻩ〈/init-param〉
〈init—param〉
refererUrl</param-name〉
ﻩ<param—value〉http:
//127.0.0.1:
9080/**/*,https:
//127。
0。
0。
1:
4443/**/*〈/param—value〉
ﻩﻩ</init-param〉
〈filter—mapping〉
ﻩﻩ<filter-name〉CsrfFilterfilter-name〉
ﻩ<url-pattern>/*</url—pattern>
ﻩ
...
注意:
修改允许的referer白名单refererUrl。
1.5X-Frame-Options未配置
1.5.1解决办法
1.5.1.1apache
http.conf
。
。
。
#setX-Frame-Options
HeaderalwaysappendX—Frame-OptionsSAMEORIGIN
。
..
注意:
apache24默认就配置了
1.5.1.2nginx
nginx。
conf
。
。
.
add_header X-Frame-Options SAMEORIGIN;
.。
。
可以加在location
..。
location/
{
add_headerX-Frame-OptionsSAMEORIGIN;
}
。
。
.
1.6服务器启用了TRACE方法
1.6.1解决办法
1.6.1.1apache
2.0.55版本以后
http。
conf
..。
TraceEnableoff
..。
2.0.55版本以前
http。
conf
。
。
.
LoadModulerewrite_modulemodules/mod_rewrite。
so
。
。
。
在各虚拟主机的配置文件里添加如下语句:
。
..
RewriteEngineOn
RewriteCond%{REQUEST_METHOD}^(TRACE|TRACK)
RewriteRule .* - [F]
...
1.6.1.2nginx
nginx.conf
.。
.
#限制访问的方法
if($request_method!
~^(GET|HEAD|POST)$){
return 403;
}
。
..
可以加在server
...
server{
..。
if($request_method!
~^(GET|HEAD|POST)$){
return403;
}
。
.。
}
.。
。
1.7隐藏服务器版本号
1.7.1解决办法
1.7.1.1apache
http.conf或者 http—default。
conf
。
..
ServerTokensProd。
。
.
1.7.1.2nginx
nginx。
conf
...
server_tokensoff;
。
..
可以加在http
.。
。
http{
。
.。
server_tokensoff;
。
..
}
。
..