深入理解web安全攻防策略，看完这一篇就够了

前言

互联网时代，数据安全与个人隐私信息等受到极大的威胁和挑战，本文将以几种常见的攻击以及防御方法展开分析。

1. XSS (跨站脚本攻击)

定义：通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击可造成的主要影响:

利用虚假输入表单骗取用户个人信息。
利用脚本窃取用户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求。

原理：恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的

如上图所示，网页URL输入一段包含js脚本的代码，在页面HTML中会获取url传参 keyword，并直接塞入到网页中直接执行，且参数可能会直接传到后台服务器中保存，后面再取到该参数时候又会执行脚本。整个过程中我们可以发现该漏洞产生的原因：1.输入的参数未经过安全过滤；2.恶意脚本被输出到网页；3.用户浏览器执行了恶意脚本。

1.1 反射性XSS攻击

特征：

不经过服务器存储，直接通过 HTTP 的 GET 和 POST 请求就能完成攻击，直接拿到用户隐私数据。
攻击者需要诱骗用户点击，用户点击相关链接才能发起
用来盗取用户敏感保密信息

1.2 存储型XSS攻击

一般在前端 Form 表单提交等交互功能，如文章留言，评论信息等。黑客利用的 XSS 漏洞，将输入内容提交进入数据库持久保存，当前端页面获得后端从数据库中注入脚本代码时，恰好将其渲染执行。如下图我们在掘金评论区输入恶意脚本（掘金社区做了校验处理，该评论是无法提交的）。

攻击成功需要同时满足以下几个条件：

POST 请求提交表单后端没做转义直接入库。
后端从数据库中取出数据没做转义直接输出给前端。
前端拿到后端数据没转义直接渲染成 DOM。

1.3 XSS攻击的防御策略

请求头部 Content-Security-Policy 策略：CSP 本质上就是通过建立白名单告诉浏览器哪些外部资源可以加载和执行。例如：只允许加载本站资源（Content-Security-Policy: default-src ‘self’）、只允许加载 HTTPS 协议图片（Content-Security-Policy: img-src https://* ）、允许加载任何来源框架（Content-Security-Policy: child-src ‘none’）等等，只要配置了正确的规则，那么即使网站存在漏洞，攻击者也不能执行它的攻击代码，并且 CSP 的兼容性也不错。
转义字符：用户的输入永远不可信，最普遍的做法就是转义输入输出的内容，对于引号、尖括号、斜杠等符号进行转义,如下方法：

