6.1-网站安全

Create by fall on -- -- 2021 Recently revised in 31 Oct 2023

https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

https://html5sec.org/

CSRF

CSRF（Cross Site Request Forgery）跨站请求伪造

攻击方式

是一种挟持用户在当前已登录的 Web 应用程序上执行非用户本意的操作的攻击方法。

用户登录网站 1，并且进行认证，保留登录凭证（Cookie）
攻击者引诱导用户访问网站 2
网站 2 通过欺骗用户的浏览器去访问网站 1，携带网站 1 的 Cookie
网站 2，就如同用户一样，肆意在网站 1 进行操作

攻击类型

GET型：如在页面的某个 img 中发起一个 get 请求
POST型：通过自动提交表单到恶意网站
链接型：需要诱导用户点击链接

防御措施

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

一般有以下防御措施：

涉及到数据修改操作严格使用 post 请求而不是 get 请求
HTTP 协议中使用 Referer 属性来确定请求来源进行过滤（禁止外域）
不让第三方网站访问到用户 Cookie
阻止第三方网站请求接口
请求地址添加 token ，将 Token 保存在 Session 中，使黑客无法伪造用户请求
涉及到重要内容时，附带验证信息，添加验证码、密码等
双重 cookie 验证

SameSite

过滤请求来源

利用 SameSite（三种模式：Strict、Lax、None）让浏览器禁止第三方站点发起请求携带关键 Cookie；验证请求的来源站点，请求头中的 Referer 和 Origin 属性；利用 CSRF Token；

可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送，可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏览器都兼容。

Referer Check

HTTP Referer 是 header 的一部分，当浏览器向 web 服务器发送请求时，一般会带上 Referer 信息告诉服务器是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御 CSRF 攻击。正常请求的 referer 具有一定规律，如在提交表单的 referer 必定是在该页面发起的请求。所以通过检查 http 包头 referer 的值是不是这个页面，来判断是不是 CSRF 攻击。

但在某些情况下如从 https 跳转到 http，浏览器处于安全考虑，不会发送 referer，服务器就无法进行 check 了。若与该网站同域的其他网站有XSS 漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。出于以上原因，无法完全依赖 Referer Check 作为防御 CSRF 的主要手段。但是可以通过 Referer Check 来监控 CSRF 攻击的发生。

Anti CSRF Token

目前比较完善的解决方案是加入 Anti-CSRF-Token。即发送请求时在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器建立一个拦截器来验证这个 token。服务器读取浏览器当前域 cookie 中这个 token 值，会进行校验该请求当中的 token 和 cookie 当中的 token 值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。

这种方法相比 Referer 检查要安全很多，token 可以在用户登陆后产生并放于 session 或 cookie 中，然后在每次请求时服务器把 token 从 session 或 cookie 中拿出，与本次请求中的 token 进行比对。由于token的存在，攻击者无法再构造出一个完整的URL实施 CSRF 攻击。但在处理多个页面共存问题时，当某个页面消耗掉 token 后，其他页面的表单保存的还是被消耗掉的那个 token，其他页面的表单提交时会出现 token错误。

验证码

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

检查 Referer 字段

HTTP 头中有一个 Referer 字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer 字段应和请求的地址位于同一域名下。

以示例中商城操作为例，Referer 字段地址通常应该是商城所在的网页地址，应该也位于 www.semlinker.com 之下。而如果是 CSRF 攻击传来的请求，Referer 字段会是包含恶意网址的地址，不会位于 www.semlinker.com 之下，这时候服务器就能识别出恶意的访问。

这种办法简单易行，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的 Referer 字段。虽然 HTTP 协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其 Referer 字段的可能。

同步表单 CSRF 校验

CSRF 攻击之所以能够成功，是因为服务器无法区分正常请求和攻击请求。针对这个问题我们可以要求所有的用户请求都携带一个 CSRF 攻击者无法获取到的 token。对于 CSRF 示例图中的表单攻击，我们可以使用 同步表单 CSRF 校验 的防御措施。

