WEB开发安全漏洞原因分析及解决..docVIP

WEB开发安全漏洞 原因分析及解决 文档控制 修改记录 日期 修改类型 作者 版本 备注 目 录 1 会话标识未更新 5 1.1 原因 5 1.2 解决 5 2 SQL注入 6 2.1 原因 6 2.2 解决 7 3 XSS跨站脚本编制 8 3.1 原因 8 3.2 解决 8 4 XSRF跨站请求伪造 10 4.1 原因 10 4.2 解决 10 4.2.1 使用的Struts框架开发的web应用 11 4.2.2 Jsp+javabean开发的web应用 13 5 登录错误消息凭证枚举（不充分帐户封锁） 15 5.1 原因 15 5.2 解决 15 6 HTML注释敏感信息泄露 15 6.1 原因 15 6.2 解决 15 7 应用程序错误 15 7.1 原因 15 7.2 解决 15 8 已解密的登录请求 15 8.1 原因 15 8.2 解决 16 8.2.1 prototype版 16 8.2.2 JQuery版 16 9 启用了不安全的HTTP方法 17 9.1 原因 17 9.2 解决 17 10 禁止页面缓存 18 10.1 原因 18 10.2 解决 18 11 数据库错误模式 18 11.1 原因 18 11.2 解决 19 12 SQL注入文件写入（需要用户验证） 19 12.1 原因 19 12.2 解决 20 13 不充分的帐号封锁 20 13.1 原因 20 13.2 解决 20 14 链接注入（便于跨站请求伪造） 21 14.1 原因 21 14.2 解决 21 15 通过框架钓鱼 22 16 Caucho Resin resin-admin跨站点脚本编制 22 16.1 原因 22 16.2 解决 22 17 HTTP 响应分割 22 17.1 原因 22 17.2 解决 23 18 Apache Tomcat Web表单哈希冲突拒绝服务漏洞 24 18.1 原因 24 18.2 解决 24 19 会话cookie中缺少HttpOnly属性 24 19.1 原因 24 19.2 解决 24 20 基于 DOM 的跨站点脚本编制 25 20.1 原因 25 20.2 解决 26 21 主机允许从任何域进行 flash 访问 27 21.1 原因 27 21.2 解决 27  会话标识未更新 原因 在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说还是以前的那个session（事实上session也确实不会改变，因为没有建立新session，原来的session也没有被销毁）。会话invalidate没有用request.getSession().invalidate();），是因为invalidate方法不是真正的将session销毁，只是将session中的内容清空，所以当invalidate以后再新建session，新建的session其实不是新的，是将之前的session重新启用了。于是session的id不变就不奇怪了。 Cookie[] cookies = request.getCookies(); for (int i = 0; i cookies.length; i++) { if (cookies[i].getName().toUpperCase().equals(JSESSIONID)) cookies[i].setMaxAge(0); } 解决 在登录页面上加上一段代码： request.getSession().invalidate() ; //清空session if (request.getCookies()!=null) { Cookie[] cookies = request.getCookies(); for (int i = 0; i cookies.length; i++) { if (cookies[i].getName().toUpperCase().equals(JSESSIONID)) cookies[i].setMaxAge(0); // 让JSESSIONID cookie过期 } }没有正确过滤转义字符在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞：statement := SELECT * FROM users WHERE name = + userName + ; 将用户名变量(即username)设置为：a or t=t，此时