function escapeHtml(html) {
  html = html.replace(/&/g, '&amp;');
  html = html.replace(/</g, '&lt;');
  html = html.replace(/>/g, '&gt;');
  html = html.replace(/"/g, '&quto;');
  html = html.replace(/'/g, '&#39;');
  html = html.replace(/`/g, '&#96;');
  html = html.replace(/\//g, '&#x2F;');
  return html;
}

但是对于类似富文本，显然不能通过上面的办法来转义所有字符，因为这样会把需要的格式也过滤掉。所以通常采用白名单过滤的办法，如下所示，示例使用了 js-xss 来实现，可以看到在输出中保留了 h1 标签且过滤了 script 标签

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
console.log(html)  // <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;

HttpOnly Cookie：Web应用程序在设置cookie时，将其属性设为HttpOnly，就可以避免该网页的cookie被客户端恶意JavaScript窃取，保护用户cookie信息。

2. CSRF(跨站请求伪造)

定义：利用用户已登录的身份，在用户毫不知情的情况下，以用户的名义完成非法操作。

2.1 CSRF攻击的原理

根据上面的原理图，可以知道完成 CSRF 攻击必须要有三个条件：

用户已经登录了站点 A，并在本地记录了 cookie
在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
站点 A 没有做任何 CSRF 防御策略

2.2 CSRF攻击的防御策略

防范 CSRF 攻击的思路：1. Get 请求不对数据进行修改；2. 不让第三方网站访问到用户 Cookie；3. 阻止第三方网站请求接口；4. 请求时附带验证信息，比如验证码或者 Token。

设置 SameSite 属性：对 Cookie 设置 SameSite 属性，表示 Cookie 不随着跨域请求发送，可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏览器都兼容。Samesite 有两个属性值，分别是 Strict 和 Lax：当Samesite属性值设置为 Strict时被称为严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外；当Samesite属性值设置为 Lax被称为宽松模式，假如这个请求改变了当前页面或者打开了新页面并且同时是个GET请求，则这个Cookie可以作为第三方Cookie。
同源检测：CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：Origin 和 Referer。这种方法并非万无一失，使用Referer 值验证来源的的方法，相当于把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不是很安全。在部分情况下，攻击者可以隐藏，甚至修改自己请求的Referer。
CSRF Token：CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的带有真实cookie信息的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。CSRF Token的防护策略分为以下三个步骤：

用户打开页面，服务器用户生成一个Token（该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合），在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。为了安全起见Token最好还是存在服务器的Session中。
在页面提交的请求中设置一个新的请求头属性，并且携带这个Token。
当用户从客户端拿到Token再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。

启用验证码：应用程序和用户进行交互过程中，特别是账户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在通常情况下，验证码够很好地遏制CSRF攻击。但增加验证码降低了用户的体验，网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段，在关键业务点设置验证码。

3. 点击劫持

定义：点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。

隐蔽性较高，骗取用户操作
“UI-覆盖攻击”
利用iframe或者其它标签的属性

3.1 点击劫持的原理

如下代码展示的是一个静态页面，用iframe引入一个csdn地址通过设置透明度属性之后，肉眼是没法看见的。外层设置一个吸引人的img 图片，诱导用户点击，实际上会触发点击到iframe 内嵌的页面。下面的图中展示了设置不同透明度的情况下可以看见的真实页面内容。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>点击劫持</title>
</head>
<style>
    iframe {
        width: 1440px;
        height: 900px;
        position: absolute;
        top: -0px;
        left: -0px;
        z-index: 2;
        -moz-opacity: 0;
        opacity: 0;
        filter: alpha(opacity=0);
    }
    button {
        position: absolute;
        top: 500px;
        left: 1050px;
        z-index: 1;
        width: 90px;
        height: 40px;
    }
</style>
<body>
    <button>嗨，点我有福利哟 ~ ~</button>
    <img     src="https://gimg2.baidu.com/image_search/src=http%3A%2F%2Fpic1.win4000.com%2Fwallpaper%2F2019-11-19%2F5dd3870a80b9c.jpg&refer=http%3A%2F%2Fpic1.win4000.com&app=2002&size=f9999,10000&q=a80&n=0&g=0n&fmt=auto?sec=1665362005&t=e7270ce2a5b520cde3bd3f0f8835128e">
    <iframe src="https://www.csdn.net/" scrolling="no"></iframe>
</body>
</html>

3.2 点击劫持的防御策略

X-FRAME-OPTIONS：X-FRAME-OPTIONS是一个 HTTP 响应头，就是为了防御用 iframe 嵌套的点击劫持攻击。该响应头有三个值可选，分别是：

DENY，表示页面不允许通过 iframe 的方式展示
SAMEORIGIN，表示页面可以在相同域名下通过 iframe 的方式展示
ALLOW-FROM，表示页面可以在指定来源的 iframe 中展示

4. URL跳转漏洞

定义：借助未验证的URL跳转，将应用程序引导到不安全的第三方区域，从而导致的安全问题。

4.1 URL跳转漏洞的原理

黑客构建恶意链接(链接需要进行伪装,尽可能迷惑),发在QQ群或者是浏览量多的贴吧/论坛中。安全意识低的用户点击后,经过服务器或者浏览器解析后，跳到恶意的网站中。经常的做法是熟悉的链接后面加上一个恶意的网址，这样才迷惑用户。如下图：

4.2 URL跳转漏洞的防御策略

referer的限制：如果确定传递URL参数进入的来源，我们可以通过该方式实现安全限制，保证该URL的有效性，避免恶意用户自己生成跳转链接
加入有效性验证Token: 保证所有生成的链接都是来自于我们可信域的，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验，可以避免用户生成自己的恶意链接从而被利用，但是如果功能本身要求比较开放，可能导致有一定的限制。

5. SQL注入

攻击者利用SQL注入这个漏洞，可以访问或修改数据，或者利用潜在的数据库漏洞进行攻击。

5.1 SQL注入原理

我们通过如下例子来说明，前端表单提交的代码和后端的的sql语句如下所示：

<form action="/login" method="POST">
    <p>Username: <input type="text" name="username" /></p>
    <p>Password: <input type="password" name="password" /></p>
    <p><input type="submit" value="登陆" /></p>
</form>

let querySQL = `
    SELECT *
    FROM user
    WHERE username='${username}'
    AND password='${password}'
`;

但如果有一个恶意攻击者输入的用户名是 admin' --，密码随意输入，就可以直接登入系统了，这就是SQL注入,sql注入的代码如下：

SELECT * FROM user WHERE username='admin' --' AND password='xxxx'

在 SQL语句中,' --是闭合和注释的意思，-- 是注释后面的内容的意思，所以有效查询语句实际上是：

SELECT * FROM user WHERE username='admin'

5.2 SQL注入的危害

获取数据库信息：管理员后台用户名和密码；获取其他数据库敏感信息：用户名、密码、手机号码、身份证、银行卡信息…… ；整个数据库：脱裤
获取服务器权限
植入shell，获取服务器权限，读取服务器敏感文件等

5.3 SQL注入的防御策略

限制数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害
后端代码检查输入的数据，严格限制变量的类型，例如使用正则表达式进行一些匹配处理。
对进入数据库的特殊字符（'，"，\，<，>，&，*，; 等）进行转义处理，或编码转换。基本上所有的后端语言都有对字符串进行转义处理的方法，比如 lodash 的 lodash._escapehtmlchar 库。
所有的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。

6. OS命令注入攻击

定义：通过Web应用，执行非法的操作系统命令达到攻击的目的。只要在能调用Shell脚本的地方就有存在被攻击的风险。倘若调用Shell时存在疏漏，就可以执行插入的非法命令。

危害：命令注入攻击可以向Shell发送命令，让Windows或Linux操作系统的命令行启动程序。也就是说，通过命令注入攻击可执行操作系统上安装着的各种程序。

6.1 OS命令注入的原理

黑客构造命令提交给web应用程序，web应用程序提取黑客构造的命令，拼接到被执行的命令中，因黑客注入的命令打破了原有命令结构，导致web应用执行了额外的命令，最后web应用程序将执行的结果输出到响应页面中。假如需要实现一个需求：用户提交一些内容到服务器，然后在服务器执行一些系统命令去返回一个结果给用户：

// 以 Node.js 为例，假如在接口中需要从 github 下载用户指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* 用户输入的参数 */};
exec(`git clone ${params.repo} /some/path`);

如果 params.repo 传入的是 https://github.com/admin/admin.github.io.git 确实能从指定的 git repo 上下载到想要的代码。但是如果 params.repo 传入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服务是用 root 权限起的，那就造成了服务器文件的丢失，OS命令攻击注入得逞。

6.2 OS命令注入的防御策略

后端对前端提交内容进行规则限制（比如正则表达式）。
在调用系统命令前对所有传入参数进行命令行参数转义过滤。
不要直接拼接命令语句，借助一些工具做拼接、转义预处理，例如 Node.js 的 shell-escape npm包等。

7. DoS（Denial of Service）拒绝服务攻击

定义：DoS又被称为拒绝服务，造成DoS的攻击行为被称为DoS攻击，其目的是使计算机或网络无法提供正常的服务。该攻击通过网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源，使目标系统服务系统停止响应甚至崩溃，而在此攻击中并不包括侵入目标服务器或目标网络设备。

7.1 常见攻击手段

缓冲区溢出攻击：最常见的 DoS 攻击，这个概念是向网络地址发送大量的流量。当程序写入超过缓冲区的边界时，就会产生所谓的“缓冲区溢出”。发生缓冲区溢出时，就会覆盖下一个相邻的内存块（覆盖相邻函数的栈帧），导致程序发生一些不可预料的结果。常见的防御策略如下：

地址空间随机化 —— 随机重新排列进程的关键数据区的地址空间位置。缓冲区溢出攻击通常依赖于了解重要的可执行代码的确切位置，地址空间的随机化可以使这种了解几乎不可能。
防止数据执行 —— 标记内存的某些区域（可执行或不可执行），防止漏洞利用运行不可执行区域中的代码。

ICMP泛洪（死亡ping）：通过发送欺骗性数据包来利用配置错误的网络设备，这些数据包 ping 目标网络上的每台计算机，而不仅仅是一台特定的计算机。然后触发网络以放大流量。这种攻击也被称为死亡ping。由于使用ping工具很容易完成这种攻击，以至于它也成了这种攻击的首选武器，这也是这种攻击名字的由来。因此仅仅阻塞 ping 的使用并不能完全解决这个漏洞。预防死亡之ping的最好方法是对操作系统打补丁，使内核将不再对超过规定长度的包进行重组。如下代码就是简单的死亡ping攻击手段：

// -l 所指为IP结尾断点，65500 表示数据长度上限，-t 表示不停地ping目标地址
ping -l 65500 192.169.1.1 -t

SYN flood：发送连接到服务器的请求，但未完成握手。直到所有打开的端口都被请求饱和。如下图所示，发送请求到服务器但是最后却不完成握手，依次打开所有的请求端口直至饱和状态，造成网络崩溃：
可以采取以下三种措施: 阻止发往该保护主机的后续连接请求、切断保护主机上的最老半连接会话、向 TCP Proxy 添加受保护 IP 地址。
UDP泛洪 (UDP Flood)：短时间内向特定目标不断发送 UDP 报文，致使目标系统负担过重而不能处理合法的传输任务，就发生了 UDP Flood。防御手段：

判断攻击包大小，如果是大包攻击就采用防止UDP碎片方法：可以根据攻击包大小设定包碎片重组大小，一般不小于1500。特殊极端情况下，可以丢弃所有UDP碎片。

泪滴攻击（TearDrop）：TCP/IP协议在数据传输过程中，对过大的数据会进行分包处理，传输到目的主机后再到堆栈中进行重组，为实现重组，一个分片数据包的偏移量和大小之和要同于下一个分片数据包的偏移量和大小之和，如果不同，则数据包重叠。当发送伪造的含有重叠偏移信息的分段包到目标主机时，被攻击主机试图将分段包重组时，由于分段数据的错误，接收这些数据包的机器因为TCP / IP碎片重组错误而无法重新组装，因此数据包相互重叠，导致目标网络设备崩溃。常见的防御策略如下：

收到分割封包时候进行分析，计算offset是否有误
server应用最新或者尽可能使用最新操作系统
设置防火墙时对分段进行重组，而不是转发它们

IP欺骗（IP Spoofing DoS）: 行动产生的IP数据包为伪造的源IP地址，以便冒充其他系统或发件人的身份。这是一种骇客的攻击形式，骇客使用一台计算机上网,而借用另外一台机器的IP地址,从而冒充另外一台机器与服务器打交道。防御方法：

可在设备上开启单播逆向路径转发（URPF）功能
可在设备上开启IP源防护（IPSG）功能

7.3 DDoS（Distributed denial of service attack）分布式拒绝服务攻击

定义：DDoS（Distributed denial of service attack）分布式拒绝服务攻击：黑客利用工具集合许多的网络带宽来同时对同一个目标发动大量的 DoS（Denial of Service）攻击，并可以借此躲避追踪的手段。

原理：一个完整的DDoS攻击体系由攻击者、主控端、代理端和攻击目标四部分组成。主控端和代理端分别用于控制和实际发起攻击，其中主控端只发布命令而不参与实际的攻击，代理端发出DDoS的实际攻击包。这样攻击者可以逃避追踪，每一个攻击代理主机都会向目标主机发送大量的服务请求数据包，这些数据包经过伪装无法识别它的来源，而且这些数据包所请求的服务往往要消耗大量的系统资源，造成目标主机无法为用户提供正常服务。甚至导致系统崩溃。