这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
今天学习了Web开发安全的一些相关知识。
一、攻击篇
安全攻击的方式
1.Cross-site Scripting(XSS)
跨站脚本攻击。在开发维护的页面中，攻击者通过一种方式将其恶意脚本注入进来，用户访问页面时，该脚本就会运行，造成用户隐私泄露等严重问题。
xss主要利用了：
a) 盲目信任用户提交的内容
b) 直接将用户提交的字符串转化为DOM
xss的特点
- 通常难以从UI上感知(暗地执行脚本)
- 窃取用户信息(cookie/token)
- 绘制UI(例如弹窗)，诱骗用户点击/填写表单 例如不会对submit内容进行过滤 xss根据性质分为几大类
- stored xss
- 存储型：恶意脚本被存在数据库中
- 访问页面→读数据被攻击
- 危害最大，对全部用户可见
- reflected xss
- 不涉及数据库
- 从url上攻击
- DOM-based xss
- 不需要服务器的参与
- 恶意攻击的发起和执行，全在浏览器端完成
- 利用了浏览器渲染DOM的特性（独特优化)
- 不同浏览器，会有区别(按浏览器进行攻击)
2.Cross-site request forgery(CSRF)
- 在用户不知情的前提下
- 利用用户权限（cookie)
- 构造指定HTTP请求，窃取或修改用户敏感信息
3.SQL Injection
其他的
- CLl
- os command
- Server-Side Request Forgery(SSRF)，服务端伪造请求·严格而言，SSRF 不是injection，但是原理类似
4.Denial of Service(DoS)
通过某种方式(构造特定请求)，导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应
一、防御篇
1.XSS的防御
- 永远不信任用户的提交内容
- 不要将用户提交内容直接转换成DOM
前端
-主流框架默认防御XSS - google-closure-library服务端(Node)
- DOMPurify 如果用户需求就是生成dom 注意：
- 对String进行转义
- 对图片进行扫描
- 尽量不要做用户自定义跳转行为
Same-origin Policy
同源策略 同源：确保两个url协议域名端口号完全相等
Content Security Policy(CSP)
- 哪些源(域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对eval + inline script 直接报错
2.CSRF的防御
