常见web安全漏洞及修复建议

常见WEB漏洞

高危漏洞

SQL Injection（SQL注入攻击）

漏洞描述

通过把SQL命令插入到Web表单递交或输入域名、页面请求的查询字符串中，最终达到欺骗服务器执行恶意的SQL命令。

示例：

以输入用户名、密码进行登录校验为例，当程序中存在SQL拼接时，可能发生的SQL注入攻击

• 代码中使用拼接SQL，验证用户是否存在

JdbcConnection conn = new JdbcConnection();
// 拼接SQL,引起 SQL 注入
String sql = "select * from user where name = '" + request.getParameter("name") + "' and pwd='"+request.getParameter("pwd")+"'";

conn.execqueryResultSet(sql);

• mybatis中的使用’$'符号取值拼接SQL，验证用户是否存在

    
    select * from user where name = ${value} and pwd = ${pwd}

当pwd参数传值为（1’ or ‘1’='1），此时sql结果为真，可以进入后台

   select * from user 
   where 
   		name = 'admin' and pwd = '1' or '1'= '1'

当pwd参数传值为（1’ or exists(select 列名 from 表名) --），使用"–"注释符规避语法错误，可以根据是否成功进一步猜测表名和列名

   select * from user 
   where 
   		name = 'admin' 
   		and pwd = '1' or exists(select 列名 from 表名) --'

修复建议

1. 所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
2. 对进入数据库的特殊字符（’”<>&*;等）进行转义处理，或编码转换。
3. 确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
4. 数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
5. 网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
6. 严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
7. 避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
8. 在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。

Cross-site scripting（跨站脚本攻击，简称XSS）

漏洞描述

恶意攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，以此达到恶意攻击用户的目的。XSS 攻击对WEB 服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生
了较严重的危害

XSS 类型包括：

1. 非持久型跨站： 即反射型跨站脚本漏洞， 是目前最普遍的跨站类型。
   跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，
   这类跨站的代码不存储到服务端（比如数据库中）。
2. 持久型跨站：危害最直接的跨站类型，跨站代码存储于服务端
   （比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的
   Javascript 代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入
   的Javascript 代码。
3. DOM 跨站（DOM XSS ）：是一种发生在客户端DOM （Document
   Object Model 文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻
   辑导致的安全问题。

示例：（窃取网页浏览中的cookie信息）

如查看留言板功能，攻击者留言为一段javascript代码，如：

那么留言板界面的网页代码就会变成形如以下，当有用户不小心点击图片时，便会向目标主机发送cookie信息，击者很可能能够直接利用cookie不用密码直接登录被攻击者的账户。

         



留言：





留言记录：

修复建议

1. 与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script 、iframe 等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
2. 不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
3. 不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
4. 对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
5. 在发布应用程序之前测试所有已知的威胁。

Broken Access Control（越权攻击漏洞）

指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定，一旦权限验证不充分，就易致越权漏洞。

水平越权：指攻击者尝试访问与他拥有相同权限的用户资源。例如，用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。

垂直越权：由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

修复建议

1. 前后端同时对用户输入信息进行校验，双重验证机制
2. 执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限
3. 特别敏感操作可以让用户再次输入密码或其他的验证信息
4. 可以从用户的加密认证 cookie 中获取当前用户 id，防止攻击者对其修改。或在 session、cookie 中加入不可预测、不可猜解的 user 信息
5. 直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理
6. 永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

weak password（弱口令漏洞）

应用存在默认口令或口令较简单易被猜到。通过爆破工具可以很容易破解用户的弱口令。

示例：

如用户登录，通过burp suite爆破登录密码。

修复建议

1. 不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
2. 口令长度不小于8 个字符。
3. 口令不应该为连续的某个字符（例如： AAAAAAAA ）或重复某些字符的组合（例如：tzf.tzf. ）。
4. 口令应该为以下四类字符的组合，大写字母(A-Z) 、小写字母(a-z) 、数字(0-9) 和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
5. 口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail 地址等等与本人有关的信息，以及字典中的单词。
6. 口令不应该为用数字或符号代替某些字母的单词。
7. 口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。
8. 至少90 天内更换一次口令，防止未被发现的入侵者继续使用该口令。

Denial of Service (DDoS 攻击)

通过大规模互联网流量淹没目标服务器或其周边基础设施，以破坏目标服务器、服务或网络正常流量的恶意行为

推荐参考：DDos攻击与防御

修复建议

1. 设置高性能设备，保证网络设备不能成为瓶颈

