网站常见安全漏洞-客户端漏洞 | 青训营

SyntaxSugar
37 阅读7分钟

开放重定向

例如

淘宝登录以后跳转到之前访问的商品的链接

抖音登录以后跳转到之前访问的视频

本质上都是重定向，能够记住你之前访问的链接，并在你完成某个操作以后重定向到这个链接里面去。但如果重定向的链接是外部可控而且没有做好限制就会导致一些安全风险

  • 开放重定向：某些需要重定向到其它站点的功能，往往在参数中携带需要重定向的URL，但实际程序逻辑没有控制好重定向的范围，导致攻击者可以构造恶意链接，诱导用户重定向到恶意网站。
  • 危害：钓鱼攻击
  • 修复方案：对重定向严格进行白名单控制并正确匹配白名单

比如 example.com 是一个可信的网站，如果重定向到恶意站点，就会对网站用户带来不良影响。

https://www.example.com/redirect?url=https://evil.com

XSS

跨站脚本（XSS）攻击，本质是一种Script代码注入，攻击者往目标Web页面里植入恶意script代码。当有用户访问页面（有客户端需要交互）时，嵌入其中 Web 里面的 Script 代码会被执行，从而达到恶意攻击用户的目的 场景：反射型，存储型，DOM型 危害：通常的危害包括窃取用户敏感信息，以用户身份执行敏感操作。

不如前端代码使用 Vue，会从 path 中读取 username，同时使用v-html指令将 username 直接渲染到 DOM 中

比如一段窃取Cookie并发送到攻击者服务器的恶意代码放到网站评论等地方，可能导致访问页面所有的用户的Cookie被窃取

前端任何有用户输入或外部可控的地方，都要进行注意。

  • Step1: 构造恶意链接，将 username 设置为payload
  • Step2: 攻击者通过网站反馈入口，向管理员/运营人员发送恶意链接
  • Step3: 攻击者的服务器成功收到管理员/运营人员的Session Cookie
  • Step4: 浏览器替换 cookie 为管理员的，获取管理员权限

管理员可能会在后台管理面板看到恶意用户的 username，如果管理员的系统是对外的，这样就可以访问到管理员的 Session Cookie，如果不对外，可以访问到一些内部接口，再发送到外部服务器

防护方案

  1. 输入过滤：对输入的特殊字符进行拦截，禁止前端提交特殊字符
  2. 输出过滤：a. 当字符串输出到 DOM 是，对危险字符进行 html encode，避免 xss b. 使用vue/react等框架时，避免使用危险指令，而应该使用安全指令（v-html/v-text）
  3. 富文本场景：比如文章发布场景，本身是需要提供富文本功能，这时候需要严格限制tag和attribute，可以在代码层面做白名单或者黑名单
  4. CSP：用户缓解XSS，理念是对当前粘点允许加载什么源的资源，发送什么请求进行限制（避免XSS加载恶意资源或者把窃取数据发送到外部）。

Content-Security-Policy: default-src 'self'; img-src *; media-src example.orgh example.net; script-src userscripts.example.com

设计，实现和代码上线后防护。

有时候输入过滤输出过滤可能造成业务误伤，比如不适合富文本场景

CSRF

跨站请求伪造（CSRF）：允许攻击者访问恶意链接，执行用户非预期的操作。 危害：用户执行敏感操作，如关注其它用户，或者更改账号的安全邮箱等。

假设你的系统设计了更改安全邮箱的功能，传入一个emailchange url，跟了你控制的email邮箱，假设攻击者把email改成自己的，把链接放在公开的位置，不知不觉改变了自己的邮箱。

漏洞利用步骤： step1：将更改Email的请求生成CSRF表单，并构造钓鱼链接 step2：发送链接给其它用户 step3：用户点击链接后执行email更改操作

防护方式：防护的核心时判断请求的来源

  1. CSRF tokens：首次访问的时候给客户端传递一个token，客户端每次访问时候都必须带上此token才能访问
  2. SameSite cookies：Strick -> Lax(Default) -> None 核心是禁止某些场景发送第三方 cookie（有的时候会导致第三方无法分析）
  3. Referer-based validation: 校验Referer 来源是否是合法站点

Refer请求头是浏览器的行为，是客户端无法控制的，所以是可信的

点击劫持

点击劫持（clickjacking）是一种在网页中将恶意代码等应藏在看似无害或者诱导的内容（如按钮之下）并诱使用户点击的手段，用户点击后往往会执行一些非预期的操作。

漏洞场景：考虑如下删除账号功能，如果目标站点的CSRF防护做的很到位，无法直接构造CSRF钓鱼页面，这时候可以考虑在钓鱼页面iframe原始页面，并覆盖一层诱导性文字。

step1：构造钓鱼页面链接 step2：发送链接给其它用户 step3：用户访问链接，点击 win 300$ 的时候，实际上是点击 Delete Account

防护方式：防护的核心是不让非预期的网站 iframe 我的站点

  1. X-Frame-Option: DENY / SAMEORIGIN
  2. CSP: frame-ancestors指令，用于设置允许frame的source列表 Content-Security-Policy: frame-ancestors ; Content-Security-Policy: frame-ancestors 'self' example.org example.com store.example.com

CSP配置允许一些白名单，可以做细粒度的控制

CORS 跨域配置错误

CORS：全称是“跨域资源共享”（Cross-origin resource sharing），用以解决网页应用的跨域问题。

CORS 错误配置：CORS本身不存在漏洞。而是由于开发者在配置CORS过程中，错误配置跨域访问 Allow List，导致非预期的站点可以进行跨域访问，最终可能导致信息泄露。

常见几种错误配置： 以需要跨域访问 example.org 所有子域名为例

  1. 前缀/后缀/包含/正则匹配：可用example.com.attack.com、attackexample.com、attackexample.com 域名绕过
  2. 反射：在Access-Control-Allow-Origin中反射请求的Origin值（即信任从前端拿到的origin），理论上可以用任意域名绕过
  3. 信任null：攻击者还可以从任意域下通过iframe sandbox构造Origin为null的跨域请求
  4. https信任http：http传输存在被劫持篡改可能，攻击者可能通过劫持通信流量植入恶意脚本方式窃取敏感信息。

返回 Access-Control-Allow-Origin 没有做好限制，导致攻击者可以绕过跨源限制，使用不信任的源发起请求。

防护方式：核心是正确设置跨域白名单

  1. 代码层：Middleware统一处理

  2. 网关层：Nginx反代统一处理

WebSocket （聊天场景）

区别与http，只是不同的交互协议，本质上http服务端的漏洞，在WebSocket上也可能存在，这里讨论WebSocket本身的一些问题

  1. WSS和 WS：WSS（Web Socket over SSL/TLS）提供加密信道，杜绝掉一些中间人攻击
  2. 数据校验：SQL/XSS/RCE等漏洞仍然可能存在
  3. CSWSH：Cross-Site WebSokcet Hijacking，记载使用cookie作为认证方式的时候，如果 WebSocket客户端没有校验好请求来源（Origin），将导致 WebSocket 会话被劫持

黑产设置钓鱼页面，用户一旦访问后，用户 WebSocket 绘画就可能会被监听。

防护手段：

  1. Cookie 鉴权：限制请求的Origin
  2. ticket/token 鉴权：http服务提供接口，用于获取临时的身份凭证，并传递到WebSocket的初始化流程中。（建立websocket时，从authcenter获取token再发送请求，由于浏览器同源策略，getWssToken是不能跨域调用成功的，攻击者无法获取token，无法伪造身份）

image.png

avatar
文章
阅读
粉丝