Web开发安全问题 | 青训营笔记

ydcgye
127 阅读7分钟

这是我参与「第四届青训营 」笔记创作活动的的第10天

Web开发的安全

一、攻击者角度

1.XSS攻击

由于程序盲目信任用户提交内容，且未进行任何信息过滤导致

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

1. Stored XSS

  • 恶意脚本被存在数据库中
  • 访问页面 -> 读数据 ===被攻击
  • 危害最大，对全部用户可见 若没有对用户提交信息进行过滤，则可能导致恶意数据被存储

2. Reflected XSS

  • 不涉及数据库
  • 从 URL 上攻击 修改URL地址上的代码片段，当用户访问时，将会被攻击

3. DOM-based XSS

  • 不需要服务器的参与
  • 恶意的攻击发起+执行，全在浏览器完成 与第二类反射型的XSS攻击相似，但不同的是反射型攻击在 server 服务端进行注入，而 DOM-based XSS 是由浏览器进行

4. Mutation-based XSS

  • 利用了浏览器渲染 DOM 的特性（独特优化）
  • 不同浏览器，会有区别（按浏览器进行区别攻击） 攻击者利用浏览器渲染机制，巧妙注入恶意脚本。最难防御

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

   用户不知情的前提下，利用用户权限(cookie)，构造指定 HTTP 请求，窃取或修改用户敏感信息
常见方法：get请求方式，构造a，img标签等

3.Injection注入攻击

  • 最常见：SQL Injection，其攻击流程：
    1. SQL 参数（恶意注入）在 HTTP 请求中
    2. 服务器端在 HTTP 请求上读取并允许 sql 语句
    3. 攻击者即可获取、修改、删除数据等
  • CLI 命令行
  • OS command 系统命令
  • Server-Side Request Forgery(SSRF) 服务端伪装请求，但严格来说,SSRF并非injectio，但原理相似

4.Denial of Service(DoS) 服务拒绝

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

ReDoS：基于正则表达式的 DoS
利用贪婪模式，不断回溯的行为。攻击者会恶意注入易于发生回溯行为的字符串，结果将导致服务器响应时间延长，吞吐量降低，响应用户请求速度下降

5.Distributed DoS(DDoS)攻击

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

  • 直接访问 IP，不限制于域名访问
  • 任意 API 均可，不会区分
  • 主要在消耗大量带宽
    在 TCP 协议三次握手中，攻击者将发送大量 SYN,当服务器按规范返回 ACK+SYN 时，攻击者不会返回第三次 ACY，导致无法完成三次握手，连接数无法释放，进而达到服务器最大连接数，无法响应新请求。

6.中间人攻击

中间人插入在浏览器与服务器之间，窃取其相互传递的信息。其扮演角色多变，如：恶意浏览器，路由器，运营商。 为什么会发生？

  • 传递时为明文传输
  • 学习篡改时不可知
  • 对方身份未验证

二、防御者角度

1.XSS攻击

  • 不要相信用户提交的内容
  • 不要将用户提交内容直接转换为 DOM
  • 将提交内容当作字符串对待
    防御工具：
    在前端，主流框架，如 Vue，React 等默认防御 XSS 攻击。Google 提供的 google-closure-library 也提供了许多防御函数

将string->DOM时注意：
1. 需对 string 进行转义
2. 若允许 SVG 上传，也需对 SVG 进行扫描，防止恶意script标签加载
3. 尽量避免用户自定义跳转行为，若使用也要过滤

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

允许开发者去定义哪些源（域名）被认为是安全的。安全源的脚背可执行，否则报错。对eval+inline脚本直接拒绝。
利用同源策略，同源即协议、域名、端口一致。对于HTTP请求，同源则运行，跨域则需要看服务器设置

3.CSRF跨站伪造请求防御