2. 保证带宽，提高抗受攻击的能力

3. 异常流量清洗

   通过DDoS硬件防火墙对异常流量的清洗过滤，通过数据包的规则过滤、数据流指纹检测过滤、及数据包内容定制过滤等顶尖技术能准确判断外来访问流量是否正常，进一步将异常流量禁止过滤。

4. 分布式集群防御

   目前网络安全界防御大规模DDoS攻击的最有效办法。分布式集群防御的特点是在每个节点服务器配置多个IP地址，并且每个节点能承受不低于10G的DDoS攻击，如一个节点受攻击无法提供服务，系统将会根据优先级设置自动切换另一个节点，并将攻击者的数据包全部返回发送点，使攻击源成为瘫痪状态，从更为深度的安全防护角度去影响企业的安全执行决策。

5. IP轮询技术

   对稳定性、流畅性以及安全性上要求较高的业务，用户遭受 DDoS 攻击且达到一定峰值时，系统通过 IP 轮询机制，将从IP 池中灵活调取一个新的 IP 充当业务 IP，使攻击者失去攻击目标，以此保证业务在 DDoS 的攻击下正常运转。

Slow HTTP Denial of Service Attack (慢速http拒绝服务攻击)

当恶意攻击者以很低的速率发起HTTP请求，使得服务端长期保持连接，这样使得服务端容易造成占用所有可用连接，导致拒绝服务。

修复建议

1. 对web服务器的http头部传输的最大许可时间进行限制，修改成最大许可时间为20秒
2. 限制HTTP头及包长至一个合理数值（tomcat默认值为4096个字节，也就是4K）

XML External Entity Injection（XXE漏洞）

XXE(XML External Entity Injection)，即MXL外部实体注入漏洞，XXE漏洞发生在应用程序解析XML输入时，没有禁止外部实体的加载，导致可加载恶意外部文件，造成文件读取、命令执行、内网端口扫描、攻击内网网站，发起dos攻击

推荐参考：XXE漏洞学习

示例：

这种写法则调用了本地计算机的文件/etc/passwd，XML内容被解析后，文件内容便通过&xxe被存放在了methodname元素中，造成了敏感信息的泄露。

]>

&xxe;

修复建议

1. 配置XML处理器去使用本地静态的DTD，不允许XML中含有任何自己声明的DTD。

2. 过滤用户提交的XML数据。

   过滤关键词：

中危漏洞

Cross-Site Request Forgery（跨站点请求伪造，简称CSRF）

漏洞描述

攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
CSRF 主要用于使用受害者的特权对目标站点执行操作，通过访问响应来公开信息。当目标站点易受 XSS 攻击时，信息泄露的风险会急剧增加，因为 XSS 可以作为 CSRF 的平台，允许攻击在同源策略的范围内进行。

示例：

用户在某网站配置其电子邮件帐户用于接收邮件信息，简单的from表单提交如：

	
电子邮件：
	

攻击者通过查看此 HTML 源代码或使用此表单推断出合法请求的格式类似于以下内容：

POST /account/edit HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
Cookie: PHPSESSID=1234

如果攻击者可以伪造来自其他用户的此类请求，则攻击者可能会开始接收受害者的所有电子邮件。如使用 JavaScript 提交包含隐藏字段的表单：

或者是通过横幅广告、跨站点脚本缺陷或其他方式来实现请求的伪造。

所以被CSRF攻击，一般要同时满足两个条件：

1. 登录受信任网站A，并在本地生成Cookie。
2. 在不登出A的情况下，访问危险网站B。

修复建议

1. 验证 HTTP Referer 字段

   在request header中，有个referer字段，表明请求的来源，服务端可以通过这个字段判断是否是在合法的网站下发送的请求。

2. 在请求地址中添加 token 并验证，

   用户提交请求后， 服务端验证表单中的Token是否与用户Session中的Token一致，一致为合法请求，不是则非法请求。

3. 在 HTTP 头中自定义属性并验证

   这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。

会话标示未更新漏洞

在用户进入登录页面，但还未登录时，会产生一个session，用户输入信息，登录以后，session的id没有改变，也就是说没有建立新session，原来的session没有被销毁, 可以继续使用，黑客可利用此漏洞窃取或操纵客户会话和cookie，用于模仿合法用户，从而能够以该用户身份查看或变更用户记录以及执行事务。

修复建议

1. 用户成功登录认证时，始终生成新的会话
2. 防止用户操纵会话标识
3. 不接受用户浏览器登录时所提供的会话标识

