WEB应用安全概述

一. 浏览器安全策略

同源策略

浏览器的安全都是以同源为基础，它是浏览器最核心也最基本的安全功能

同源策略规定：不同域的客户端脚本在没有明确授权的情况下，不能读写对象的资源。（不能请求不同域的数据，不能通过脚本操作不同域下的DOM）

不同域

协议不同

域名不同

端口不同

恶意网址拦截

恶意网址拦截的工作原理很简单，一般都是浏览器周期性地从服务器端获取一份最新的恶意网址黑名单，如果用户上网时访问的网址存在于此黑名单中，浏览器就会弹出一个警告页面。

等等……

CSP

Same-Site Cookies

……

二. XSS

跨站脚本攻击（Cross Site Scripting），恶意攻击者往Web页面里插入恶意Script代码，当用户浏览时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。

Reflected XSS（基于反射的XSS攻击）

用户输入的存在XSS攻击的数据，发送给后台，后台并未对数据进行存储，也未经过任何过滤，直接返回给客户端，被浏览器渲染。就可能导致XSS攻击；

反射型 XSS 的攻击步骤：

攻击者构造出特殊的 URL，其中包含恶意代码。

用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。

用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。

POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

Stored XSS（基于存储的XSS攻击）

数据库中存有的存在XSS攻击的数据，返回给客户端。若数据未经过任何转义。被浏览器渲染。就可能导致XSS攻击；

存储型 XSS 的攻击步骤：

攻击者将恶意代码提交到目标网站的数据库中。

用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。

用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。

反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。

POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

DOM-based or local XSS（基于DOM或本地的XSS攻击）

纯粹发生在客户端的XSS攻击

DOM 型 XSS 的攻击步骤：

攻击者构造出特殊的 URL，其中包含恶意代码。

用户打开带有恶意代码的 URL。

用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。

恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

攻击方式总结

在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。

在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。

在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。

在标签的 href、src 等属性中，包含 javascript: 等可执行代码。

在 onload、onerror、onclick 等事件中，注入不受控制代码。

在 style 属性和标签中，包含类似 background-image:url("javascript:..."); 的代码（新版本浏览器已经可以防范）。

在 style 属性和标签中，包含类似 expression(...) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

防范策略

抵御存储型，反射型XSS攻击

输入过滤
HTML转义
纯前端渲染，数据代码分离

输入过滤

只适用于明确输入类型，如邮箱，电话等

不可靠：

用户提交时过滤输入：构造请求绕过前端

服务端过滤输入：客户端和前端编码不同，不兼容；转义后的字符串不能用于Vue等模板的展示；

HTML转义

常用的模板引擎对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用，但并不完善。想要完善XSS防护，还需要更加细致的转义规则。

纯前端渲染

在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。

但纯前端渲染还需注意避免 DOM 型 XSS 漏洞。

抵御DOM型XSS攻击

DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。

使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.creteElement() 等可执行字符串的方法时要小心。

Vue/React 技术栈中在render避免 innerHTML、outerHTML 的XSS隐患。

DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，标签的 `href` 属性，JavaScript 的 `eval()`、`setTimeout()`、`setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

内容安全政策CSP（Content Security Policy）

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

禁止加载外域代码，防止复杂的攻击逻辑。

禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。

禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。

禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。

合理使用上报可以及时发现 XSS，利于尽快修复问题。

其它

防范存储型和反射型 XSS 是后端 RD 的责任。而 DOM 型 XSS 攻击不发生在后端，是前端 RD 的责任。防范 XSS 是需要后端 RD 和前端 RD 共同参与的系统工程。
转义应该在输出 HTML 时进行，而不是在提交用户输入时。
不同的上下文，如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等，所需要的转义规则不一致。

三. CSRF

跨站请求伪造攻击（Cross-Site Request Forgery），攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF的流程

受害者登录a.com，并保留了登录凭证（Cookie）。

攻击者引诱受害者访问了b.com。

b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。

a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。

a.com以受害者的名义执行了act=xx。

攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

CSRF的特点

攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。

攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。

整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。

跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪

防护策略

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

同源检测

CSRF（通常）发生在第三方域名，我们就直接禁止外域（或者不受信任的域名）对我们发起请求。

在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：

Origin Header
Referer Header

这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的来源域。

问题：

但是Origin在以下两种情况下并不存在

IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识
在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。

而对于Referer，虽然Referer的值是由浏览器提供的，HTTP协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，部分浏览器尚不支持Origin标头；另外，出于保护隐私，任何浏览器请求都可以决定省略Referer标头。

如果Origin和Referer都不存在，建议直接进行阻止，特别是如果您没有使用随机Token作为第二次检查。

当一个请求是页面请求（比如网站的主页），而来源是搜索引擎的链接（例如百度的搜索结果），也会被当成疑似CSRF攻击。所以在判断的时候需要过滤掉页面请求情况。

Token

CSRF攻击者不能获取到Cookie等信息，只能直接使用。而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求，我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。

四. DDoS

分布式拒绝服务（ Distributed Denial of Service ）原理就是利用大量的请求造成资源过载，导致服务不可用。

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

网络层 DDoS

网络层 DDoS 攻击包括 SYN Flood、ACK Flood、UDP Flood、ICMP Flood 等。

SYN Flood 攻击

SYN flood 攻击主要利用了 TCP 三次握手过程中的 Bug，我们都知道 TCP 三次握手过程是要建立连接的双方发送 SYN，SYN + ACK，ACK 数据包，而当攻击方随意构造源 IP 去发送 SYN 包时，服务器返回的 SYN + ACK 就不能得到应答（因为 IP 是随意构造的），此时服务器就会尝试重新发送，并且会有至少 30s 的等待时间，导致资源饱和服务不可用，此攻击属于慢型 DDoS 攻击。

ACK Flood 攻击

ACK Flood 攻击是在 TCP 连接建立之后，所有的数据传输 TCP 报文都是带有 ACK 标志位的，主机在接收到一个带有 ACK 标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应 RST 包告诉对方此端口不存在。

UDP Flood 攻击

UDP flood 攻击是由于 UDP 是一种无连接的协议，因此攻击者可以伪造大量的源 IP 地址去发送 UDP 包，此种攻击属于大流量攻击。正常应用情况下，UDP 包双向流量会基本相等，因此发起这种攻击的攻击者在消耗对方资源的时候也在消耗自己的资源。

ICMP Flood 攻击

ICMP Flood 攻击属于大流量攻击，其原理就是不断发送不正常的 ICMP 包（所谓不正常就是 ICMP 包内容很大），导致目标带宽被占用，但其本身资源也会被消耗。目前很多服务器都是禁 ping 的（在防火墙在可以屏蔽 ICMP 包），因此这种攻击方式已经落伍。

防御策略

网络层的 DDoS 攻击究其本质其实是无法防御的，我们能做得就是不断优化服务本身部署的网络架构，以及提升网络带宽。当然，还是做好以下几件事也是有助于缓解网络层 DDoS 攻击的冲击：

网络架构上做好优化，采用负载均衡分流。

确保服务器的系统文件是最新的版本，并及时更新系统补丁。

添加抗 DDos 设备，进行流量清洗。

限制同时打开的 SYN 半连接数目，缩短 SYN 半连接的 Timeout 时间。

限制单 IP 请求频率。

防火墙等防护设置禁止 ICMP 包等。

严格限制对外开放的服务器的向外访问。

运行端口映射程序或端口扫描程序，要认真检查特权端口和非特权端口。

关闭不必要的服务。

认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更,那这台机器就可能遭到了攻击。

限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。

加钱堆机器

报警

应用层 DDoS

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

CC 攻击

当时绿盟为了防御 DDoS 攻击研发了一款叫做 Collapasar 的产品，能够有效的防御 SYN Flood 攻击。黑客为了挑衅，研发了一款 Challenge Collapasar 攻击工具（简称 CC）。

CC 攻击的原理，就是针对消耗资源比较大的页面不断发起不正常的请求，导致资源耗尽。因此在发送 CC 攻击前，我们需要寻找加载比较慢，消耗资源比较多的网页，比如需要查询数据库的页面、读写硬盘文件的等。通过 CC 攻击，使用爬虫对某些加载需要消耗大量资源的页面发起 HTTP 请求。

DNS Flood

DNS Flood 攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层 DNS 服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成 DNS 服务器解析域名超时。

HTTP 慢速连接攻击

针对 HTTP 协议，先建立起 HTTP 连接，设置一个较大的 Conetnt-Length，每次只发送很少的字节，让服务器一直以为 HTTP 头部没有传输完成，这样连接一多就很快会出现连接耗尽。

防御策略

判断 User-Agent 字段（不可靠，因为可以随意构造）

针对 IP + cookie，限制访问频率（由于 cookie 可以更改，IP 可以使用代理，或者肉鸡，也不可靠)

关闭服务器最大连接数等，合理配置中间件，缓解 DDoS 攻击。

请求中添加验证码，比如请求中有数据库操作的时候。

编写代码时，尽量实现优化，并合理使用缓存技术，减少数据库的读取操作。

加钱堆机器

报警

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

其他 DDoS 攻击

发起 DDoS 也是需要大量的带宽资源的，但是互联网就像森林，林子大了什么鸟都有，DDoS 攻击者也能找到其他的方式发起廉价并且极具杀伤力的 DDoS 攻击。

利用 XSS

举个例子，如果 12306 页面有一个 XSS 持久型漏洞被恶意攻击者发现，只需在春节抢票期间在这个漏洞中执行脚本使得往某一个小站点随便发点什么请求，然后随着用户访问的增多，感染用户增多，被攻击的站点自然就会迅速瘫痪了。这种 DDoS 简直就是无本万利，不用惊讶，现在大站有 XSS 漏洞的不要太多。

来自 P2P 网络攻击

大家都知道，互联网上的 P2P 用户和流量都是一个极为庞大的数字。如果他们都去一个指定的地方下载数据，成千上万的真实 IP 地址连接过来，没有哪个设备能够支撑住。拿 BT 下载来说，伪造一些热门视频的种子，发布到搜索引擎，就足以骗到许多用户和流量了，但是这只是基础攻击。
高级的 P2P 攻击，是直接欺骗资源管理服务器。如迅雷客户端会把自己发现的资源上传到资源管理服务器，然后推送给其它需要下载相同资源的用户，这样，一个链接就发布出去。通过协议逆向，攻击者伪造出大批量的热门资源信息通过资源管理中心分发出去，瞬间就可以传遍整个 P2P 网络。更为恐怖的是，这种攻击是无法停止的，即使是攻击者自身也无法停止，攻击一直持续到 P2P 官方发现问题更新服务器且下载用户重启下载软件为止。

其它

最后总结下，DDoS 不可能防的住。

五. MITM（ Man-in-the-MiddleAttack ）

中间人攻击是攻击方同时与服务端和客户端建立起了连接，并让对方认为连接是安全的，但是实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息，还能修改通信信息。

当然防御中间人攻击其实并不难，只需要增加一个安全通道来传输信息。HTTPS 就可以用来防御中间人攻击，但是并不是说使用了 HTTPS 就可以高枕无忧了，因为如果你没有完全关闭 HTTP 访问的话，攻击方可以通过某些方式将 HTTPS 降级为 HTTP 从而实现中间人攻击。

那么对于还没有升级的情况，我们可以努力让影响降到最低。

六. Replay Attacks

所谓重放攻击就是攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程。比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道，因为JWT机制是无状态的。

防犯策略

采用时间戳

这种方式的做法就是，首先我们认为一次HTTP请求从发出到到达服务器的时间是不会超过dt的，当你发送一个请求时必须携带一个时间戳t1，当请求到达服务器之后，服务器会取出当前时间,假设为t2，当t2 - t1> dt，那么服务器就认为请求不合法。

因为黑客抓包到伪造请求再到发送需要时间。

注意，这个时间戳是需要加入MD5或其他加密签名的，不然黑客修改了时间戳那就是白费功夫了。

基于record方案

什么是基于record的验证方式呢？就是说我现在不需要随机数，我利用MD5加密的唯一性，采用多维度（多个字段），将每次请求的记录保存到数据库中，每次请求先校验签名记录是否存在，如果存在，则认为请求非法，不存在，则将MD5签名结合其他参数一起保存到数据库中。当然这里也可以结合时间戳只保存60s内的数据。

这一点主要是不考虑采用随机数机制，同时对自己业务可以有不同的扩展，或者说加入业务参数方便运维监控等。

七. sql注入

SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，而是针对程序员编程时的疏忽，通过SQL语句，实现无帐号登录，甚至篡改数据库。

方式

寻找到SQL注入的位置

判断服务器类型和后台数据库类型

针对不通的服务器和数据库特点进行SQL注入攻击

举例

"select * from user_table where username=

' "+userName+" ' and password=' "+password+" '";

// 字符串拼接，当用户输入为 'or 1 = 1 -- 时，username=”or 1=1，--后的内容被注释