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

爱困的猫cat
93 阅读4分钟

这是我参加「第四届青训营 」笔记创作活动的第五天。 本次课程从两个角度看待了web安全问题：攻击者、防御者

1.攻击

1.1Cross-Site Scripting（XSS)跨站脚本攻击

可能会导致用户隐私泄露 作为开发者盲目的信任用户提交的内容。比如将用户提交的字符串转换为了DOM,会造成XSS攻击。

1.1.1 特点

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

1.1.2 分类

1.1.2.1 存储型：Stored XSS

  • 恶意脚本被存在数据库中

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

  • 对全部用户可见（危害最大）

       比如一个视频网站存在XSS漏洞，在上传视频时插入XSS恶意脚本，当其他用户观看此视频时，信息可能就会被暴露。

1.1.2.2 反射性型：Reflected XSS（服务端）

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

1.1.2.3 DOM：DOM-based XSS（浏览器）

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

1.1.2.4 Mutation-based XSS（浏览器）

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

1.2 Cross-site request forgery(CSRF)跨站伪造请求

  • 在用户不知情的前提下

  • 利用用户权限(cookie)

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

    比如用户收到一封邮件有链接，点击进去之后，访问一个恶意页面，攻击者构造了一个HTTP请求，比如向银行进行转账，而这个请求在另外一个页面，银行有cooiek且通过，就会执行转账接口，用户就会丢失财产。构造HTTP表单即可。

1.3 注入Injection

1.3.1 SQL Injection

假如有一个HTTP请求，SQL参数在请求上载入，然后这段请求载入服务器端，从HTTP上读取参数，构造一个SQL语句，然后运行SQL代码，被执行后导致信息泄露、删除或者修改。

image.png

1.3.2 CLI

1.3.3 OS command

1.3.4 Server-Side Request Forgery(SSRF)，服务端伪造请求

严格而言，SSRF不是injection, 但是原理类似

1.3.5 Denial of Service(DoS)

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

ByteDance

1.3.6 Distributed DoS(DDoS)

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

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

1.3.7中间人攻击

在浏览器和服务器中间，中间人可以窃取、修改信息，中间人可以是恶意浏览器、路由器等。 为什么中间人这种形式会发生呢？ ①明文传输 ②信息篡改不可知 ③对方身份未验证

2 防御

2.1 XSS

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

防御XSS攻击工具：

前端：主流框架（Vue，React）默认防御XSS
一google-closure-library
服务端(Node)
- DOMPurify

当有用户需求，需要动态生成DOM，我们需要注意以下几点：

string->DOM需要将string进行转义
上传svg文件，需要扫描
尽量不要做自定义跳转链接
自定义样式

2.2插播：Sanme-origin Policy 同源策略

协议、域名、端口相等

2.3 Content Security Policy(CSP)内容安全策略

开发者确定哪些源是安全的，安全源的脚本可以执行否则报错

2.4 CSRF的防御

image.png

image.png

2.5 SanmeSite Cookie避免用户信息被携带

有一个页面对应的cookie是A，则所有domain属性是A的cookie为第一方Cookie，其他的为第三方Cookie。向域名A发送请求时第一方的Cookie被成功带上，第三方不会带给域名A 的服务器（默认行为）

如果依赖第三方Cookie

image.png

image.png

2.6注入防御

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

2.7其他注入

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

2.8防御Dos

  • 避免写贪婪模式
  • 代码扫描+正则性能测试
  • 拒绝用户提供的使用正则

2.9 DDoS

image.png

2.10防御层

HTTPS

  • 可靠性:加密，避免明文传输
  • 完整性: MAC验证，没有被篡改
  • 不可抵赖性:数字签名，身份认证

2.11 SRI

静态资源被劫持篡改，在script标签上添加integrity属性（hash）

3总结

开发安全是必须的，在开发安全上还有许多更深的内涵，需要进一步了解。

avatar
文章
阅读
粉丝