Clickjacking: CSP frame-ancestors missing (点击劫持：缺少 CSP frame-ancestors)

点击劫持（Click Jacking）是一种视觉上的欺骗手段，攻击者通过使用一个透明的iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，通过调整iframe页面的位置，可以使得伪造的页面恰好和iframe里受害页面里一些功能重合（按钮），以达到窃取用户信息或者劫持用户操作的目的。

修复建议

1. 设置X-Frame-Options配置项为deny,使浏览器拒绝当前页面加载任何frame页面。
2. CSP设置frame-ancestors限制，限制嵌入框架的网页。

低危漏洞

JSON Hijacking（JSON劫持）

JSON 劫持又为“ JSON Hijacking ”，最开始提出这个概念大概是在 2008 年国外有安全研究人员提到这个 JSONP 带来的风险。其实这个问题属于 CSRF（ Cross-site request forgery 跨站请求伪造）攻击范畴。当某网站听过 JSONP 的方式来快域（一般为子域）传递用户认证后的敏感信息时，攻击者可以构造恶意的 JSONP 调用页面，诱导被攻击者访问来达到截取用户敏感信息的目的。

示例：

1. 某网站存在一个api接口，http://www.demo.com/api/getVipCardInfo

2. 已登录用户访问该接口，会返回会员卡信息，如{“balance”: “2000”,“userId”:1000,“vipCardId”:999}

3. 用户此时在网页上不小心点了一个恶意植入的广告等，访问了一个恶意站点http://www.attack.com/

4. 这个站点下存在如下的恶意代码

上述代码会首先向将http://www.demo.com/api/getVipCardInfo地址发起请求，获取到的用户敏感信息通过对JS对象默认的setter方法重写，用户敏感信息被发送到一个恶意收集信息的站点。至此，用户敏感信息被泄露，JSON劫持攻击完成。

修复建议

json劫持属于CSRF（ Cross-site request forgery 跨站请求伪造）的攻击范畴，所以解决的方法和解决csrf的方法一样。

参照CSRF攻击修复修复建议：Csrf修复修复建议

JavaScript Hijacking（JavaScript函数劫持）

函数劫持，顾名思义，即在一个函数运行之前把它劫持下来，添加我们想要的功能。当这个函数实际运行的时候，它已经不是原本的函数了，而是带上了被我们添加上去的功能。以此可以非法获取用户的资料。

JavaScript劫持的经典结构

window.onload=function(){    
	var _func=func;    
	window.func=function(){           
	 }
}

var _func=func中func指代的就是一个实际的JavaScript native方法，window.func=function(){}指的就是重写的内容。

示例：

劫持alert()函数，将信息上传到攻击者的服务器

window.alert = function (message) {    
	console.log('alert: ' + message.toString());    
	//把信息上报到攻击者的服务器上    
	sendToAttacker(message);
}

Cookie缺少HttpOnly属性

Cookie中的HttpOnly属性值规定了Cookie是否可以通过客户端脚本进行访问，能起到保护Cookie安全的作用，如果在Cookie中没有将HttpOnly属性设置为true，那么攻击者就可以通过程序（JS脚本、Applet等）窃取用户Cookie信息，增加攻击者的跨站脚本攻击威胁。

修复建议

1. 所有会话Cookie中添加“HttpOnly”属性

HttpServletResponse response = (HttpServletResponse)response;
response.setHeader( "Set-Cookie", "name=value; HttpOnly");

2. 禁止向cookie中存值或取值

Cookie(s) without Secure flag set (Cookie(s)未设置Secure标志)

对于敏感业务，如登录、转账、支付等，需要使用HTTPS来保证传输安全性，如果会话Cookie缺少secure属性，Web应用程序通过SSL向服务器端发送不安全的Cookie，可能会导致发送到服务器的Cookie被非HTTPS页面获取，造成用户Cookie信息的泄露。如果启用了secure属性，浏览器将仅在HTTPS请求中向服务端发送cookie内容。

修复建议

1. 使用https传输数据
2. cookie添加secure属性

Possible internal IP address disclosure (内网IP地址泄漏)

参数值中发现了内部IP，会为渗透攻击打下良好基础，攻击者可能会以此收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名或敏感文件位置。

修复建议

1. 禁止在源代码中注释中包含有内网IP
2. 删除携带内网IP地址的页面，并制定完善的安全编码策略，并且及时检查存在的页面代码是否包含内部IP地址问题
3. 合理配置WEB服务器，禁止在数据交互中，传输内网IP地址