常见WEB开发安全漏洞原因分析及解决.docxVIP

常见WEB开发安全漏洞原因分析及解决 常见WEB开发安全漏洞 原因分析及解决 目录 1会话标识未更 新 3 1.1 1.2 2原 因 3解 决 3 SQL 注 入 3 2.1 2.2原 因 3解 5 XSS跨站脚本编 制 5 3.1 3.2原 因 5解 决 5 XSRF跨站请求伪 造 7 4.1 4.2原 因 7解 决 8 5登录错误消息凭证枚举（不充分帐户封 锁） 8 5.1 5.2原 因 8解 决 8 6 HTML注释敏感信息泄 露 ....9 6.1 6.2原 因 9解 决 9 7应用程序错 误 9 7.1 7.2原 因 9解 9 8已解密的登录请 求 9 8.1 8.2原 因 9解 决 9 9启用了不安全的HTTP方 法 10 9.1 9.2原 因 10解 决 10 禁止页面缓 存 11 因 11 解 决 11 数据库错误模 式 11 原 因 11解 决 12 10 10.110.2 11 11.111.2 1会话标识未更新 1.1原因 在用户进入登录页面，但还未登录时，就已经产生了一个session,用 户输入信息，登录以后，session的id不会改变，也就是说还是以前的那 个session (事实上session也确实不会改变，因为没有建立新session,原 来的session也没有被销毁)。 很多人只是让会话 invalidate 没有用(request.getSession().invalidate();), 是因为invalidate方法不是真正的将session销毁，只是将session中的内容清空,所以当invalidate以后再新建session,新建的session其实不是新的， 是将Z前的session重新启用了。于是session的id不变就不奇怪了。只有 cookie失效掉，才能换成新的session id 1.2解决 在登录页面上加上一段代码：request.getSession().invalidate(); 〃清空 session if (request.getCookies()!二null) { Cookie cookie = request.getCookies()[0]; // 获取 cookie cookie.setMaxAge(O); // 让 cookie 过期 } 注：会话失效后，请不要在代码前面使用SESSION保存数据。 2 SQL注入 2.1原因 没冇正确过滤转义字符 在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻 击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数 据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞： statement := “SELECT * FROM users WHERE name = #39;” + userName + #39;;11 将用户名变量(即 将用户名变量(即username)设f a#39; or #39;t#39;=#39;t, 此时原始语句发牛了变化. 用户输入错误的数据类型 如果一个用户提供的字段并非一个强类型，或者没有实施类型强制, 就会发生这种形式的攻击。 当在一个SQL语句中使用一个数字字段时，如果程序员没有检查用户 输入的合法性(是否为数字型)就会发生这种攻击。例如： statement := SELECT * FROM data WHERE id = + a_variable + 从这个语句可以看出，作者希望a_variable是一个与“id”字段有关 的数字。不过，如果终端用户选择一个字符串，就绕过了对转义字符的需 要。例如，将 a_variable 设置＞9:1; DROP TABLE users,它会将 “users” 表 从数据库中删除，SQL语句变成： SELECT * FROM DATA WHERE id = 1; DROP TABLE users; 数据库服务器中的漏洞 有时，数据库服务器软件中也存在着漏洞，如MYSQL服务器中 mysql_real_escape_string()函数漏洞。这种漏洞允许一个攻击者根据错误的 统一字符编码执行一次成功的SQL注入式攻击。 盲目SQL注入式攻击 当一个Web应用程序易于遭受攻击而其结果对攻击者却不见时，就会 发生所谓的肓目SQL注入式攻击。有漏洞的网页可能并不会显示数据，而 是根据注入到合法语句中的逻辑语句的结果显示不同的内容。这种攻击相 当耗时，因为必须为每一个获得的字节而精心构造一个新的语句。但是一 口漏洞的位置和冃标信息的位置被确立以后，一种称为Absinthe的工具就 可以使这