Web开发安全（防御篇）| 青训营笔记

Desain
82 阅读3分钟

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

XSS

方案：

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

现成工具：

前端：

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

服务端(Node)：

  • ○DOMPurify

CSRF

同源政策

浏览器的同源政策： A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。

所谓"同源"指的是"三个相同"：

  • 协议相同
  • 域名相同
  • 端口相同

同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

CSP

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

  • 决定好哪些源(域名)是安全的
  • 来自安全源的脚本可以执行，否则直接报错
  • 对于eval / inline script 直接禁止

两种形式：

  • 服务器的响应头部：

image.png

  • 浏览器meta

image.png

CSRF防御(token)

  • 验证 HTTP Referer 字段
  • 在请求地址中添加 token 并验证
  • 在 HTTP 头中自定义属性并验证

SameSite Cookie

避免用户信息被携带
Cookie的SameSite属性用来限制第三方Cookie，从而减少安全风险。
可以设置成三个值：

  • Strict：最严格。完全禁止第三方Cookie，跨站点时，任何情况都不会发送Cookie
  • Lax：大多数情况不发送第三方Cookie，但是导航到目标地址的GET请求会发送。
  • None：显示关闭SameSite属性。前提是需要同时设置Secure属性(Cookie只能通过HTTPS协议发送)，否则无效

导航到目标地址的GET请求：链接、预加载、GET表单

设置了Strict或Lax之后，基本杜绝了CSRF攻击。
应用场景是依赖Cookie的第三方服务：如网站内嵌其他网站的播放器，开启SameSite属性后，就识别不了用户的登录态，也就发不了弹幕了。

Injection

使用prepare Statement对象防止sql注入。

prepare Statement对象能把用户非法输入的单引号用\反斜杠做了转义，从而达到了防止sql注入的目的。

Dos

ReDoS

  • Review代码，拒绝写出类似/(ab*)+/贪婪的匹配正则表达式
  • 代码扫描 + 正则性能测试
  • 拒绝使用用户提供的正则

DDoS

  1. 采用高性能的网络设备
  2. 尽量避免NAT的使用
  3. 充足的网络带宽保证
  4. 升级主机服务器硬件

网络层的 DDoS 攻击究其本质其实是无法防御的，我们能做就是不断优化服务本身部署的网络架构，以及提升网络带宽。

应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。

  • 应用层的防御有时比网络层的更难，因为导致应用层被 DDoS攻击的因素非常多，有时往往是因为程序员的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。

  • 而应用层 DDoS防御的核心就是区分人与机器(爬虫)，因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。

防御中间人攻击

使用HTTPS代替HTTP协议

HTTPS的一些特性：

  • 可靠性：加密(非明文)
  • 完整性：MAC验证(防篡改)，通过hash算法来实现，所以就算只有很小的改变，hash输出结果也会变化很大
  • 不可抵赖性：数字签名(确定身份)
avatar
文章
阅读
粉丝