web开发的安全之旅｜青训营笔记

祛毒a
67 阅读4分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天

以下为今日课上笔记内容

Web 安全一窥

安全问题“很常见”，会危害

  • 用户
  • 公司
  • 程序员 (祭天)

91d10b90a04a6fa12ded53b81ae4686.png

很遗憾，这个[免费变强] 的功能下线了

e8dc45abfdd8193eb56466d85f2be7d.png

两个角度看 web 安全

1.假如你是一个 hacker一一攻击

2.假如你是一个开发者一一防御

一.攻击篇

1.Cross-Site Scripting(XSS)

6da8e52585362b552807f33511e68e8.png

  • XSS 主要利用了 856af00b515b6ff11a5a3bd26f04ebf.png
  • XSS 的一些特点

通常难以从UI上感知(暗地执行脚本）

窃取用户信息 (cookie/token)

绘制 UI(例如弹窗)，诱骗用户点击/填写表单

  • XSS demo

6766c1ab5a05bfec8d2cbda27950fc5.png 可以直接提交恶意脚本

0ba09ed0df1f052225feb477f49b67f.png

  • 类型

1）.Stored XSS（存储型）

恶意脚本被存在数据库中

访问页面->读数据==被攻击

危害最大，对全部用户可见

f0b063ca4414d7c1aff726625fe9825.png

2）.Reflected XSS

不涉及数据库

从URL上攻击

  • Reflected XSS Demo

e00d14d5ffe1606f6fc2653f28d3811.png

3）.DOM-based XSS

不需要服务器的参与

恶意攻击的发起+执行，全在浏览器完成 a7553db5630f8bb1bebdd12267f9f25.png

Reflected vs DOM-based

一个为服务端 一个为浏览器 acc2431b03c6bba4c1c6568914f7f6c.png

4）.Mutation-based XSS

利用了浏览器渲染 DOM 的特性(独特优化)

不同浏览器，会有区别(按浏览器进行攻击）

28b115e744ad83c74e6597d28c5bf34.png

2.Cross-site request forgery(CSRF)

在用户不知情的前提下

利用用户权限(cookie)

构造指定HTTP请求，窃取或修改用户敏感信息

CSRF demo ce50572fba7e8789460afd97e90ed52.png

类型： 1）CSRF--GET

7ff4f0aee10b59537c27cbde64b538b.png

2）CSRF--beyond GET

fc9f47fe0b092b64c0a7e9721362f39.png

3.Injection（注入）

  • SQLInjection

b2603869a3bc8d59452190813e98ff4.png

  • Injection demo 1

读取请求字段

直接以字符串的形式拼接SQL 语句

f20d481ec65178064f622926394eb04.png

0ccd649b45712fbdb2ece02349e9f33.png

Injection 不止于 SQL

  • CLI
  • OS command
  • Server-Side Request Forgery(SSRF)，服务端伪造请求
  • 严格而言，SSRF 不是 injection，但是原理类似

Injection demo 2一一执行

07d00ea28ef79539552166c5506d0e3.png

3ac202fa8158ad0f0435d3339501f75.png

  • Injection demo2--读取 +修改

859bab0a9c69855d146acfbdf657364.png

  • SSRF demo

1）请求[用户自定义]的 callback URL

2）web server 通常有内网访问权限

ca014b707ff8524a88651deffb3b174.png

  • Denial of Service(DoS)

导致服务器资源被显薯消耗通过某种方式(构造特定请求)，来不及响应更多请求，导致请求挤压，进而雪崩效应。

  • 插播: 正则表达式一一贪婪模式

重复匹配时[?]vs [no ?]: 满足“一个“即可 vs 尽量多

0cc718941a52b4d64d127fa8cb0a5e6.png

  • ReDoS:基于正则表达式的 DoS

贪婪:n 次不行? n- 1 次再试试? --回溯

ba0000b9a32b9092ed781560cb1c630.png

  • Distributed DoS(DDoS)

短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，!导致请求堆积，进而雪崩效应，无法响应新请求 [不搞复杂的，量大就完事儿了]

  • DDos

攻击特点

1)直接访问 IP

2)任意API

3)消耗大量带宽(耗尽)

  • DDoS demo

a3041c4466f6ccd32cbb17025c54948.png

  • 传输层

1.中间人攻击

1)明文传输

2)信息篡改不可知

3)对方身份未验证

087787cb2c92b4f7046cdf37ce52251.png

二.防御篇

1.XSS

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

9f761023abe9e27a931a1d3730d33ae.png

2.XSS一一现成工具

前端

  • 主流框架默认防御XSS
  • google-closure-library 服务端 (Node)
  • DOMPurify

3.XSS一一耗子尾汁

[用户需求] 不讲武德，必须动态生成 DOM

string -> DOM

ad6b48d7ce87f8b535a0fc476ce5294.png

上传svg

