一篇补齐你的Web安全知识死角

WEB安全漏洞

概述

Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的广泛使用，Web应用已经融入到日常生活中的各个方面：网上购物、网络银行应用、证券股票交易、政府行政审批等等。在这些Web访问中，大多数应用不是静态的网页浏览，而是涉及到服务器侧的动态处理。此时，如果 Java 、 PHP 、ASP等程序语言的编程人员的安全意识不足，对程序参数输入等检查不严格等，会导致Web应用安全问题层出不穷。

漏洞分类

01.SQL注入

SQL 注入漏洞(SQL Injection)是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。

而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。很多 Web 开发者没有意识到 SQL 查询是可以被篡改的，从而把 SQL 查询当作可信任的命令。殊不知，SQL 查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过 SQL 查询去运行主机系统级的命令。

SQL 防护

1. 不要信任用户的输入: 对用户的输入进行校验，可以通过正则表达式，或限制长度;对进入数据库的特殊字符('，"，\，<，>，&，*，; 等)进行转义处理，或编码转换。
2. 不要使用动态拼装 SQL，可以使用参数化的 SQL 或者直接使用存储过程进行数据查询存取。
3. 不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4. 不要把机密信息直接存放，加密或者 hash 掉密码和敏感的信息。
5. 严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害
6. 在应用发布之前建议使用专业的 SQL 注入检测 工具 进行检测，以及时修补被发现的 SQL 注入漏洞。网上有很多这方面的开源工具，例如 sqlmap、SQLninja 等。
7. 不要过于细化返回的错误信息，如果目的是方便调试，就去使用后端日志，不要在接口上过多的暴露出错信息，毕竟真正的用户不关心太多的技术细节，只要话术合理就行。
8. 当采用MyBatis执行sql语句时，存在模糊查询的方法。存在表达式${} 和 #{}

02.XSS 攻击

XSS 又称为 CSS，全程为 Cross-site script，跨站脚本攻击，为了和 CSS 层叠样式表区分所以取名为 XSS，是 Web 程序中常见的漏洞。

其原理是攻击者向有 XSS 漏洞的网站中输入恶意的 HTML 代码，当其它用户浏览该网站时候，该段 HTML 代码会自动执行，从而达到攻击的目的，如盗取用户的 Cookie，破坏页面结构，重定向到其它网站等。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。

根据攻击的方式，XSS攻击可以分为三类：反射型XSS、存储型XSS、DOM Based XSS。

反射型XSS也被称为非持久性XSS,这种攻击方式把XSS的Payload写在URL中，通过浏览器直接“反射”给用户。这种攻击方式通常需要诱使用户点击某个恶意链接，才能攻击成功。

存储型XSS又被称为持久性XSS,会把黑客输入的恶意脚本存储在服务器的数据库中。当其他用户浏览页面包含这个恶意脚本的页面，用户将会受到黑客的攻击。一个常见的场景就是黑客写下一篇包含恶意JavaScript脚本的博客文章，当其他用户浏览这篇文章时，恶意的JavaScript代码将会执行。

DOM Based XSS 是一种利用前端代码漏洞进行攻击的攻击方式。前面的反射型XSS与存储型XSS虽然恶意脚本的存放位置不同，但其本质都是利用后端代码的漏洞。

反射型和存储型xss是服务器端代码漏洞造成的，payload在响应页面中，DOM Based中，payload不在服务器发出的HTTP响应页面中，当客户端脚本运行时(渲染页面时)，payload才会加载到脚本中执行。

XSS防御

• 输入检查

常见的Web漏洞，如XSS、SQL注入等，都要求攻击者构造一些特殊的字符串，而这些字符串是一般用户不会用到的，所以进行输入检查就很有必要了。

输入检查可以在用户输入的格式检查中进行。很多网站的用户名都要求是字母及数字的组合如“1234qwer”，其实也能过滤一部分的XSS和SQL注入。但是，这种在客户端的限制很容易被绕过，攻击者可以用JavaScript或一些请求工具，直接构造请求，想网站注入XSS或者SQL。所以，除了在客户端进行格式检查，往往还需要在后端进行二次检查。客户端的检查主要作用是阻挡大部分误操作的正常用户，从而节约服务器资源。

• 对输出转义

在输出数据之前对潜在的威胁的字符进行编码、转义是防御XSS攻击十分有效的措施。

为了对抗XSS,在HtmlEncode中至少转换以下字符：

< 转成 <

> 转成 >

& 转成 &

“ 转成 "

‘ 转成 '

XSS防护—Spring MVC

a)项目级过滤

<context-param> 
<param-name>defaultHtmlEscape</param-name> 
<param-value>true</param-value> 
</context-param> 

