安全基础

XSS 跨站脚本攻击

有哪几种
- 反射型（非持久型）
  - 恶意脚本存在 URL 里，服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器，恶意代码被执行
  - 一般发生在前后端一体的应用中
  - 现在是前后端分离，所以反射型不多见
  - 基于 url 上的xss攻击
  - 常见于通过 URL 传递参数的功能：如网站搜索
- 存储性
  - 黑客将恶意 JS 存储在服务端数据库中，所有用户一旦访问相关页面数据，恶意脚本就会被执行
  - 常见于贴吧评论
  - 防范：
    - 前端对输入进行转义/过滤（防范不了抓包修改数据）
    - 服务端也对数据进行转义
    - 前端展示之前，进行转义/过滤
- 基于 DOM 的
  - 取出和执行都是由浏览器端完成，属于前端漏洞
  - 原因：把不可信的内容插入到了页面，在使用 .innterHTML、.appendChild 等 API不小心
  - 内联事件监听都能把字符串作为代码运行 onClick=alert(1)
  - 链接跳转
  - JS 的 eval() setTimeOut() setInterval() 都能讲字符串作为代码执行
  - 防范：要对输入进行转义
危害
- 可以盗取用户 Cookie
- 未授权操作
- 发动 XSS 蠕虫攻击
- 。。。
怎么防
- 两大要素
  - 攻击装提交恶意代码
  - 浏览器执行恶意代码
- 对 URL 请求参数进行编码（反射型）
- 一切输入不可信，转义（存储型/转义型）
  - 白名单进行检测和过滤
- 使用 CSP 内容安全策略，定义域名白名单
  - 服务端使用 CSP 头部来指定策略，前端设置 meta 标签
    - 前端 meta 标签无法使用 report 上报
  - 兼容性不好
- 设置 Cookie 的 HttpOnly 属性
- 使用验证码

CSRF 跨站请求伪造

跨站请求伪造 Cross-Site request forgery

黑客引诱用户打开黑客的的网站，利于用户的登录状态发起跨站请求。

常见攻击手段
- 最容易实现的是 Get 请求，比如图片的 URL
- 构造隐藏表单来自动发起 Post 请求
- 通过引诱链接诱惑用户点击触发请求，a 链接的 href

攻击原理：

诱导站点B向站点A发送了一个请求，浏览器会默认携带站点A的Cookie信息。

要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。

在业界目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。

防御：

添加验证码

转账的时候等敏感操作，可以用

检测 Referer

Referer 可以被修改

使用 csrf Token

每次请求时都要携带这个 token
传统页面，每次下发隐藏域 CSRF Token，适合前后端不分离的网站(通常有效的方法是在使用 POST 方法提交的HTML表单的隐藏字段内将令牌传输给客户端。提交表单后，令牌将作为请求参数包括在内)
- JS 遍历 DOM，给所有的 a 和 form 标签后加上 Token
- POST 请求，要在 form 的最后加上
```
  <input type="hidden" name="csrf-token" value="CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz" />
```
前后端分离：通过 ajax 加上 csrfotken 这个 HTTP 头属性
Session机制在分布式环境下失效，因此在分布式集群中CSRF Token需要存储在Redis之类的公共存储空间

Samesite Cookie

可以有效防御 CSRF 攻击
存在兼容性问题
不支持子域
- 在主域名下存储了用户登录信息，每个子域名又要重新登录一次
有 2 个值
- Strict 严格，任何情况都不发送
  - B向站点A发送了一个请求，浏览器不会默认携带站点A的Cookie信息
  - 太严格了，不常用
- Lax 宽松
  - 放宽限制
  - GET HEAD 请求可以带上 Cookie
  - POST PUT DELETE 不能带上 Cookie
应用场景有待观望

双重 Cookie 验证

无需使用Session，适用面更广
此方法并没有大规模应用

如何防止网站被利用？

对于用户上传的图片，进行转存或者校验。不要直接使用用户填写的图片链接。
当前用户打开其他用户填写的链接时，需告知风险（这也是很多论坛不允许直接在内容中发布外域链接的原因之一

Security HTTP Headers

先读一下下面的文章

https://www.kiwii.ch/en/digital-marketing/security/http-headers-security-check/
https://geekflare.com/http-header-implementation/

有哪些 header？

HTTP Strict Transport Security(HSTS) 严格传输安全
Content Security Policy(CSP) header
HTTP Public Key Pinning(HPKP) header
Cross-Site Scripting (XSS) header XSS 头
X-Frame-Options "SAMEORIGIN" header
Referrer-Policy header

