这是我参与「第四届青训营 」笔记创作活动的的第4天
Web安全
攻击：
XSS：
通常难以从UI上感知（暗地执行脚本）
窃取用户信息（cookie/token）
绘制UI（例如弹窗），诱骗用户点击、填写表单
XSS demo
public asyns submit(ctx){
const{ const, id}=ctx.request.body;
//没有对content过滤
await db.save({
content
id
});
}
public async render(ctx){
const{content}=await db.query({
id:ctx.query.id
});
//没有对content过滤
ctx.body='<div>${content}</div>';
}
Stored XSS
- 恶意脚本被存在数据库中
- 访问页面->读数据=被攻击
- 危害最大，对全部用户可见
Reflected XSS
- 不涉及数据库
- 从URL上攻击
public asyns render(ctx){
const {param}=ctx.query;
ctx.status=200;
ctx.body='<div>${param}</div>';
}
DOM-based XSS
- 不需要服务器的参与
- 恶意攻击的发起+执行，全在浏览器完成
Mutation-based XSS
- 利用了浏览器渲染DOM的特性（独特优化）
- 不同浏览器，会有区别（按浏览器进行攻击）
Cross-site request forgery(CSRF)
- 在用户不知情的前提下
- 利用用户权限
- 构造指定HTTP请求，窃取或修改用户敏感信息
SQL injection
DoS
通过某种方式(构造特点请求)，导致服务器资源被显著消耗，来不及响应更多请求，导致请求 挤压，进而雪崩效应。
防御篇
XSS
- 永远不信任用户提交的内容
- 不要将用户提交的内容直接转换成DOM
XSS--现成工具
前端
- 主流框架默认防御XSS
- google-closure-library
服务端（Node）
DOMPurify
CSP
- 哪些源(域名)被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对eval+inline script说NO
CSRF的防御
- if伪造请求=异常来源
- then 限制请求来源->限制伪造请求
SameSite vs CORS
SameSite:
Cookie 发送
domain vs 页面域名
CORS: 资源读写（HTTP请求）
资源域名 VS 页面域名
白名单
SameSite demo
防御CSRF的正确姿势
injection
- 找到项目中查询SQL的地方
- 使用prepared statement
