攻击篇

XSS(Cross-Site Scripting)攻击：

起因：

盲目信任用户的提交内容，并将内容直接放置到浏览器中的dom对象中。

特点：

• 通常难以从UI上感知（暗地执行脚本）
• 窃取用户信息(cookie/token)
• 绘制UT(例如弹窗)，诱骗用户点击/填写表单

分类：

1. Stored XSS

• 恶意脚本被存在数据库中
• 访问页面→读数据 ≡ 被攻击
• 危害最大，对全部用户可见

2. Reflected XSS

• 不涉及数据库
• 从URL中攻击

3. DOM-based XSS

• 不需要服务器的参与
• 恶意攻击的发起 + 执行， 全在浏览器完成

4. Mutation-based XSS

• 利用了浏览器渲染DOM的特性
• 不同浏览器，会有区别（根据浏览器攻击）

CSRF攻击(Cross-Site request forgery）

• 在用户不知情的前提下
• 利用用户权限（cookie)
• 构造指定HTTP请求，窃取或修改用户敏感信息

<-当用户点击该请求时，根据cookie跟银行接口进行转账的完成-->
<a href="https://bank.com/transfer?to=hacker&amount=l00">点我抽奖</a>

3. SQL注入

注入攻击过程举例：

1. 正常前端sql查询

2. 用户删库查询

除了SQL，类似的还有CLI、OS command，Server-Side Request Forgery（SSRF），服务端伪造请求

Denial of Service（Dos）

不断显著消耗服务器资源，导致服务器来不及响应更多请求，导致请求积压，雪崩效应产生

基于正则表达式的DOS

4. Distributed DOS（DDos）

短时间内，完成海量请求 攻击特点

• 直接访问IP
• 任意API
• 消耗大量带宽（耗尽）

5. 传输层攻击

中间人攻击

起因：

1. 明文传输
2. 信息篡改不可知
3. 对方身份未验证

用https进行防御

防御篇

XSS防御

永远不信任用户的提交内容，也不要将用户提交内容直接转换成DOM

前端

• 主流框架默认防御XSS

Same-origin Policy

源：协议、域名、端口统统相同 HTTP请求：一般要求同源

Content Security Policy

• 定义哪些源被认为是安全的
• 否则对eval或内联的标签直接拒绝

CSRF的防御

CSRF token防御机制

CSRF反模式

有时开发偷懒将get请求和post请求放在一个请求中，无id则说明提交表单，则为post请求；有id则为get请求；但很容易被hacker盗取信息

SameStie Cookie