这是我参与[第四届青训营]笔记创作活动的第六天。
安全问题会危害:
- 用户
- 公司
- 程序员(祭天)
两个角度看web安全
- 攻击
- 防御
攻击篇:
1、跨站脚本攻击:
xss的一些特点:
- 通常难以从UI 上感知(暗地执行脚本)
- 窃取用户信息(cookie/token)
- 绘制UI(例如弹窗),诱骗用户点击/填写表单
xss可以直接提交恶意脚本,诱导用户点击。
stored xss
- 恶意脚本被存在数据库中
- 访问页面→读数据===被攻击
- 危害最大,对全部用户可见
Refleted XSS :
- 不涉及数据库
- 从URL上进行攻击
基于DOM的XSS攻击
DOM-based XSS:
- 不需要服务器的参与
- 恶意攻击的发起+执行,全在浏览器完成
基于Mutation的XSS攻击
- 利用了浏览器渲染DOM的特性(独特优化)
- 不同浏览器会有区别(按浏览器进行攻击)
最难防御的一种方式
2、 跨站伪造请求:
- 在用户不知情的前提下
- 利用用户权限(cookie)
- 构造指定HTTP请求,窃取或修改用户敏感信息
3、注入攻击:
- 读取请求字段
- 直接以字符串的形式拼接SQL语句
- CLl
- OS command
- Server-Side Request Forgery(SSRF),服务端伪造请求
- 严格而言,SSRF 不是injection,但是原理类似
SSRF demo
- 请求【用户自定义】的callback URL
- web server通常有 内网访问权限
4、服务拒绝:
通过某种方式(构造特定请求),导致服务器资源被显著消耗,来不及响应更多请求,导致请求挤压,进而雪崩效应。
Distributed DoS(DDoS):
短时间内,来自大量僵尸设备的请求流量,服务器不能及时完成全部请求,导致请求堆积,进而雪崩效应,无法响应新请求。
总而言之:不搞复杂的,量大就完事儿了!!!
攻击特点:
- 直接访问IP
- 任意API
- 消耗大量带宽(耗尽)
5、洪水攻击:
发送大量TCP请求 使服务器握手无法完成。连接数无法释放,服务器达到最大连接次数,新请求无法响应。
6、中间人攻击:
可能发生的原因:
- 明文传输
- 信息篡改不可知
- 对方身份未验证
防御篇:
XSS防御:
- 永远不信任用户的提交内容
- 不要将用户提交内容直接转换成DOM
防御XSS 现成工具:
前端
- 主流框架默认防御XSS
- google-closure-library
服务端(Node)
- DOMPurify
特例: 有些用户需求必须动态生成DOM
string-DOM
对string进行转译
上传svg
对svg进行扫描
自定义跳转链接
尽量不要然用户自定义跳转链接
自定义样式
尽量不要然用户自定义样式
插播:同源内容
协议、域名、端口都相同才可称为同源
CSP防御:
- 哪些源(域名)被认为是安全的
- 来自安全源的脚本可以执行,否则直接抛错
- 对eval + inline script说NO
CSRF防御:
其他判断请求来自合法来源的方式:
先有页面,后有请求
- if(请求来自合法页面)
- then C服务器接收过页面请求)
- then C服务器可以标识
iframe攻击:
绕过Origin,同源请求
反模式: GET!==GET+POST
将更新+获取逻辑放到同一个GET接口
public async getAndUpdate(ctx) {
const f update, id J=(ctx.query;
if ( update){await this.update( update);
}
ctx.body = await this.get( id);
}
避免用户信息被携带:SameSite Cookie:
从根源上解决了CSRF攻击
依赖Cookie 的第三方服务怎么办?
- 内嵌一个下站服务器。识别不了用户登录状态,发不了弹幕
SaneSite VS CORS
sameSite
- cookie发送
- domain vs 页面域名
- 我跟你说个事儿,出这屋我可就不认了
CORS
- 资源读写(HTTP请求)
- 资源域名vs页面域名
- 白名单
防御CSRF的正确姿势:
从node层角度来说,应做一个中间件专门针对CSRF
注入防御:
SQL:
- 找到项目中查询SQL的地方
- 使用prepared statement
其他:
最小权限原则
- sudo ll root
建立允许名单+过滤
- rm
对URL类型参数进行协议、域名、ip等限制
- 访问内网
DOS:
- Code Review (×/(ab*)+/)
- 代码扫描+正则性能测试
- 拒绝用户提供的使用正则
DDoS:
过滤:
- 流量治理
- 负载均衡
- API网关
- CDN
抗量:
- 快速自动扩容
- 非核心服务降级
传输层:防御中间人:
HTTPS的一些特性:
- 可靠性:加密
- 完整性:MAC验证
- 不可抵赖性:数字签名
非对称加密:
HTTPS--完整性:
数字签名:
数字签名(又称公钥数字签名)是只有信息的发送者才能产生的别人无法伪造的一段数字串,这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。它是一种类似写在纸上的普通的物理签名,但是使用了公钥加密领域的技术来实现的,用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算,一个用于签名,另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。
HTTPS--不可抵赖:数字签名:
总结:
- 安全无小事
- 使用的依赖(npm package,甚至是NodeJS)可能成为最薄弱的一环
- left-pad事件
- eslint-scope事件
- event-stream事件
- 保持学习心态
npm install除了带来了黑洞,还可以带来漏洞