这是我参与「第四届青训营 」笔记创作活动的的第3天
一、课堂重点内容
- 攻击角度看web安全
- 防御角度看web安全
二、详细知识点介绍
攻击
Cross-Site Scripting(XSS)
在开发维护的界面中攻击者以某种方式将其恶意脚本注入进来，当用户访问界面时恶意脚本就会执行，可能导致用户隐私泄露或用户机器变为矿机等。
XSS主要利用了开发者盲目信任了用户的提交内容、直接将用户提交的string转换为了DOM
- 通常难以从UI上感知（暗地执行脚本）
- 窃取用户信息（cookie/token）
- 绘制UI（例如弹窗），诱骗用户点击、填写表单
XSS类型
- Stored XSS
- 恶意脚本被存在数据库中
- 访问页面→读数据=被攻击
- 危害最大，对全部用户可见
- Reflected XSS
- 不涉及数据库
- 从URL上攻击
- DOM-based XSS
- 不需要服务器的参与
- 恶意攻击的发起+执行，全在浏览器完成
- Mutation-based XSS
- 利用了浏览器渲染DOM的特性（独特优化）
- 不同浏览器，会有区别（按浏览器进行攻击）
Cross-site request forgery(CSRF)
- 在用户不知情的前提下
- 利用用户权限（cookie）
- 构造指定HTTP请求，窃取或修改用户敏感信息
Injection
SQL Injection
攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串， 欺骗服务器执行恶意的SQL命令
CLI Injection
由于嵌入式应用程序或者 web应用程序对用户提交的数据过滤不严格，导致黑客可以通过构造特殊命令字符串的方式，将数据提交至应用程序中，并利用该方式执行外部程序或系统命令实施攻击，非法获取数据或者网络资源等
OS Command Injection
操作系统命令注入（也称为外壳程序注入）是一个网络安全漏洞，攻击者可以利用该漏洞在运行应用程序的服务器上执行任意操作系统（OS）命令，通常会完全破坏应用程序及其所有数据。常常，攻击者可以利用OS命令注入漏洞来破坏托管基础结构的其他部分，利用信任关系将攻击转移到组织内的其他系统。
Server-Side Request Forgery(SSRF)
服务端伪造请求，严格而讲不是Injection，但是原理类似
Denial of Service(DoS)
通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应。
ReDos
利用贪婪匹配模式，通过回溯行为消耗服务器资源
Distributed DoS(DDoS)
短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求
- 直接访问IP
- 任意API
- 消耗大量带宽（耗尽）
传输层
中间人攻击
防御
XSS
永远不相信用户的提交内容：不要将用户提交内容直接转换成DOM
XSS现成工具
- 前端
- 主流框架默认防御 XSS
- google-closure-library
- 服务端
- DOMPurify
Content Security Policy(CSP)
基于同源政策
- 哪些源（域名）被认为是安全的
- 来自安全源的 脚本可以执行，否则直接抛错
- ban eval+inline script
CSRF
Origin+Referer
token
校验token
- 用户绑定
- 过期时间
iframe攻击
X-Frame-Options:DENY/SAMEORIGIN
- DENY:当前页面不能被作为iframe加载
- SAMEORIGIN：必须是同源页面才能加载iframe
CSRF anti-pattern
GET!==GET+POST 不要图省事把get和post写一起
SameSite Cookie
避免用户信息被携带
Injection
SQL
- 找到项目中查询SQL的地方
- 使用prepared statement
others
- 最小权限原则
- 建立白名单+过滤
- 对URL类型参数进行协议、域名、ip等限制
Regex DoS
- 避免写出类似贪婪匹配的处理方式
- 代码扫描+正则性能测试
- 拒绝使用用户提供的正则
DDoS
- 过滤
- 流量治理
- 负载均衡
- API网关
- CDN
- 流量治理
- 扛量
- 快速自动扩容
- 非核心服务降级
传输层
防御中间人——使用HTTPS：将HTTP主动升级到HTTPS
Subresource Integrity(SRI)
检测托管的静态资源是否被劫持：对比hash值
三、实践联系例子
XSS demo
服务器端：
攻击者：
CSRF demo
Injection demo
服务器端：
攻击者：