跨域请求攻击的本质是利用 cookie 会携带，最简单的保护手段就是不使用 cookie，改成 html 储存，比如 localstorage 等，然后前后自行维护一套类似 cookie 的过期逻辑。

  • 可尝试限制请求来源，即限制伪造请求。
    • 如判断请求域名，浏览器每次 http 请求会携带两 header 字段，对Origin或Referer进行校验，同域名则放行，否则拒绝
    • Origin表述请求的源，只有协议、域名和端口
    • Referer表述请求的url，会包含全部的路径
    • 源的校验只能作为辅佐手段，而不是最终判定，因为 Origin 字段在各大浏览器中曾经不断暴露过很多漏洞，所以不能严格依赖
  • 除了Origin和Referer，还有几种方法判断请求是否来自合法来源：
    • 对来自合法页面的请求进行标识
    • token防御机制，即服务器返回页面时携带token给用户，当用户请求API时需验证用户的token，通过则响应
      • 本质上替代了校验源 origin 的作用，由我们自己生成和控制
      • 不能保存在cookie
      • token与具体用户绑定，防止攻击者为合法用户
      • token需要有过期时间，防止用户token被窃取
    • 随机cookie验证
      • SOP不会阻止 cookie 跨域发送，但是会阻止 cookie 获取。利用这点特性，为每次请求返还一个随机的值设置在 cookie 中，下一次请求的时候，把这个值用 js 从 cookie 中取出来，拼接到参数中，后台在收到接口时，先校验这个参数。即可判定是不是可信任的源。 由于在第三方源无法用 js 取出这个随机值，那么由它发起的请求自然也会被过滤掉。
    • 面对iframe攻击（在同源中完成）
      • 可以设置X-Frame-Options响应头部
      • DENY(当前页面不能作为iframe加载)
      • SAMEORIGIN(必须为同源页面才能加载)

4.SameSite Cookie防御请求

CSRF 的根源在 cookie 可以被跨域发送。为了避免用户信息被携带，防止自己的cookie被获取，而提出了该防御请求

限制的是：

  • ①Cookie domain
  • ②页面域名（仅第一方cookie成功） 但对于依赖cookie的第三方服务，浏览器端也可对安全的第三方cookie进行标记
Set-Cookie:SameSite=None;Secure;

5.Injection

  • Injection SQL攻击防御：
    • 做到代码中查询SQL的地方
    • 使用 prepared statement，将sql语句提前编译，使得恶意程序无法编译执行
  • 最小权限原则
    • 所有命令不要通过sudo执行，不要赋予root权限
  • 建立运行名单+过滤
    • 只允许指定命令执行
  • 对URL类型参数进行协议、域名、IP等限制
    • 避免攻击者访问内网资源

6.防御Regex DoS

  • 避免贪婪匹配方式，特别是处理接口相关操作
  • 使用代码扫描工具，对代码中正则表达式进行性能测试
  • 直接拒绝用户提供的使用正则（根本方法）

7.DDoS

  1. 过滤
  • 流量治理
    • 负载均衡
    • API网关层，流量识别是否异常
  1. 抗量
  • 所有流量都要经过CDN，才能得到具体服务
  • 快速自动扩容，承载更多流量
  • 非核心服务降级

8.防御中间人

HTTPS的特性：

  • 可靠性：加密，避免明文传输
  • 完整性：MA验证，避免信息篡改
  • 不可抵赖性：数字签名，验证双方身份

总结

   前端安全主要来源两个方面，一个是不安全的脚本,另一个是不安全的请求。前者代表各种 XSS 等注入脚本的手段、后者则发起非法的请求，CSRF 是代表。
   同源策略SOP是web的安全基石，在同源下cookie\html5储存等资源是可以共享的，其核心是保护属于某个源的资源不被其他源读取，它们彼此独立。即跨域访问的话是“可写不可读”，因此也常常造成出现其他源的非法请求。
   SOP只服务于源的数据隔离，对请求不做任何限制，甚至跨域时cookie携带也不做限制
   对于开发者而言，要对此十分警惕，不要信任任何用户提交的内容、其他第三方源。用默认拒绝的心态处理一切安全问题，保护好自己。

avatar
文章
阅读
粉丝