网络常见安全漏洞(下)| 青训营

390 阅读9分钟

第二节 服务端漏洞

越权漏洞

认证:你是谁?

授权:你能做什么?

越权:资源访问或操作时候主体权限没有进行效验就会造成越权问题,可细分为未授权、水平越权和垂直越权

未授权

系统没有做认证,用户无需登录或访问认证就可以通过拼接Order id的方式查询订单数据即为未授权

image.png

水平越权

用户拥有了直接操作同等级用户账户的数据(如密码和私人信息)的越权即为水平越权

image.png

黑灰产场景: 订单查询功能提供订单id即可查询订单详情,这里攻击者可以遍历orderld获取其他用户的订单信息

防护方式: 涉及资源id尽量不要使用短id (遍历难度较小) ,一定要做好资源属性校验

垂直越权

垂直越权通常只发生在一个账户里,当低权限的用户可以访问高权限数据或执行高权限操作时即为垂直越权

image.png

黑灰产场景: 攻击者可以通过开通另外的测试管理员账户抓包获取接口,或者通过逆向前端代码方式获取实际接口,然后绕过前端直接尝试访问后端接口,获取数据详情

防护方式: 如果是简单的场景,可以将接口在路由级别进行分组,对不同的API分组引入Middleware进行权限拦截,Middleware获取当前用户角色以确定是否可以访问此接口

SSRF

SSRF又称服务端请求伪造攻击,指攻击者利用后端服务器为跳板,让后端服务向非预期网络地址(主要指内网地址)发出恶意请求,获取敏感信息或执行恶意操作。

案例展示:

在查询库存的场景中,服务端请求stockApi,获取结果返回

攻击者可以将stockApi参数改为内网地址,绕过授权访问内网资源

image.png

防护方式: 对url的host进行白名单过滤,获取对host解析的ip进行判定,是否是内网地址

文件上传漏洞

恶意用户可以上传一些服务端脚本(如读取文件的PHP脚本),获取敏感目录下的文件

攻击者找到公开的上传点(如视频创作/文章创作/客服反馈等),上传恶意文件(恶意视频、图片),获取图片url,然后直接分享url至外部恶意网站或QQ/微信群

防护方案:

  1. 限制文件类型:如果系统只需要图片类型,可以从服务端解析文件格式,限制只能传入特定的文件格式。
  2. 站库分离:应用部署的位置和上传的文件分离,一般可以使用TOS、OSs等进行文件存储。
  3. 防止图床:对图片访问链接进行限制,包括时间限制,访问身份限制等。

第三节 服务端漏洞

开放重定向

开放重定向:某些需要重定向到其他站点的功能,往往在参数中携带需要重定向的URL,但实际程序逻辑没有控制好重定向的范围,导致攻击者可以构造恶意链接,诱导用户重定向到恶意站点。

危害:钓鱼攻击。

image.png

修复方案:对重定向严格进行白名单控制并正确校验匹配白名单。

XSS

跨站脚本(XSS)攻击:本质是一种Script代码注入,攻击者往目标Web 页面里插入恶意Script代码,当用户访问页面(有客户端时需要交互)时,嵌入其中 Web 里面的Script 代码会被执行,从而达到恶意攻击用户的目的。

场景:反射型,存储型,Dom型

危害:通常的危害包括窃取用户敏感信息,以用户身份执行敏感操作。

案例展示

前段代码使用了Vue,会从请求path中读取username,同时使用v-html指令将username直接渲染到Dom中,攻击者通过构造特殊用户名,可以执行恶意操作(如下图中的弹窗操作)

image.png

image.png

XSS攻击步骤

Step1:构造恶意链接,将username设置为恶意payload

Step2:攻击者通过网站反馈入口,向管理员/运营人发送恶意链接

Step3:攻击者的服务器成功收到管理员/运营人员的Session Cookie

Step4:浏览器替换cookie为管理员的,获取管理员权限