# security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;

# CSP 内容安全策略 
add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# . files
location ~ /\.(?!well-known) {
  deny all;
}

X-XSS-Protection

X-XSS 保护标头可以防止某些级别的 XSS（跨站点脚本）攻击，这与 IE 8+、Chrome、Opera、Safari 和 Android 兼容。

兼容性：Google，Facebook，Github使用此标头，并且大多数渗透测试咨询公司都将要求您实施此标头。

可以选择的值

0 XSS过滤器已禁用
1 如果检测到攻击，则启用XSS筛选器并清理页面
1;moder=block 启用XSS过滤器，并在检测到攻击时阻止渲染页面
1;report=http://example.com/report_URI 启用XSS筛选器，并在检测到攻击时上报

add_header X-XSS-Protection "1; mode=block";

HSTS

HTTP Strict Transport Security(HSTS) 严格的传输安全

HSTS（HTTP严格传输安全）头，以确保浏览器的所有通信都通过HTTPS（HTTP安全）发送。这可以防止HTTPS点击提示，并将HTTP请求重定向到HTTPS。

?> 兼容性：浏览器的所有主要最新版本（例如IE，Firefox，Opera，Safari和Chrome）都支持HSTS标头。

有三个参数配置。

max-age 告诉浏览器请求仅通过HTTPS可用的持续时间（以秒为单位）。
includeSubdomains 该配置也对子域有效。
preload 如果您希望将域包含在 HSTS 预加载列表中，请使用

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

X-Frame-Options

防止点击劫持。

通过实现此 header ，可以指示浏览器不要将您的网页嵌入 frame / iframe。

这个头部字段在浏览器支持方面有一些限制，因此您必须在实施之前进行检查。

add_header X-Frame-Options "SAMEORIGIN" always;

可能的值有

SAMEORIGIN 同源
DENY 禁止所有域名
ALLOW-FROM 指定一个URL

X-Content-Type-Options

TODO:

?> 通过将此标头添加到网页的HTTP响应中，可以防止 MIME 类型的安全风险。具有此标头可指示浏览器将文件类型视为已定义，并禁止内容嗅探。您只需添加“ nosniff”一个参数。

add_header X-Content-Type-Options nosniff;

Referrer-Policy

想要控制您网站的 Referrer-Policy ？有一定的隐私和安全优势。然而，并不是所有的浏览器都支持所有的选项，所以在实施之前，请检查您的要求。

add_header Referrer-Policy "no-referrer-when-downgrade";

add_header Referrer-Policy same-origin;

支持的语法：

no-referrer referrer 信息不回随着请求发送
no-referrer-when-downgrade [默认设置，其中当 HTTP到HTTP，HTTPS到HTTPS相同的协议发送 referrer。]
unsafe-url （full URL will be sent with the request.）
same-origin [Referrer will be sent only for same origin site.]
strict-origin [send only when a protocol is HTTPS]
strict-origin-when-cross-origin (the full URL will be sent over a strict protocol like HTTPS)
origin (send the origin URL in all the requests)
origin-when-cross-origin (send FULL URL on the same origin. However, send only origin URL in other cases.)

HPKP

HTTP Public Key Pinning (HPKP) header HTTP公共密钥固定 TODO:

通过固定证书来最大程度地降低中间人（MITM）的攻击风险。(它告诉Web客户端将特定的加密公共密钥与特定的Web服务器相关联，以降低使用伪造证书进行MITM攻击的风险)

您可以固定根证书公钥或即时证书。

HPKP当前可在Firefox和Chrome中运行，并支持SHA-256哈希算法。

Public-Key-Pins: 
    pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; 
    pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; 
    max-age=5184000;
    includeSubDomains; 
    report-uri="https://www.example.com/hpkp-report"

Feature-Policy

控制浏览器的功能，例如地理位置，全屏，扬声器，USB，自动播放，扬声器，振动，麦克风，付款，VR等，以在Web应用程序中启用或禁用。

Expect-CT - 试验阶段

仍处于试验状态的新标头将指示浏览器验证与Web服务器的连接以实现证书透明（CT）。 Google的这个项目旨在修复SSL / TLS证书系统中的某些缺陷。

X-Permitted-Cross-Domain-Policies

TODO:

使用Adobe产品（例如PDF，Flash等？您可以实现此标头，以指示浏览器如何处理跨域请求。