b)页面级过滤

<spring:htmlEscape defaultHtmlEscape=”true” /> 

c)表单元素级过滤

在form元素中添加

<form:form htmlEscape=“true”>或 
<form:input path=”someFormField” htmlEscape=”true” /> 

03.CSRF

CSRF(Cross-Site Request Forgery)，中文名称：跨站请求伪造攻击那么 CSRF 到底能够干嘛呢?你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。

所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。

CSRF流程

角色

• 正常浏览网页的用户：User
• 正规的但是具有漏洞的网站：WebA
• 利用CSRF进行攻击的网站：WebB

流程

1.用户登录、浏览并信任正规网站WebA，同时，WebA通过用户的验证并在用户的浏览器中产生Cookie。

2.攻击者WebB通过在WebA中添加图片链接等方式诱导用户User访问网站WebB。

3.在用户User被诱导访问WebB后，WebB会利用用户User的浏览器访问第三方网站WebA，并发出操作请求。

4.用户User的浏览器根据WebB的要求，带着步骤一中产生的Cookie访问WebA。

5.网站WebA接收到用户浏览器的请求，WebA无法分辨请求由何处发出，由于浏览器访问时带上用户的Cookie，因此WebA会响应浏览器的请求，如此一来，攻击网站WebB就达到了模拟用户操作的目的。

CSRF攻击防护

CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。服务端的预防 CSRF 攻击的方式方法有多种，但思路上都是差不多的，主要从以下两个方面入手：

• 正确使用 GET，POST 请求和 cookie
• 在非 GET 请求中增加 token

一般而言，普通的 Web 应用都是以 GET、POST 请求为主，还有一种请求是 cookie 方式。我们一般都是按照如下规则设计应用的请求：

• GET 请求常用在查看，列举，展示等不需要改变资源属性的时候(数据库 query 查询的时候)
• POST 请求常用在 From 表单提交，改变一个资源的属性或者做其他一些事情的时候(数据库有 insert、update、delete 的时候)

当正确的使用了 GET 和 POST 请求之后，剩下的就是在非 GET 方式的请求中增加随机数，这个大概有三种方式来进行：

• 为每个用户生成一个唯一的 cookie token，所有表单都包含同一个伪随机值，这种方案最简单，因为攻击者不能获得第三方的 cookie(理论上)，所以表单中的数据也就构造失败，但是由于用户的 cookie 很容易由于网站的 XSS 漏洞而被盗取，所以这个方案必须要在没有 XSS 的情况下才安全。
• 每个 POST 请求使用验证码，这个方案算是比较完美的，但是需要用户多次输入验证码，用户体验比较差，所以不适合在业务中大量运用。
• 渲染表单的时候，为每一个表单包含一个 csrfToken，提交表单的时候，带上 csrfToken，然后在后端做 csrfToken 验证。

CSRF 的防御可以根据应用场景的不同自行选择。CSRF 的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量，但是这种工作量是值得的，毕竟用户隐私以及财产安全是产品最基础的根本。

04.DDos

DDos又叫分布式拒绝服务，全称Distributed Denial of Service，利用DDos造成的攻击称为拒绝服务攻击，其原理就是利用大量的请求造成资源过载，导致服务不可用。

DDos攻击从层次上可分为网络层攻击与应用层攻击，从攻击手法上可分为快型流量攻击与慢型流量攻击，但其原理都是造成资源过载，导致服务不可用。

网络层DDos攻击

网络层DDos攻击包括SYN flood、UDP flood、ICMP flood等。

• SYN flood攻击：SYN flood攻击主要利用了TCP三次握手过程中的bug，我们知道TCP三次握手过程是要建立连接的双方发送SYN，SYN+ACK，ACK数据包，而当攻击方随意构造源ip去发送SYN包时，服务器返回的SYN+ACK就不能得到应答(因为ip是随意构造的)，此时服务器就会尝试重新发送，并且会有至少30s的等待时间，导致资源饱和服务不可用，此攻击属于慢型dos攻击。
• UDP flood攻击：由于udp是一种无连接的协议，因此攻击者可以伪造大量的源IP地址去发送udp包，此种攻击属于大流量攻击。正常应用情况下，UDP包双向流量会基本相等，因此在消耗对方资源的时候也在消耗自己的资源。
• ICMP flood攻击：此攻击属于大流量攻击，其原理就是不断发送不正常的ICMP包(所谓不正常就是ICMP包内容很大)，导致目标带宽被占用，但其本身资源也会被消耗。并且目前很多服务器都是禁ping的(在防火墙在可以屏蔽icmp包)，因此这种方式已经落伍。

网络层DDos防御