防护方法:

  1. 输入过滤:对输入的特殊字符进行拦截,禁止前端提交特殊字符
  2. 输出过滤: (a)当字符输出到Dom时候,对危险字符进行html encode,避免XSS (b)使用vue/react等框架时候,避免使用危险指令,而应该使用安全指令
  3. 富文本场景:比如文章发布场景,本身是需要提供富文本功能,这时候需要严格限制tag和attribute,可以在代码层面做白名单或者黑名单。<tag attribute1=’value1’ attribute2=’value2’ />
  4. CSP:用于缓解XSS,理念是对当前站点允许加载什么源的资源、发送什么请求能进行限制。Content-Security-Policy: default-src 'self; img-src *; media-src example.org example.net;script-src userscripts.example.com

CSRF

跨站请求伪造(CSRF):允许攻击者诱导用户访问恶意链接,执行用户非预期执行的操作。

危害:用户执行敏感操作,如关注其他用户,或者更改账号的安全邮箱等。

案例展示

假设系统支持更改邮箱功能,攻击者可以利用CSRF漏洞更改用户邮箱

漏洞利用步骤:

  1. 将更改Email的请求生成CSRF表单,并构造钓鱼链接
  2. 发送链接给其他用户(如在论坛传播钓鱼链接)
  3. 用户点击链接后成功执行email更改操作,用户email被更改为攻击者设定的email

image.png

防护方式:防护的核心是判断请求的来源

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

点击劫持

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

案例展示

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

image.png

漏洞利用步骤:

Step1:参考如下代码构造页面钓鱼链接

Step2:发送链接给其他用户

Step3:用户访问链接,点击 Win 300$ 时候,实际是点击 Delete Account

image.png

image.png

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

  1. X-Frame-Options: DENY/SAMEORIGIN
  2. CSP: frame-ancestors指令,用于设置允许frame的source列表 Content-Security-Policy: frame-ancestors < space separaated list of sources>; Content-Security-Policy: frame-ancestors 'self' <https://example.org> https://example.com  https://store.example.com

CORS跨域配置错误

CORS:全称是“跨域资源共享”(Cross-origin resource sharing),用以解决网页应用跨域访问的需求

image.png

浏览器在请求中自动带上Origin,服务端判断Origin合法性,是否允许访问

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

常见几种错误配置(以需要跨域访问example.com所有子域名为例):

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

案例展示

案例场景:网站个人信息也提供查看个人信息功能,相关接口允许宽域访问且存在配置问题。此网站使用反射方式,恶意用户可以直接通过钓鱼链接获取接口信息并获取其他用户个人信息

image.png

利用思路:

Step1:构造钓鱼页面URL

image.png

Step2:在钓鱼页面后台监控访问日志,发现受害者成功点击了钓鱼页面,并且将accountDetail信息回传

image.png

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

  1. 代码层:Middleware统一处理
  2. 网关层:Nginx反代统一处理拦截处理

WebSocket

WebSocket区别于http,只是不同的交互协议,本质上http服务端的漏洞,在WebSocket上也可能存在。因此重点讨论WebSocket架构的一些问题

  1. WSS和WS:WSS(WebSockets over SSL/TLS),提供加密信息。杜绝掉一些中间人攻击

  2. 数据效验:SQL/XSS/RCE等漏洞任然可能存在

  3. CSWSH:Cross-Site WebSocket Hijacking, 即在使用cookie作为认证方式时候,如果WebSocket没有校验好请求来源(Origin),将导致WebSocket会话劫持

案例展示

黑户设置钓鱼页面,用户一旦访问后,用户WebSocket会话就可能会被监听 image.png

如果没有在服务端做Origin限制,WebSocket则会默认带上cookie,攻击者可以通过钓鱼页面从点击用户发起会话请求并监听敏感信息

CSWSH防护手段:

  1. Cookie鉴权:限制请求的Origin

image.png

  1. ticket/token鉴权:http服务提供端口,用于获取临时的身份凭证,并传递到WebSocket的初始化化流程中

image.png