同步表单 CSRF 校验 就是在返回页面时将 token 携带到页面中，在 form 表单提交的时候通过隐藏域或者作为查询参数把 CSRF token 提交到服务器。比如，在同步渲染页面时，在表单请求中增加一个 _csrf 的查询参数，这样当用户在提交这个表单的时候就会将 CSRF token 提交上来：

<form method="POST" action="/upload?_csrf={{由服务端生成}}" enctype="multipart/form-data">
  用户名: <input name="name" />
  选择头像: <input name="file" type="file" />
  <button type="submit">提交</button>
</form>

流程：
- 步骤1：在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）
- 步骤2：在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）
- 步骤3：后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
优点：
- 无需使用 Session，适用面更广，易于实施。
- Token 储存于客户端中，不会给服务器带来压力。
- 相对于 Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。
缺点：
- Cookie 中增加了额外的字段。
- 如果有其他漏洞（例如 XSS ），攻击者可以注入Cookie，那么该防御方式失效。
- 难以做到子域名的隔离。
- 为了确保 Cookie 传输安全，采用这种防御方式的最好确保用整站 HTTPS 的方式，如果还没切 HTTPS 的使用这种方式也会有风险。
Samesite Cookie 属性：Google 起草了一份草案来改进 HTTP 协议，那就是为 Set-Cookie 响应头新增 Samesite 属性，它用来标明这个 Cookie 是个“同站 Cookie”，同站Cookie只能作为第一方 Cookie，不能作为第三方 Cookie，Samesite 有两个属性值，Strict 为任何情况下都不可以作为第三方 Cookie ，Lax 为可以作为第三方 Cookie , 但必须是Get请求

双重 Cookie 防御 就是将 token 设置在 Cookie 中，在提交（POST、PUT、PATCH、DELETE）等请求时提交 Cookie，并通过请求头或请求体带上 Cookie 中已设置的 token，服务端接收到请求后，再进行对比校验。

axios 提供了 xsrfCookieName 和 xsrfHeaderName 两个属性来分别设置 CSRF 的 Cookie 名称和 HTTP 请求头的名称，它们的默认值如下所示：

// lib/defaults.js
var defaults = {
  adapter: getDefaultAdapter(),
  // 省略部分代码
  xsrfCookieName: 'XSRF-TOKEN',
  xsrfHeaderName: 'X-XSRF-TOKEN',
};

前面我们已经知道在不同的平台中，Axios 使用不同的适配器来发送 HTTP 请求，这里我们以浏览器平台为例，来看一下 Axios 如何防御 CSRF 攻击：

// lib/adapters/xhr.js
module.exports = function xhrAdapter(config) {
  return new Promise(function dispatchXhrRequest(resolve, reject) {
    var requestHeaders = config.headers;
    var request = new XMLHttpRequest();
    // 省略部分代码
    // 添加xsrf头部
    if (utils.isStandardBrowserEnv()) {
      var xsrfValue = (config.withCredentials || isURLSameOrigin(fullPath)) && config.xsrfCookieName ?
          cookies.read(config.xsrfCookieName) : undefined;
      if (xsrfValue) {
        requestHeaders[config.xsrfHeaderName] = xsrfValue;
      }
    }
    request.send(requestData);
  });
};

Axios 内部是使用 双重 Cookie 防御 的方案来防御 CSRF 攻击。

iframe 安全

如何让自己的网站不被其他网站的 iframe 引用？

// 检测当前网站是否被第三方iframe引用
// 若相等证明没有被第三方引用，若不等证明被第三方引用。当发现被引用时强制跳转百度。
if(top.location != self.location){
    top.location.href = 'http://www.baidu.com'
}

如何禁用，被使用的 iframe 对当前网站某些操作？

sandbox 是 html5 的新属性，主要是提高 iframe 安全系数。iframe 因安全问题而臭名昭著，这主要是因为 iframe 常被用于嵌入到第三方中，然后执行某些恶意操作。现在有一场景：我的网站需要 iframe 引用某网站，但是不想被该网站操作DOM、不想加载某些 js（广告、弹框等）、当前窗口被强行跳转链接等，我们可以设置 sandbox 属性。如使用多项用空格分隔。