45857e1afb1903187a0f36d4c77bdff.png

自定义跳转链接

367125ff6dedd825bc0b6db485f2cef.png

自定义样式

ed048c50c0fc16cbc4ed54a2dbe608d.png

4.插播: Same-origin Policy

  • 协议
  • 域名
  • 端口

ccdc33de72b5df6afba48aa1f0d2593.png

50f554fc6f5c0969699cc08077b37d5.png

5.Content Security Policy(CSP)

CSP

  • 哪些源(域名)被认为是安全的
  • 来自安全源的脚本可以执行，否则直接抛错
  • 对 eval + inline script 说不

服务器的响应头部

42b2b475f0ac542363f798086b8a18b.png

浏览器 meta

f26fbf4b20e2d32342d6470e8d668c4.png

6.CSRF的防御

6c6cf59e5f6fc40d2a97d6058c915c8.png

7.CSRF--token

除了 Origin + Referrer其他判断[请求来自于合法来源]的方式

026493bd5324b18f9d4e55015793523.png

c126d75441c3b71f3d1a383f06360f9.png

1）用户绑定攻击者也可以是注册用户 === 可以获取自己的token

2)过期时间[前向保密]

8.CSRF--iframe 攻击

095749144d5a5fb3c5994bef73dfd7b.png

9.CSRF anti-pattern

GET != GET + POST

b88bb7c8f81709c6fe71d86bcd39569.png

避免用户信息被携带: SameSite Cookie

a77251dd3be791106ec67ce284a04be.png

10.SameSite Cookie

af0fc62c8089db9aaf736fc7527de84.png

依赖 Cookie 的第三方服务怎么办?

  • 内嵌一个 X 站播放器，识别不了用户登录态，发不了弹幕

99c648be398e9dfd6e603a1dedcf8bf.png

11.SameSite vs CORS

SameSite

  • Cookie 发送
  • domain vs页面域名
  • "我跟你说个事儿出这屋我可就不认了"

CORS

  • 资源读写(HTTP请求)
  • 资源域名vs页面域名
  • 白名单

12.SameSite demo

FirstPartyCookie 3PartyCookie

f9600415f2f5714737a4417be339f52.png

13.防御CSRF的正确姿势

Case by case 防御?不

527135bc722f9a7088aceac45007a59.png

Injection

  • 找到项目中查询 SQL 的地方
  • 使用 prepared statement

6f284a48351c632338cd00ab067ee8f.png

14.Injection beyond SQL

4686310376e03d42b76c714f0cc141b.png

15.防御 DoS

Regex DoS

d3344ef5b00c6d847a2397367f0a792.png

DDos

be110df51200b215682890a9c031d09.png

16.传输层一一防御中间人

a3ae8e0ebdfec92739a062a6191a19d.png

17.HTTPS的一些特性

  • 可靠性:加密
  • 完整性:MAC验证
  • 不可抵赖性:数字签名

明文

篡改身份

aca9d01ff35f6ac2afc91028ba9e480.png

01674522727e017121c693f979a6d20.png

18.HTTPS一一完整性

c3a3da33a0f35c045f0bc1dcafe82e1.png

19.插播:数字签名

签名执行者

  • privateKey (自己藏好)
  • publicKey (公开可见)

e3af2e7eef4e049e050cb778860a3a1.png

20.HTTPS一一不可抵赖:数字签名

e1758c03d987f0a37e8cbd540c96c7f.png

21.HTTPS一一证书续

7c21106907818709ae057d6a207dca7.png

22.HTTPS一一证书 demo

c4fb2b7d0bc9400b69bba9d6c50e130.png 成也证书，败也证书

c7254374a10f9fcf85ef126705d6e42.png

23.HTTP Strict-Transport-Security(HSTS)

e3c6c669c4b006dab354316cfdeea9b.png

24.Subresource Integrity(SRI)

56575fa39fb1e807a65610ae77d7cbe.png

25.SRI--demo

标签 hash (原始内容 hash) vs 实际内容 hash

094293b71066632b98867fa6398619a.png

一点点补充内容

6112f61f5003532e04b00caacdf3a82.png

8ba839402e9b090eed0bb483b61a08d.png

三.尾声 安全无小事 使用的依赖，(npm package，甚至是 NodeJS) 可能成为最薄弱的一环。

  • left-pad 事件
  • eslint-scope 事件
  • npm install 除了带来了黑洞，还可以带来漏洞
  • event-stream 事件 保持学习心态

推荐读物

  • Amazon.com: Web Application Security: Exploitationand Countermeasuresfor Modern WebApplications (9781492053118): Hoffman，Andrew: Books
  • SameSite 那些事怡红院落(imnerd.org)
  • 关于 Web 安全突然想到的 · Issue #32 · AngusFu/diary (github.com)
  • What_is_a_DDoS_Attack?
avatar
文章
阅读
粉丝