1 明文密码传输,解决办法:https
2 XSS,攻击方式:在提交的表单中写入javascript脚本。解决办法:页面显示时,对特殊符号进行转换,如
显示结果 | 描述 | 实体名称 | 实体编号 |
---|---|---|---|
空格 | |   | |
< | 小于号 | < | < |
> | 大于号 | > | > |
& | 和号 | & | & |
" | 引号 | " | " |
' | 撇号 | ' (IE不支持) | ' |
或者用JSTL标签<c:out>进行输出,它会自动进行转换。
3 MHTML协议代码执行漏洞MS11-026
参考 https://zhuanlan.zhihu.com/p/27664793
解决办法:对Base64编码后的XSS攻击也要防
4 CSRF,攻击方式:恶意网站伪造用户向正常网站提交表单。解决办法:第1种方法,在表单中增加伪随机数,服务端进行验证;第2种方法,HTTP头的"Referer"检查,看是否本网站页面发送的请求
5 SQL注入,攻击方式:表单中插入SQL脚本。解决办法:方法1,表单数据过滤掉SQL命令关键字;方法2,用preparestatme组织SQL JDBC查询
6 会话标识未更新:解决办法:
request.getSession().invalidate();//清空session
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
IBM对AppScn SQL盲注误报的说明
http://www-01.ibm.com/support/docview.wss?uid=swg21674465
大意是:
造成AppScan“SQL盲注”误报的常见原因
原因:
和SQL注入不同,SQL盲注只是用近似的、但逻辑相反的SQL字符串,输入到被注入的应用,如果得到服务器的响应不同,就作为证明。
结果,SQL盲注更易造成误报。因为在响应中,很多因素如:服务器负载、状态也可能导致不同的反应。
AppScan本身也会造成服务器超载,因为它可能会在短时间内发送数千或数百万计的请求。
答案:
若要验证是否真的存在SQL盲注,可以按以下几步(建议参考1和4):
1 总是对发现点进行单独的重新扫描,确保服务器是在最低负荷下。如果是误报,这里的检查将不再会报SQL盲注
2 如果目标应用需要登录...
3 ...
4 分析步骤1得到的HTTP响应。如果目标页面相对较小且有一些动态元素嵌入在响应中,AppScan判断SQL盲注的阀值“95%匹配”可能偏高,需要调低
http://www-01.ibm.com/support/docview.wss?uid=swg21674465
大意是:
造成AppScan“SQL盲注”误报的常见原因
原因:
和SQL注入不同,SQL盲注只是用近似的、但逻辑相反的SQL字符串,输入到被注入的应用,如果得到服务器的响应不同,就作为证明。
结果,SQL盲注更易造成误报。因为在响应中,很多因素如:服务器负载、状态也可能导致不同的反应。
AppScan本身也会造成服务器超载,因为它可能会在短时间内发送数千或数百万计的请求。
答案:
若要验证是否真的存在SQL盲注,可以按以下几步(建议参考1和4):
1 总是对发现点进行单独的重新扫描,确保服务器是在最低负荷下。如果是误报,这里的检查将不再会报SQL盲注
2 如果目标应用需要登录...
3 ...
4 分析步骤1得到的HTTP响应。如果目标页面相对较小且有一些动态元素嵌入在响应中,AppScan判断SQL盲注的阀值“95%匹配”可能偏高,需要调低