从CSRF到用户信息泄漏，XSS和完整账户接管

0x00前言

CSRF漏洞的严重性在很大程度上取决于漏洞的位置。有时，错误的CSRF保护机制会致使可有可无的问题，例如未经受权的设置更改或清空用户的购物车。有时，它们会致使更大的问题：用户信息泄漏，XSS甚至一键式账户接管。

我在CSRF中遇到了一些致使严重安全问题的案例。一般，这些是CSRF和其余较小的设计缺陷的组合。

0x01 CSRF泄漏用户信息

CSRF有时会致使信息泄漏。应用程序常常根据用户偏好发送或公开信息。若是这些设置端点没有受到CSRF的保护，则能够为敏感信息公开铺平道路。实现基于CSRF的信息泄漏的一种方法是处理这些请求。

例如，我曾经使用过的Web应用程序上的付费服务将每个月的计费电子邮件发送到用户指定的电子邮件地址。这些电子邮件包括用户的街道地址，电话号码和有限的信用卡信息。能够经过如下请求更改发送这些计费电子邮件的电子邮件地址：

POST /change_billing_email

REQUEST BODY:

email=NEW_EMAIL &csrftok=12345

在此端点上的CSRF验证已损坏。服务器接受空白令牌，即便csrftok字段为空，请求也将成功。在使受害者发送如下请求后，全部之后的帐单电子邮件都将发送到ATTACKER_EMAIL（直到受害者注意到未经受权的更改），从而将与该账户关联的街道地址和电话号码泄露给***者。

POST /change_billing_email

REQUEST BODY:

email=ATTACKER_EMAIL &csrftok=

0x02使用CSRF存储的Self-XSS

安全团队几乎老是将Self-XSS视为非问题，由于它们难以利用。可是，与CSRF结合XSS使用时，自身XSS一般能够变成存储的XSS。

例如，在我遇到的一个金融网站上，用户能够为每一个连接的银行账户建立昵称。账户昵称字段容易受到XSS的***：该字段上的用户输入不进行清理，验证或转义。可是，这是只有受权用户才能编辑和查看的字段，所以***者没法直接触发XSS。

不幸的是，用于更改账户昵称的终结点计算机上也存在CSRF错误。该应用程序未正确验证CSRF令牌的存在，所以仅在请求中省略令牌参数将绕过CSRF保护。例如：

POST /change_account_nickname

REQUEST BODY:

nickname=<XSS PAYLOAD> &csrftok=WRONG_TOKEN

该请求将失败。

POST /change_account_nickname

REQUEST BODY:

nickname=<XSS PAYLOAD>

虽然此请求将成功更改用户的账户昵称，并存储XSS有效负载。下次用户登陆账户并查看其仪表板时，将触发XSS。

0x03使用CSRF接管用户账户

这些是我发现的一些最简单的账户接管。这些状况也很多见。当账户验证功能（如建立密码，更改密码，更改电子邮件地址或重置密码）中存在CSRF问题时，就会发生账户接管问题。

例如，这是我在客户端的Web应用程序中发现的错误。

该网络应用程序容许社交媒体注册。用户经过社交媒体注册后，他们能够选择经过如下请求设置密码：

POST /password_change

REQUEST BODY:

oldpassword= &newpassword=XXXXX &csrftok=12345

因为用户经过其社交媒体账户注册，所以不须要旧密码便可设置新密码。所以，若是CSRF保护在此终结点上失败，***者将可以为经过其社交媒体账户注册但未设置密码的任何人设置密码。

不幸的是，这正是在此特定端点上发生的事情。应用程序没法正确验证CSRF令牌，并接受一个空值做为csrftok参数。所以，从本质上讲，如下请求会将任何人（还没有设置密码）的密码设置为ATTACKER_PASS。

POST /password_change

REQUEST BODY:

oldpassword= &newpassword=ATTACKER_PASS &csrftok=

如今，***者所须要作的就是将该请求嵌入到网站用户常常访问的页面上，而且她能够将访问这些页面的任何用户的密码自动分配给ATTACKER_PASS。以后，***者可使用新分配的密码自由做为任何受害者登陆。

0x04总结

CSRF很是广泛，很是容易利用。虽然我遇到的大多数CSRF都是低严重性问题，但有时对关键端点进行监督可能会致使严重后果。

若是您是开发人员，请特别注意部署在关键端点上的CSRF保护机制。