• 网络架构上做好优化，采用负载均衡分流。
• 添加抗DDos设备，流量清洗。
• 限制单ip请求频率。
• 防火墙等防护设置禁止icmp包等
• 认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更,那这台机器就可能遭到了攻击。
• 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。
• 加钱堆机器

网络层的DDos攻击究其本质其实是无法防御的，我们能做得就是不断优化自身的网络架构，以及提升网络带宽。

应用层 DDoS

应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。应用层攻击千变万化，目的就是在网络应用层耗尽你的带宽，下面列出集中典型的攻击类型。

• CC 攻击：CC 攻击的原理，就是针对消耗资源比较大的页面不断发起不正常的请求，导致资源耗尽。因此在发送 CC 攻击前，我们需要寻找加载比较慢，消耗资源比较多的网页，比如需要查询数据库的页面、读写硬盘文件的等。通过 CC 攻击，使用爬虫对某些加载需要消耗大量资源的页面发起 HTTP 请求。
• DNS Flood 攻击：采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层 DNS 服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成 DNS 服务器解析域名超时。
• HTTP 慢速连接攻击：针对 HTTP 协议，先建立起 HTTP 连接，设置一个较大的 Conetnt-Length，每次只发送很少的字节，让服务器一直以为 HTTP 头部没有传输完成，这样连接一多就很快会出现连接耗尽。

应用层DDos防御

• 判断User-Agent字段(不可靠，因为可以随意构造)
• 网页中镶嵌js代码(不可靠，因为爬虫也可携带浏览器引擎，或者执行js代码)
• 针对ip+cookie，限制访问频率(由于cookie可以更改，ip可以使用代理，或者肉鸡，也不可靠)
• 关闭apache最大连接数等，合理配置中间件，缓解ddos攻击。
• 页面中添加验证码，比如搜索数据库时。
• 编写代码时，尽量实现优化，并合理使用缓存技术，减少数据库的读取操作。

应用层的防御有时比网络层的更难，因为导致应用层被dos攻击的因素非常多，有时往往是因为 程序员 的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。而应用层DDos防御的核心就是区分人与机器(爬虫)，因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。

05.目录遍历漏洞

目录遍历漏洞成因：服务器端，接收请求中传来的文件名称，在服务器端拼凑成文件的绝对路径，并且用输出流下载。

防御措施

• 文件ID使用随机数命名
• 文件路径保存至数据库，用户提交文件对应ID下载文件。
• 下载文件之前做权限判断。
• 记录文件下载日志。

06.业务安全

在Web系统中，除了常规的如SQL，XSS，CSRF、Ddos等web漏洞外，更重要的是其业务上的安全。

账户信息安全

账户是一个系统的入口，关系到用户最直接的利益，因而账户的安全在业务安全中占及其重要的地位。账户体系分多个层次，每个环节的漏洞，都将给用户带来极大的损失。

业务数据安全

金额数据篡改：抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。

商品数量篡改：抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，如负数并提交，查看能否以修改后的数量完成业务流程。

业务流程安全

顺序执行缺陷

部分网站逻辑可能是先A过程后B过程然后C过程最后D过程。

用户控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。于是，用户就从B直接进入了D过程，就绕过了C。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站程序了。

最后提交新密码时修改用户ID为其他ID

跳过验证步骤、找回方式，直接到设置新密码页面

业务接口安全

在短信、邮件调用业务或生成业务数据环节中(类：短信验证码，邮件验证码，订单生成，评论提交等)，对其业务环节进行调用(重放)测试。如果业务经过调用(重放)后被多次生成有效的业务或数据结果

07.编程规范

一切输入都是有害的!!!输出也不安全!

输入：传参，cookie、session、http header、数据库……

输出：异常信息、敏感信息、xss

08.总结

程序猿们能够管理好代码隐私，注意代码安全问题，比如不要将产品的含有敏感信息的代码放到第三方外部站点或者暴露给外部用户，尤其是前端代码，私钥类似的保密性的东西不要直接输出在代码里或者页面中。也许还有很多值得注意的点，但是归根结底还是绷住安全那根弦，对待每一行代码都要多多推敲。

开发时要提防用户产生的内容，要对用户输入的信息进行层层检测

要注意对用户的输出内容进行过滤(进行转义等)

重要的内容记得要加密传输(无论是利用https也好，自己加密也好)

get请求与post请求，要严格遵守规范，不要混用，不要将一些危险的提交使用jsonp完成。

对于URL上携带的信息，要谨慎使用。

心中时刻记着，自己的网站哪里可能有危险。

作者介绍

李伟山

江湖人称：山哥，85年生产，IT届的小学生。享米高级技术总监，曾经在华为、阿里巴巴任职。

座右铭：Fake it until you make it。