网络世界, 没有所谓的安全, 任何系统都存在漏洞, 只要时间足够以及具备值得被攻破的价值. 就会被攻击.

攻与防之间，本来就没有绝对的安全。

我们能做的就是，尽量提高攻击的成本。

有时有些方案虽然有漏洞，但是实现起来足够简单，但是并不会过度影响业务性能（比如响应时间）。

所以，权衡安全性、开发成本、对系统性能的影响，选择比较折中、比较合理的方案更为重要。

Web安全 - FreeBuf网络安全行业门户  // Web安全 20200710

https://github.com/ningxiaofa/sectoolset  // 搜集的Github关于安全工具集合 -- 20210308

https://github.com/ningxiaofa/learning_of_web_security  // Web安全攻防 -- 20210308

安全攻防技能30讲_安全_漏洞_黑客-极客时间  -- 推荐系统学习

什么是 XSS 攻击XSS 全称是 Cross Site Scripting，为了与“CSS”区分开来，故简称 XSS，翻译过来就是“跨站脚本”。

XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

最开始的时候，这种攻击是通过跨域来实现的，所以叫“跨域脚本”。

但是发展到现在，往 HTML 文件中注入恶意代码的方式越来越多了，所以是否跨域注入脚本已经不是唯一的注入手段了，但是 XSS 这个名字却一直保留至今。

当页面被注入了恶意 JavaScript 脚本时，浏览器无法区分这些脚本是被恶意注入的还是正常的页面内容，所以恶意注入 JavaScript 脚本也拥有所有的脚本权限。

下面我们就来看看，如果页面被注入了恶意 JavaScript 脚本，恶意脚本都能做哪些事情。

可以窃取 Cookie 信息。恶意 JavaScript 可以通过“document.cookie”获取 Cookie 信息，然后通过 XMLHttpRequest 或者 Fetch 加上 CORS 功能将数据发送给恶意服务器；恶意服务器拿到用户的 Cookie 信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。

可以监听用户行为。恶意 JavaScript 可以使用“addEventListener”接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。黑客掌握了这些信息之后，又可以做很多违法的事情。

可以通过修改 DOM 伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。

还可以在页面内生成浮窗广告，这些广告会严重地影响用户体验。除了以上几种情况外，恶意脚本还能做很多其他的事情，这里就不一一介绍了。总之，如果让页面插入了恶意脚本，那么就相当于把我们页面的隐私数据和行为完全暴露给黑客了。

恶意脚本是怎么注入的

现在我们知道了页面中被注入恶意的 JavaScript 脚本是一件非常危险的事情，所以网站开发者会尽可能地避免页面中被注入恶意脚本。

要想避免站点被注入恶意脚本，就要知道有哪些常见的注入方式。通常情况下，主要有存储型 XSS 攻击、反射型 XSS 攻击和基于 DOM 的 XSS 攻击三种方式来注入恶意脚本。

1. 存储型 XSS 攻击

2. 反射型 XSS 攻击

3. 基于 DOM 的 XSS 攻击

如何阻止 XSS 攻击?

我们知道存储型 XSS 攻击和反射型 XSS 攻击都是需要经过 Web 服务器来处理的，

因此可以认为这两种类型的漏洞是服务端的安全漏洞。

而基于 DOM 的 XSS 攻击全部都是在浏览器端完成的，因此基于 DOM 的 XSS 攻击是属于前端的安全漏洞

但无论是何种类型的 XSS 攻击，它们都有一个共同点，那就是首先往浏览器中注入恶意脚本，然后再通过恶意脚本将用户信息发送至黑客部署的恶意服务器上。

所以要阻止 XSS 攻击，我们可以通过阻止恶意 JavaScript 脚本的注入和恶意消息的发送来实现。

常用的阻止 XSS 攻击的策略。

1. 服务器对输入脚本进行过滤或转码
不管是反射型还是存储型 XSS 攻击，我们都可以在服务器端将一些关键的字符进行转码，比如最典型的：

2. 充分利用 CSP
虽然在服务器端执行过滤或者转码可以阻止 XSS 攻击的发生，但完全依靠服务器端依然是不够的，我们还需要把 CSP 等策略充分地利用起来，以降低 XSS 攻击带来的风险和后果。

实施严格的 CSP 可以有效地防范 XSS 攻击，具体来讲 CSP 有如下几个功能：
限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
禁止向第三方域提交数据，这样用户数据也不会外泄；
禁止执行内联脚本和未授权的脚本；

还提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。因此，利用好 CSP 能够有效降低 XSS 攻击的概率。

3. 使用 HttpOnly 属性
由于很多 XSS 攻击都是来盗用 Cookie 的，因此还可以通过使用 HttpOnly 属性来保护我们 Cookie 的安全。

更多信息参见:

参见 极客时间 - 浏览器工作原理与实践 - 浏览器安全[33 | 跨站脚本攻击（XSS）：为什么Cookie中有HttpOnly属性？-极客时间]

补充

参考代码实现

PHP【Yii】

/**
 * 判断Url地址是否是Xss地址
 * @param $url
 * @param string $scene
 * @return bool
 */