allow-same-origin：允许被视为同源，即可操作父级DOM或cookie等
allow-top-navigation：允许当前iframe的引用网页通过url跳转链接或加载
allow-forms：允许表单提交
allow-scripts：允许执行脚本文件
allow-popups：允许浏览器打开新窗口进行跳转
“”：设置为空时上面所有允许全部禁止

iframe 安全

嵌入第三方 iframe 会有很多不可控的问题，同时当第三方 iframe 出现问题或是被劫持之后，也会诱发安全性问题
点击劫持
- 攻击者将目标网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，诱导用户点击。
禁止自己的 iframe 中的链接外部网站的JS

预防方案：

为 iframe 设置 sandbox 属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则
服务端设置 X-Frame-Options Header头，拒绝页面被嵌套，X-Frame-Options 是HTTP 响应头中用来告诉浏览器一个页面是否可以嵌入

opener

如果在项目中需要 打开新标签 进行跳转一般会有两种方式

// 1) HTML -> <a target='_blank' href='http://www.baidu.com'>
// 2)  JS  -> window.open('http://www.baidu.com')

/* 
 * 这两种方式看起来没有问题，但是存在漏洞。
 * 通过这两种方式打开的页面可以使用 window.opener 来访问源页面的 window 对象。
 * 场景：A 页面通过 <a> 或 window.open 方式，打开 B 页面。但是 B 页面存在恶意代码如下：
 * window.opener.location.replace('https://www.baidu.com') 【此代码仅针对打开新标签有效】
 * 此时，用户正在浏览新标签页，但是原来网站的标签页已经被导航到了百度页面。
 * 恶意网站可以伪造一个足以欺骗用户的页面，使得进行恶意破坏。
 * 即使在跨域状态下 opener 仍可以调用 location.replace 方法。
 */

<a></a>

<a target="_blank" href="" rel="noopener noreferrer nofollow">a标签跳转url</a>
<!-- 
  通过 rel 属性进行控制：
  noopener：会将 window.opener 置空，从而源标签页不会进行跳转（存在浏览器兼容问题）
  noreferrer：兼容老浏览器/火狐。禁用HTTP头部Referer属性（后端方式）。
  nofollow：SEO权重优化，详情见 https://blog.csdn.net/qq_33981438/article/details/80909881
 -->

b.window.open()

<button onclick='openurl("http://www.baidu.com")'>click跳转</button>
function openurl(url) {
    var newTab = window.open();
    newTab.opener = null;
    newTab.location = url;
}

XSS

XSS（Cross-Site Scripting），跨站脚本攻击（缩写和 CSS 重叠，所以叫 XSS）

利用网页开发时存在的代码，修改注入恶意代码到网页内部，用户访问页面时加载执行代码，从而实施攻击。这些恶意网页程序通常是 JavaScript，但实际上也可以包括 Java、VBScript、ActiveX、Flash 或者甚至是普通的 HTML。

攻击者在目标网站植入恶意脚本（js / html），用户在浏览器上运行时可以获取用户敏感信息（cookie / session）、修改 web 页面以欺骗用户、与其他漏洞相结合形成蠕虫等。

添加能修改页面内容的恶意 URL 参数
在评论功能中添加恶意代码

攻击方式

就是攻击者想尽一切办法将可以执行的代码注入到网页中。

存储型（server端）：

场景：见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
攻击步骤：
- 攻击者将恶意代码提交到目标网站的数据库中
- 用户打开目标网站时，服务端将恶意代码从数据库中取出来，拼接在HTML中返回给浏览器
- 用户浏览器在收到响应后解析执行，混在其中的恶意代码也同时被执行
- 恶意代码窃取用户数据，并发送到指定攻击者的网站，或者冒充用户行为，调用目标网站的接口，执行恶意操作

反射型（Server端）

