SQL注入攻击(SQL injection)
危害度: 高
通常原因:
直接使用页面输入的内容来拼接组建SQL文。
例如:
String sql = "DELETE FROM member WHERE email = '" + email + "' AND password = '" + password + "'";
如果传入一下输入以下数据的话
email = "test@test.com"
password = "' or 1 = 1"
组建的SQL就会变成
sql = "DELETE FROM user WHERE email = 'test@test.com' AND password = '' or 1 = 1
解决对策:
现在的大多数Web开发框架都集成了这一问题的自动解决方案。如果在项目中使用了框架的话,
除非是特殊的检索,否则,自己不用再额外做什么应对措施的。
如果没有使用框架的话,那么可以采取两个对策。
(1)对于用户输入做严格验证,比如数字、日期之类的合法性等,这个有助于减少隐患。
(2)在拼接组建SQL文的时候,对特殊文字进行escape。需要转义字符因数据库而不同,一般都会包括: ' => '' 和 \ => \\
跨站脚本攻击(Cross Site Scripting,缩写XSS)
危害度: 中
通常原因:
程序中,直接将用户的输入数据显示到页面上。
例如:在某论坛,有恶意用户A发布带脚本的帖子,由于输入数据原样显示在页面中,所以显示页面的时候该脚本可执行。
此时,如果用户B浏览到该网页时,用户B的就会受到侵害,如个人信息泄露,遭受病毒、木马等。
此类问题容易出现在论坛社交类网站。(没事还是少上不正规的黄色论坛的好!!)
解决策略:
(1) 用户的输入内容如果直接以文本的形式输出到页面的话,对以下字符进行转义。
「&」 ⇒ 「&」
「<」 ⇒ 「<」
「>」 ⇒ 「>」
「"」 ⇒ 「"」
「'」 ⇒ 「'」 PS: 这个不转义其实也没事
(2) 用户的输入内容如果作为标签属性输出的话,一定要包含到引号里。
PS:应该在项目开始之初就定制成通用方案,并且在今后的项目中重复利用。
换行符注入攻击(或者叫“HTTP header 注入攻击”, 英文:HTTP Header Injection)
危害度: 中
通常原因:
程序里直接将用户输入数据作为response的一部分内容返回给用户了。此时,如果用户的输入数据包含了换行符的话,就可以恶意篡改HTTP信息,如cookie等。
例如:
通过如下URL访问网站
http://www.test.com/?a=%0d%0aSet-Cookie:%20userId%3d999
如果程序里直接在response.sendRedirect的URL里使用参数a的值的话,用户cookie里的数据就会篡改。
解决策略:
(1)加强参数的合法性检查
(2)用户的输入参数在response的field里使用之前,去除换行符。
使用HTTP协议传输重要信息或者用户个人信息。
危害度: 中
解决策略:
使用SSL协议(即HTTPS)传输重要信息或者用户个人信息。
访问地址被任意导向
危害度: 低
通常原因:
当通过参数来传递url时,参数值被恶意篡改的话,用户就会恶意导向一些别的网站(如含有病毒或木马的网站)。
例如:程序对如下URL的处理后,会返回returnUrl的页面
http://www.test.com/login?returnUrl=xxxxxxx
如果returnUrl被恶意篡改的话,用户就会被导向恶意网站。
解决策略:
(1)加强参数的合法性检查,如domain等(2)对参数值进行加密
暴露服务器IP
危害度: 低
通常原因:
当apache的VirtualHost里的ServerName没设置成domain时,
请求头里Host项目去掉后的HTTP1.0请求访问网站时,response信息的Location里会暴露服务器的IP,有可能招致更多别的攻击。
PS:HTTP1.0请求才有这问题,HTTP1.1的请求Host项是必须的,没有的话报400 Bad Request错误。
解决策略:
apache的VirtualHost里的ServerName没设置成domain
未防止CSRF伪造请求
危害度: 中
通常原因:
对于客户端提交的表单没有防伪造的防范。
恶意用户可以伪造请求提交;后者普通用户受到CSRF攻击时被提交。
从而造成服务器负荷严重而宕机或者造成用户的个人损失。
解决策略:
(1)在表单里增加用于验证的随机数hidden (2)使用认证码CAPTCHA
(3)对请求头的Referer进行合法性验证,判断提交前的页面是否为站内页面
Cookie的HttpOnly没有设置为true
危害度: 中
通常原因:
HttpOnly没有设置为true的cookie数据,允许被JavaScript脚本访问,如果遭到跨站脚本攻击的话,
用户的cookie数据就有可能暴露。
解决策略:
(1)在服务器配置文件里统一配置。如Tomcat的server.xml的userHttpOnly="true"。(2)代码里网Cookie里存数据时,指定HttpOnly为true。
系统发生异常时暴露代码细节
危害度:小
通常原因:
代码里对没有预期的异常没有作统一的处理。直接抛出到页面了。
解决策略:
系统的异常处理设计时,对未预期的异常进行捕获,页面输出特定信息。
危害度:小
通常原因:
一些恶意网站隐藏提交目标为本网站的iframe,用户访问这些恶意网站时遭受点击劫持提交了表单的话,
会产生用户购买或注销等行为。
解决策略:
通过代码或服务器配置,设置X-Frame-Options项,禁止或者只允许相同domain的frame请求。
如apache里添加 Header always append X-Frame-Options SAMEORIGIN
浏览器保存了重要信息的缓存
危害度:小
通常原因:
一些显示重要信息或者用户个人信息的页面,没有设置清除缓存。
解决策略:
页面里添加如下tag或者直接后台代码里设置response里的这三项。
<meta http-equiv="Pragma" content="no-cache" /><meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Expires" content="Fri, 1 Jan 2010 00:00:00 GMT" />