public static function isXssUrl($url, $scene = 'image'): bool
{
    if (empty($url)) return true;
    $url = strip_tags($url);
    $url = htmlspecialchars($url);
    $urlInfo = parse_url($url);
    switch ($scene) {
        case 'video':
            $cdnUrl = Yii::$app->params['aws']['video_cdn'] ?? '';
            if (ManageFeedResource::videoType == 'ali') {
                $cdnUrl = Yii::$app->params["ali"]["video_cdn"] ??
                    "https://outin-113d4dfc9bfe11ea911000163e00e7a2.oss-ap-southeast-1.aliyuncs.com";
            }
            break;
        default:
            $cdnUrl = Yii::$app->params['aws']['url'] ?? '';
    }
    $cdnUrlInfo = parse_url($cdnUrl);
    // 验证域名主体
    $urlHost = $urlInfo['host'] ?? '';
    $cdnHost = $cdnUrlInfo['host'] ?? '';
    // 验证url方案(https)
    $urlPrefix = $urlInfo['scheme'] ?? "";
    $cdnPrefix = $cdnUrlInfo['scheme'] ?? "";
    return empty($urlHost) || empty($cdnHost) || $urlHost != $cdnHost || $urlPrefix != $cdnPrefix;
}

CSRF 保护 | 基础组件 | Laravel 5.8 中文文档  // 建议多阅读并实践几遍

表单方法伪造与跨站请求伪造（CSRF）攻击防护 | 路由&控制器篇 | Laravel 入门到精通教程

CSRF 保护 | 基础组件 | Laravel 6 中文文档

前后端分离下如何防御CSRF攻击 - 简书

34 | CSRF攻击：陌生链接不要随便点-极客时间

网上有很多关于防御CSRF攻击的文章，大都雷同。方法主要有三种：

1. 检查Referer
2. 使用CSRF Token
3. 使用验证码

第二种方法大都是通过在form中填充隐藏的csrf_token。

这种方法适用于服务器端渲染「简称 SSR，客户端渲染：CSR」的页面，对于前后端分离的情况就不太适用了。

针对前后端分离情况，有两种方法。

Cookie-to-header token

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/

浏览器索要登录页面的时候，服务器生成一个随机的csrf_token，放入cookie中。

浏览器通过JavaScript读取cookie中的Csrf_token，然后在发送请求时作为自定义HTTP头发送回来。

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

服务器读取HTTP头中的Csrf_token，与cookie中的Csrf_token比较，一致则放行，否则拒绝。

这种方法为什么能够防御CSRF攻击呢？
关键在于JavaScript读取cookie中的Csrf_token这步。由于浏览器的同源策略，攻击者是无法从被攻击者的cookie中读取任何东西的。所以，攻击者无法成功发起CSRF攻击。

JWT(Json Web Token)
【功能实现】分布式系统 - 登录 - 学习/实践_穿素白衫的中少年的博客-CSDN博客_分布式登录系统

【功能实现】登录模块 - 学习/实践_穿素白衫的中少年的博客-CSDN博客

Note ↓

1. 构建 JavaScript 驱动的应用时，为方便起见，可以让 JavaScript HTTP 库自动在每个请求中添加 CSRF 令牌。默认情况下，resources/js/bootstrap.js 中提供的 Axios HTTP 库会使用加密后的 XSRF-TOKEN Cookie 值自动发送 X-XSRF-TOKEN 请求头。如果你没有使用这个库，则需要手动在应用中配置该实现。

2.有时候我们需要从 CSRF 保护中间件中排除一些 URL.

例如，如果你使用了第三方支付系统（如支付宝或微信支付）来处理支付并用到他们提供的回调功能，这时候就需要从 Laravel 的 CSRF 保护中间件中排除回调处理器路由，因为第三方支付系统并不知道要传什么 token 值给我们定义的路由。

更多详情

例如：// 20200904

网易云音乐

直接在url的query string中添加csrf_token进行验证.

主要用于post方式的请求.

SQL注入与检测_william_n的博客-CSDN博客

TBD

拒绝服务攻击  -- 推荐阅读，国外的blog

概念 ↓

https://zh.wikipedia.org/wiki/重放攻击

https://baike.baidu.com/item/重放攻击/?fr=aladdin

简要定义 ↓

重放攻击(Replay Attacks)又称重播攻击、回放攻击，是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。重放攻击可以由发起者，也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发给认证服务器。重放攻击在任何网络通过程中都可能发生，是计算机世界黑客常用的攻击方式之一。

引子

13 | 实战二（上）：如何对接口鉴权这样一个功能开发做面向对象分析？-极客时间

网友一

重放攻击防止方式有三种：
1、加时间戳
客户端与服务端有时间差，例如60s内的都算有效。那么黑客可以60s以内进行重放攻击，就有效。
2、时间戳+nonce（随机数）
每次请求成功后，保存nonce，例如放在redis和数据库中，再次请求如果nonce相同，则为重放攻击。
3、基于record的方案，就是和你说的保存token的意思差不多
把每次请求保存在数据库中，接收到新请求后，校验是否存在，如果存在，则请求非法。也可以与1结合时间戳只保存60s以内的数据。
参考：
负载均衡 接口鉴权 - API 文档 - 文档中心 - 腾讯云
掘金