通过实现此标头，您可以限制从其他域加载网站的资产，以避免资源滥用。

// 只允许主策略

add_header X-Permitted-Cross-Domain-Policies master-only;

CSP

内容安全策略（或 CSP ）是一种安全机制，用于将网页上的内容（如 Javascript、图像、CSS 等）的来源限制为某些授权网站。这样可以更好地防范可能的 XSS 攻击。

作用

防止XSS，点击劫持，代码注入攻击。
只加载允许的内容
合理使用上报可以及时发现 XSS，利于尽快修复问题
禁止加载外域代码

让我们看一下两个最常用的参数。

default-src
- Load everything from a defined source
script-src
- Load only scripts from a defined source

以下示例将来自同一来源的所有内容加载到各种Web服务器中。

?> add_header Content-Security-Policy "default-src 'self';";

<meta http-equiv="Content-Security-Policy" content="form-action 'self';">

add_header Content-Security-Policy "default-src 'none';
    script-src 'self' 'unsafe-inline' 'unsafe-eval' 
        https://apis.google.com 
        www.google-analytics.com 
        *.googlesyndication.com 
        *.doubleclick.net 
        *.cloudflare.com 
        *.bootstrapcdn.com;
    style-src 'self' 'unsafe-inline' 
        https://fonts.googleapis.com
        *.bootstrapcdn.com;
    img-src 'self' data: 
        www.google.com 
        www.google.fr 
        www.google-analytics.com 
        *.cloudflare.com 
        *.doubleclick.net; 
    font-src 'self' 
        https://fonts.googleapis.com 
        https://fonts.gstatic.com 
        *.bootstrapcdn.com; 
        connect-src 'self'; 
    frame-src 'self' 'unsafe-inline' 
        *.doubleclick.net; 
    frame-ancestors 'none'; 
    form-action 'none'; 
    upgrade-insecure-requests; 
    block-all-mixed-content; 
    reflected-xss block; 
    base-uri 123run.com www.123run.com; 
    referrer no-referrer-when-downgrade";

CSP 内容安全策略

csp = Content Security Policy

Http Content-Security-Policy 响应头允许网站管理员控制用户代理为给定页面加载的资源。

CSP 通过告诉浏览器一系列规则，严格规定页面中哪些资源允许有哪些来源，不在指定范围内的统统拒绝。

相比同源策略，CSP 可以说是很严格了。

作用：

这有助于防范跨网站脚本攻击(XSS)。

用法

服务端返回添加 Content-Security-Policy 响应头的 Response 来指定规则
HTML 中添加 meta 标签来指定 Content-Security-Policy 规则

一个例子：Failed to load resource: net::ERR_CONNECTION_CLOSED

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

指令

fetch 指令
document 指令
navigation 指令
reporting 指令
其他指令

场景

限制内联脚本
限制外链加载 script
限制 form 表单提交范围
限制图片链接
限制 ajax 请求

示例：

add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

限制外链 script 只能是本域名下的

'Content-Security-Policy': 'script-src 'self''

OWASP

开放 Web 应用安全项目，又称为OWASP ，每年发布一份 Web 应用中最常见安全风险的清单。最近的名单可以在这里找到( https://owasp.org/www-project-top-ten/)。每年都可以发现同样的风险。

劫持[点击劫持]

黑客构建了一个 xx 网站，然后把一个微博页面放置在当前的 iframe 中，并且让整个 iframe 透明，并且把这个 iframe 让道一个非常有诱惑的内容上方。

你被诱导点击了网页内容，实际上点的是下面 iframe 页面的内容，具体攻击什么就不得而知了。

防御：设置适当的 HTTP 头来防止其被嵌入到另一个站点的iframe中

X-Frame-Options 头
- DENY
- SAMEORIGIN
- ALLOW-FROM

DDos

中间人攻击

npm audit

Npm audit命令可用于检查债务的安全性。它将应用中的依赖的版本号与集中式错误数据库中包含已知安全威胁的依赖的版本号列表进行比较。

使用 npm audit fix 自动修复程序

MDN Website security

在 Mozilla 的 MDN 上有一个非常好的网站安全指南，这个 Website security -guide*, 提出了一个非常重要的话题:

SQL 注入

对称/非对称加密

OAuth 2.0

Session 攻击与防护

如何防止云主机被扫

默认 22 端口修改掉，并使用密钥登陆，已经可以挡掉 99%的扫描了
3306 端口永远只对内网开放. 或者说，对外的端口应该只有 ssh/ web，其他端口不应该对外.