【Web开发的安全之旅】|青训营笔记06

加油的小白
121 阅读5分钟

这是我参加【第四届青训营】笔记创作活动的第7天

两个角度看web安全

  • 假如你是一个hacker——攻击

  • 假如你是一个开发者——防御

一、攻击篇

1.跨站脚本攻击（XSS）

image.png 在开发维度的页面攻击者通过某种方式把它的恶意脚本注入进来

image.png

1.1 XSS的一些特点

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

XSS demo

image.png

可以直接提交恶意脚本

image.png

1.2 XSS攻击

①存储型XSS攻击——Stored XSS

当用户访问页面时，涉及到用户端读取数据，写数据给浏览器，只要完成这个链路用户就会被攻击，危害最大。

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

image.png

②反射型XSS攻击——Reflected XSS

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

Reflected XSS Demo

image.png

③ DOM——based XSS

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

DOM——based XSS Demo

image.png

Reflected vs DOM——based

完成注入脚本的地方：

Reflected——服务端
DOM—baesd——浏览器

image.png

Mutation——based XSS

  • 利用了浏览器渲染DOM的特性（独特优化）
  • 不同浏览器，会有区别（按浏览器进行攻击）

image.png

2.跨站伪造请求Cross—site request forgery(CSRF）

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

CSRF demo

image.png

CSRF——GET

image.png

CSRF——beyond GET

image.png

3.SQL Injection

image.png

Injection demo 1

①读取请求字段

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

image.png

image.png

Injection 不止于SQL

  • CLI
  • OS command
  • Server—Side Resquest Forgery（SSRF），服务端伪造请求
    • 严格而言，SSRF不是Injection,但是原理相似

Injection demo 2——执行

image.png 攻击者把options传入一个系统命令，服务端执行命令的时候，就会把服务器端的若干文件直接删除，导致服务器宕机 image.png

Injection demo 2——读取+修改

image.png

SSRF demo

 - 请求【用户自定义】的callback URL
 - web server 通常有内网访问权限

image.png

4.Denial of Service（DOS服务拒绝)

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

插播：正则表达式——贪婪模式

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

image.png

4.1 ReDoS：基于正则表达式的DoS

贪婪：n次不行？n-1次再试试？——回溯

image.png

4.2 Distributed DoS（DDoS）

短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。

【不搞复杂的，量大就完事儿了】

攻击特点：

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

DDoS demo

image.png

5.传输层

5.1 中间人攻击

  • 明文传输
  • 信息篡改不可知
  • 对方身份未验证

在浏览器中间插一个，浏览器觉得在和服务器沟通，服务器觉得在给浏览器访问数据，实际是中间人在操作。

image.png

二、防御篇

1.XSS

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

image.png

1.1 防止XSS的现成工具

前端

  • 主流框架默认防御XSS
  • google——closure——library

服务端（Node）

  • DOMPurify

XSS——耗子尾汁

但是，如果【用户需求】不讲武德，必须动态生成DOM

①string→DOM

如果要把string直接生成DOM，这时候需要对string进行转移

image.png

②上传svg

如果允许用户上传svg文件（例如图片），也要对svg文件进行一次扫描，因为按照规范svg文件中可以插入script标签，那么如果svg文件被加载，script会执行，完成一次XS攻击

image.png

③自定义跳转链接

尽量不要做让用户自定以跳转链接的行为，如果做了，也一定要做好过滤，因为如果允许自定义跳转链接的话 ，实际上可以传递js代码

image.png

如果允许用户自定义样式的话，也可能导致xss攻击

插播：Same—origin Policy同源策略

image.png

2.Content Security Policy（CSP内容安全策略)

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

image.png

从域名限制哪些脚本可以攻击，那么恶意脚本难以完成攻击。

3.CSRF的防御

image.png

3.1 CSRF——token

image.png

image.png

3.2 CSRF——iframe 攻击

用户点击button标签的时候，由于用户设置了CSS属性，导致点击行为被穿越到线框的iframe之中，iframe之中可能受到了点击而发送http请求，而iframe之中发生了同源请求（不是跨域请求），那么对应的攻击也就完成了 image.png

3.3 CSRF anti—pattern

GET!==GET+POST

image.png

3.4避免用户信息被携带：SameSite Cookie

image.png

image.png

限制的是：

①Cookie domain

②页面域名

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

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

image.png

SameSite vs CORS

①.SameSite

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

②.CORS

  • 资源读写（HTTP请求）
  • 资源域名 vs 页面域名
  • 白名单

3.5防御CSRF的正确姿势

Case by case 防御？🙅‍ 作一个中间件，专门去生成各种防御CSS的策略，保证整个webapp都能完成CSRF的防御

4.Injection（注入相关的防御）

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

image.png

Injection beyond SQL

  • 最小权限原则
    • 🙅‍sudo||root
  • 建立允许名单+过滤
    • 🙅‍rm
  • 对URL类型参数新型协议、域名、IP等限制
    • 🙅‍访问内网

5.Regex DoS

  • Code Revriew（❌/（ab*）+/）
  • 代码扫描+正则性能测试
  • ❌用户提供的使用正则

6.DDoS

image.png

7.传输层——防御中间人

image.png

7.1 HTTPS的一些特性

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

image.png

①HTTPS——完整性

image.png

②插播：数字签名

image.png

③HTTPS——不可抵赖：数字签名

image.png

image.png

image.png

7.2 HTTP Strict—Transport—Security（HSTS）

image.png

7.3 Subresource Integrity（SRI）

image.png

SRI——demo

标签hash9原始内容hash） vs 实际内容hsah

image.png

👀

image.png

总结：

本节课从攻击篇和防御篇两个角度学习了关于web开发的安全之旅，受益匪浅。

avatar
文章
阅读
粉丝