08月12, 2019

几种接触甚少却常见的 web 漏洞

最近有机会阅读了某甲方公司收到的渗透测试报告,总共50多份,对真实场景容易出现的漏洞有了大致的了解。

毕竟是报告,对于渗透思路的记录甚少。但是通过学习报告中列举的漏洞,我还是收获了不少东西。

这篇文章记录一下自己接触不多,却在真实场景比较常见的一些 web 漏洞。


HOST 头攻击

某些场景下,服务端的应用程序使用了客户端提交的 HTTP 请求中的 Host 字段,而客户端可以控制该字段的内容。

服务端根据 Host 字段获取域名,然后进行业务的处理,导致此漏洞产生。

报告中出现较多的是重定向目标地址的伪造,个人认为这个漏洞无法利用,并没有什么危害。

危害较大的场景其实比较少,如重置密码邮件中的链接伪造。


JSONP 劫持

由于同源策略的存在,浏览器会限制 JS 获取跨域请求的响应内容。

JSONP 是一种用于跨域获取数据的技术,主要利用<script>标签里的src属性指向提供跨域资源的服务端地址。

而服务端返回:

函数名(JSON 数据)

该函数在前端已被定义,故服务端返回的内容会作为代码被执行,如此便实现了跨域获取数据。

通常情况下,后端会认证请求包的 Cookie 信息,然后再做出响应。

如此便产生了一个 CSRF 的可能,攻击者在知道响应函数名的情况下(通常返回的函数名是由跨域请求决定的),可以构建一个恶意的网页,该网页具有同名的 JS 函数用来获取并转发数据。

当受害者访问恶意页面时,由于其浏览器已有跨域网站的 Cookie,导致<script>标签成功跨域加载 JSON 数据,执行恶意函数,造成数据泄漏。

JSONP 的防范方式大致与 CSRF 的防范方式相同,应该严格校验 Referer 或使用 csrf-token(通过 GET 方式发送 token)。


CORS 跨域资源共享漏洞

CORS 与上面的 JSONP 作用相似,也用于跨域获取数据。

关于 CORS 协议的具体内容就不提了,这个漏洞产生的主要原因是服务端的配置不当。

服务端通过设置如下请求头,来指定允许请求的域:

Access-Control-Allow-Origin: http://example.com

若发起请求的域不在服务端允许的范围内,浏览器会屏蔽响应包。

如下请求头,来设定是否允许请求包携带 Cookie:

Access-Control-Allow-Credentials: true

出于安全考虑,CORS 协议有一个特殊限制,服务端不能在既允许所有请求域的情况下,又同时允许请求包携带 Cookie。

即下面的响应头不合法:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

浏览器看到这样的响应头,会对其进行屏蔽处理。

所以当服务器允许所有域的请求时,对 Cookie 进行校验即可保证 CORS 的安全性。

但是,在某些场景下,服务端返回的Access-Control-Allow-Origin的值是客户端请求头中Origin的值。

比如,请求头中Origin的值为http://evil.com,服务端返回如下相应头:

Access-Control-Allow-Origin: http://evil.com
Access-Control-Allow-Credentials: true

如此即可造成一个 CSRF 攻击,攻击者可构造一个恶意网页,跨域请求目标站点下的数据,造成数据泄漏。


会话固定

大多数网站都会使用 Session 来记录用户的登录状态。

某些场景下,用户登录前后的 Session ID 不发生变化,则有可能造成一种潜在的攻击手段。

步骤如下:

1、攻击者先访问站点的登录页面,取得 Session ID = abc。

2、攻击者诱使受害者访问下面链接:

http://example.com/login?sessionid=abc

3、受害者输入账号密码并成功登录。

4、攻击者使用原本的 Session ID 即可登录受害者的账号。

正常情况下,服务端应该严格从 Cookie 中取出 Session ID,这样便无法进行上述攻击。

但是在某些场景下,比如 PHP,程序员使用:

sessionid = $_REQUEST['sessionid'];

导致 GET 方式提交的 Session ID 也被认可了,上述攻击便可实现。

登录成功后重置会话,并严格从 Cookie 中取出 Session ID,即可防范此种攻击。

本文链接:https://blog.cindemor.com/post/vuln-not-known.html

-- EOF --