与存储型的区别在于，存储型的恶意代码存储在数据库中，反射型的恶意代码在URL上

场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
攻击步骤：
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

Dom 型(浏览器端）

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

场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
攻击步骤：
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL。
- 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

预防方案：（防止攻击者提交恶意代码，防止浏览器执行恶意代码）

对数据进行严格的输出编码：如HTML元素的编码，JS编码，CSS编码，URL编码等等
- 避免拼接 HTML；Vue/React 技术栈，避免使用 v-html / dangerouslySetInnerHTML
CSP HTTP Header，即 Content-Security-Policy、X-XSS-Protection
- 增加攻击难度，配置CSP(本质是建立白名单，由浏览器进行拦截)
- Content-Security-Policy: default-src 'self'-所有内容均来自站点的同一个源（不包括其子域名）
- Content-Security-Policy: default-src 'self' *.trusted.com-允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
- Content-Security-Policy: default-src https://yideng.com-该服务器仅允许通过 HTTPS 方式并仅从 yideng.com 域名来访问文档
输入验证：比如一些常见的数字、URL、电话号码、邮箱地址等等做校验判断
开启浏览器XSS防御：Http Only cookie，禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
验证码

通过给别人发送带有恶意脚本代码参数的 URL，URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。

当读取 URL 中的一段代码进行执行时，比如下面的情况

<select>
  <script>
    document.write(`
	<option value=1>
		${location.href.substring(location.href.indexOf('default=') + 8)}
  </option>
`);
    document.write('<option value=2>English</option>');
  </script>
</select>
<!-- 通过修改 URL 就可以执行未知代码 -->

可能造成以下影响：

利用虚假输入表单骗取用户个人信息。不经过服务器存储，直接通过 HTTP 的 GET 和 POST 请求就能完成一次攻击，拿到用户隐私数据。
利用脚本窃取用户的 Cookie 值，被害者在不知情的情况下，帮助攻击者发送恶意请求。
显示伪造的文章或图片。
服务端较难排查问题，所以出现问题较难发现和响应修复

攻击的必要条件：

攻击者需要诱骗点击，必须要通过用户点击链接才能发起

所以为了避免被攻击，需要注意以下内容

尽量不要使用 eval，new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可执行字符串的方法。

除此之外，还有，存储型 XSS 攻击、反射型 XSS 攻击和 DOM 的 XSS 攻击；

持久型 XSS

一般存在于 Form 表单提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。

比如说，在评论中输入以下内容

<script>
	alert(996)
</script>

但是，攻击的成本很高

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

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

持久型 XSS 有以下几个特点：

持久性，植入在数据库中
盗取用户敏感私密信息
危害面广

浏览器遇到 html 中的 script 标签时，会解析并执行其中的 js 代码

针对这种情况，我们对特殊字符进行转译就好了（vue / react 等主流框架已经避免类似问题，vue 举例：不能在 template 中写 script 标签，无法在 js 中通过 ref 或 append 等方式动态改变或添加 script 标签）

XSS 类型：

持久型 XSS：将脚本植入到服务器上，从而导致每个访问的用户都会执行
非持久型 XSS：对个体用户某url的参数进行攻击

防御措施（对用户输入内容和服务端返回内容进行过滤和转译）

现代大部分浏览器都自带 XSS 筛选器，vue / react 等成熟框架也对 XSS 进行一些防护
即便如此，我们在开发时也要注意和小心
对用户输入内容和服务端返回内容进行过滤和转译
重要内容加密传输
合理使用get/post等请求方式
对于URL携带参数谨慎使用
我们无法做到彻底阻止，但是能增加黑客攻击成本，当成本与利益不符时自然会降低风险

如何防御

1，配置响应头

在响应头中设置该内容：Content-Security-Policy: default-src 'self'

查看更多有关于 Content-Security-Policy

也可以通过 meta 标签的方式进行开启 CSP 策略 <meta http-equiv="Content-Security-Policy">

只要开发者配置了正确的规则，那么即使网站存在漏洞，攻击者也不能执行它的攻击代码，并且 CSP 的兼容性也不错。

2，转义字符

用户输入永远不可信，所以，对于所有的特殊符号，都进行转义，实现防御功能，当然，markdown 语法可能不能转移，但也可以添加额外的黑名单，或者白名单，仅拒绝，允许某些内容进行输入。

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

3，HttpOnly Cookie。

设置 httpOnly 属性后，js 将无法读取到 cookie 信息，可以避免该网页的 cookie 被客户端恶意 JavaScript 窃取，保护用户 cookie 信息。

点击劫持

ClickJacking（点击劫持）

通过骗取用户进行操作，来实现点击劫持，通常搭配透明的 iframe 进行使用，一般会 iframe 覆盖原网页诱导用户进行某些操作达成目的。将攻击网站嵌套在当前网站的 iframe 中

防御措施

在 HTTP 投中加入 X-FRAME-OPTIONS 属性，此属性控制页面是否可被嵌入 iframe 中【DENY：不能被所有网站嵌套或加载；SAMEORIGIN：只能被同域网站嵌套或加载；ALLOW-FROM URL：可以被指定网站嵌套或加载。】
判断当前网页是等层窗口 iframe 嵌套
HSTS（HTTP Strict Transport Security：HTTP 严格传输安全）

响应头 X-FRAME-OPTIONS，这个 HTTP 响应头就是为了防御用 iframe 嵌套的点击劫持攻击。

DENY，表示页面不允许通过 iframe 的方式展示
SAMEORIGIN，表示只允许同源 iframe
ALLOW-FROM，表示只接受制定来源的 iframe

X-FRAME-OPTIONS HTTP 响应头是用来给浏览器指示允许一个页面可否在<frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站内容没有被嵌到别人的网站中去，也从而避免点击劫持的攻击。

有三个值：

DENY：表示页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
SAMEORIGIN：表示该页面可以在相同域名页面的 frame 中展示。
ALLOW-FROM url：表示该页面可以在指定来源的 frame 中展示。

配置 X-FRAME-OPTIONS：

Apache

把下面这行添加到 'site' 的配置中：
```
Header always append X-Frame-Options SAMEORIGIN
```
nginx

把下面这行添加到 'http', 'server' 或者 'location'，配置中
```
add_header X-Frame-Options SAMEORIGIN;
```

IIS

添加下面配置到 Web.config 文件中

  <system.webServer>
...
<httpProtocol>
  <customHeaders>
    <add name="X-Frame-Options" value="SAMEORIGIN" />
  </customHeaders>
</httpProtocol>
...
</system.webServer>

js 判断顶层窗口跳转，可轻易破解，意义不大

function locationTop(){
  if (top.location != self.location) {
     top.location = self.location; return false;
  }
  return true; 
 }
locationTop();

// 破解：
// 顶层窗口中放入代码
var location = document.location;
// 或者
var location = "";

网站接受从 HTTP 请求跳转到 HTTPS 请求的做法，例如我们输入“http://www.baidu.com”或“www.baidu.com”最终都会被 302 重定向到“https://www.baidu.com”。这就存在安全风险，当我们第一次通过) HTTP 或域名进行访问时，302 重定向有可能会被劫持，篡改成一个恶意或钓鱼网站。 HSTS：通知浏览器此网站禁止使用 HTTP 方式加载，浏览器应该自动把所有尝试使用 HTTP 的请求自动替换为 HTTPS：进行请求。用户首次访问时并不受 HSTS 保护，因为第一次还未形成链接。我们可以通过 浏览器预置HSTS域名列表 或 将 HSTS 信息加入到域名系统记录中，来解决第一次访问的问题。

URL 跳转

利用部分网站的跳转功能，在查询字符串中声明跳转的危险地址，实现跳转

http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd
http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd
http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

防御措施

referer 的限制

如果确定传递 URL 参数进入的来源，我们可以通过该方式实现安全限制，保证该URL的有效性，避免恶意用户自己生成跳转链接

加入有效性验证 Token

我们保证所有生成的链接都是来自于我们可信域的，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验，可以避免用户生成自己的恶意链接从而被利用，但是如果功能本身要求比较开放，可能导致有一定的限制。

跳转前进行确认，让用户选择是否跳转到指定页面

SQL 注入

在用户名中直接输入 sql 查询语句，让计算机误以为是用户的内容

-- 默认，理想状态下的用户输入 username='admin' psw='password'
SELECT * FROM user WHERE username='admin' AND psw='password'
-- 用户输入 username='admin' --' psw='password'
SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'
-- sql 会将 -- 后面的内容理解为注释，等价于搜索 admin
SELECT * FROM user WHERE username='admin'

获取数据库，获取了最高权限，那就是对数据为所欲为

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

如何防御

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

OS 命令注入

和 SQL 注入类似，针对操作系统进行攻击，只要能调用 Shell 的地方，就可以成为攻击对象。在插入命令后，进行请求

// 以 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 权限，只怕是要被扒了裤子。

CDN 劫持

出于性能考虑，前端应用通常会把一些静态资源存放到CDN（Content Delivery Networks）上面，例如 js 脚本和 style 文件。这么做可以显著提高前端应用的访问速度，但与此同时却也隐含了一个新的安全风险。如果攻击者劫持了CDN，或者对CDN中的资源进行了污染，攻击者可以肆意篡改我们的前端页面，对用户实施攻击。现在的CDN以支持SRI为荣，script 和 link 标签有了新的属性 integrity，这个属性是为了防止校验资源完整性来判断是否被篡改。它通过 验证获取文件的哈希值是否和你提供的哈希值一样来判断资源是否被篡改。使用 SRI 需要两个条件：一是要保证 资源同域 或开启跨域，二是在中 提供签名 以供校验。

integrity 属性分为两个部分，第一部分是指定哈希值的生成算法（例：sha384），第二部分是经过编码的实际哈希值，两者之前用一个短横 - 来分隔

HTTPS 中间人攻击

https 协议由 http + ssl 协议构成。

中间人攻击过程如下：

服务器向客户端发送公钥
攻击者截获公钥，保留在自己手上
然后攻击者自己生成一个【伪造的】公钥，发给客户端；
客户端收到伪造的公钥后，生成加密 hash（秘钥）值发给服务器；
攻击者获得加密 hash 值，用自己的私钥解密获得真秘钥；
同时生成假的加密 hash 值，发给服务器；
服务器用私钥解密获得假秘钥；
服务器用假秘钥加密传输信息；

防范方法：

服务器在发送浏览器的公钥中加入 CA 证书，浏览器可以验证 CA 证书的有效性；（现有 HTTPS 很难被劫持，除非信任了劫持者的 CA 证书）。

参考文章

作者	链接
阿宝哥	https://juejin.cn/post/6885471967714115597#heading-6
浪里行舟	常见六大Web 安全攻防解析
渴望成为大牛的男人	XSS攻击 && CSRF攻击基础理解
三毛丶	前端安全知识
牛客前端面试宝典	安全

CSRF​

攻击方式​

防御措施​

SameSite​

Referer Check​

Anti CSRF Token​

验证码​

同步表单 CSRF 校验​

双重 Cookie​

iframe 安全​

opener​

XSS​

攻击方式​

持久型 XSS​

如何防御​

点击劫持​

防御措施​

URL 跳转​

防御措施​

SQL 注入​

如何防御​

OS 命令注入​

CDN 劫持​

HTTPS 中间人攻击​

参考文章​

CSRF

攻击方式

防御措施

SameSite

Referer Check

Anti CSRF Token

验证码

同步表单 CSRF 校验

双重 Cookie

iframe 安全

opener

XSS

攻击方式

持久型 XSS

如何防御

点击劫持

防御措施

URL 跳转

防御措施

SQL 注入

如何防御

OS 命令注入

CDN 劫持

HTTPS 中间人攻击

参考文章