网友二

OAuth 2.0 + 网关（如Zuul）+ 认证中心 + AOP可以实现。
极客时间《微服务架构实战160讲》里介绍了OAuth 2.0企业级的解决方案，小争哥的方案适合快速落地。

实际业务中如果安全等级没这么高，直接生成Token鉴权就可以。通过业务模型规避风险：
1. 充值类业务，就算对方篡改接口，最终结果可以通调用证金融机构的接口验证是否有效，不会给公司带来损失。
2. 如果安全等级非常高，比如提现、转账可以通过发送手机短信，确保是本人操作。
3. 如果是商品信息查询类接口，防止第三方爬取数据，可以在调用一定次数后加入”人机验证“（输入图片识别码、拼图）。
4. 根据IP限制访问次数。
5. 服务器间调用可以绑定mac地址、IP。
6. 服务器、客户端通过架设私有VPN进行通信，将安全问题转移到VPN上，降低业务复杂度的同时还可以避免加解密带来的性能损耗，提升性能。
7. 调用接口时通过付费方式（如实名认证、银行四要素验证这些调用一次都是要收费的），防止恶意调用。
8. 通过独立加密硬件（如U盾）+ 独立密码验证器（Google验证器）+ 语音识别 + 面部识别（刷脸支付） + 指纹 + 多人同时输入动态秘钥（核打击时发射程序）。
9. 安全性会降低系统性能适可而止。
极客时间《左耳听风》专栏中介绍了亚马逊在设计开发微服务时，就已经做好了随时对外网开放的准备，由于没有阅读完整个专栏，不知道后面有没有详细介绍。

网友三[小白]

防止重放攻击的方案在老师的基础做进一步的迭代设计:
1.要求客户端生成一个唯一的请求id，如以uuid方式
2.客户端在以sha等加密哈希方式生成token时，也将请求id加入其中
3.客户端也要将请求id作为参数传递到服务端，如果是rest api就是也要将请求id拼接到url参数中
4.服务端检查服务端的缓存中(可以是redis)是否有客户端传递的请求id，如果有，则判定为重放攻击，拒绝请求。如果没有，则将请求id放到缓存中同时设置在token失效的时间窗内缓存的请求id自动失效(如redis key的TTL)

这个实现思路是: 在时间窗内的重放攻击，以服务端在时间缓存了在时间窗内的所有请求id的形式来防护，而在时间窗外的重放攻击就是老师的方案中检查客户端传过来的时间(时间戳)和服务端当前时间(时间戳)相减的绝对值不能超过时间窗的长度来实现。另外，时间戳、请求id等都hash在了token
中，所有客户端是无法篡改的。

这个实现思路的缺点是: 改实现方案要求客户端的时间和服务端的时间之间的差距不能超过时间窗，如果时间窗设置为1分钟这种比较小的，则要求客户端时间和服务端时间不能超过1分钟，这个有点苛刻，比如客户端如app所在的手机的时间不准确了，但就差1分钟，将无法访问接口。如果时间窗设置过长，如30分钟，则要求服务端缓存中缓存最近30分钟的请求id，如果接口的访问并发挺大的话，缓存占用空间也将很大，需要评估。

请继续技术调研

...

PHP安全与漏洞-免费在线视频教程-php中文网   // PHP安全与漏洞

整理实践TBD

产品团队必须能够阻止，监视和警告HTTP请求中的常见攻击模式或技术（如果适用于您的服务）：OWASP Top 10和其他应用程序安全漏洞（例如SSRF，SQLi，XSS，XXE，LFI，RCE，CSRF，业务逻辑漏洞等）。

蛮力攻击（例如，用户枚举，凭据填充，密码猜测）。

产品滥用或滥用（例如帐户接管，滥用业务逻辑缺陷）。-- SEEK RFC022

常见web攻击总结 - morethink - 博客园 // 常见Web攻击总结

安全|常见的Web攻击手段之CSRF攻击 - 简书  // 安全|常见的Web攻击手段之CSRF攻击

XSS实战：我是如何拿下你的百度账号

总结几种常见web攻击手段及其防御方式

浅谈CSRF攻击方式

前后端分离下如何防御CSRF攻击 - 简书  // 前后端分离下如何防御CSRF攻击

jQueue 动态设置form表单的action属性的值和方法

javascript的String到int(32位)的hash算法

负载均衡 接口鉴权 - API 文档 - 文档中心 - 腾讯云
掘金

PHP_SELF漏洞 - 简书  // PHP_SELF漏洞

https://blog.csdn.net/xuanyuan_fsx/article/details/104967382  // 程序猿应该知道的黑客技术大汇总

https://github.com/ningxiaofa/sectoolset  // 搜集的Github关于安全工具集合 -- 20210308

https://github.com/ningxiaofa/learning_of_web_security  // Web安全攻防 -- 20210308