本文讲述了关于微软在线调查创建应用Microsoft forms的一个漏洞，通过其中的数据分享机制，作者可以藉机获取到参与调查用户的邮箱信息，漏洞最终收获了$2k的奖励。微软的Office365有很多服务，其中的Microsoft Forms以OData数据协议方式实现在线的调查测验创建，并能把相关调查结果数据分享给其他用户。

OData协议介绍

开放数据协议（Open Data Protocol，简称OData）是一种描述如何创建和访问Restful服务的OASIS标准。该标准由微软发起 ，前三个版本1.0、2.0、3.0都是微软开放标准，遵循微软开放规范承诺书（Microsoft Open Specification Promise）。第四个版本4.0于2014年3月17日在OASIS投票通过成为开放行业标准。OData协议是一种通过Restful交互的应用层数据协议，它支持数据模型的描述、编辑和请求，其基于SQL理念，不管客户端和数据源的具体类型，都能按照客户端请求响应返回相关数据。OData的数据交互模型如下：

简单来说，OData元数据是系统（如关系数据库中的information_schema）的数据模型之一，对每一个元数据来说都具备相关的实体（类似于数据库中的表）和属性（类似于数据库中的列），以及不同实体类型之间的关系。每种实体类型都有一个实体键，它类似于关系数据库中的键。假设我们有一个名为Customers（顾客）的实体类型，它包括三个属性。此实体类型有以下记录：

在上述例子中，ID是其中一个实体键。以下请求会返回ID为2的一条顾客记录：

customerApi/Customers(2)

即该请求会返回ID=2的顾客信息。OData和SQL相同的是，我们能以请求方式来获取其中的相关数据。OData支持好几种数据请求方式，例如可以使用以下$select语法去请求受限的实体属性，它会去获取ID=2的顾客email信息：

customerApi/Customers(2)?$select=email

在SQL语法中，其查询样式为：

SELECT email FROM Customers WHERE ID=2;

以上只是为了方便大家了解OData协议举的例子。当然除了$select外，还可以使用其它的查询语法，如 *** ON或XML格式的数据导出$format等。

漏洞发现

我的漏洞测试思路是：首先需要对目标系统有一个整体的了解认识，然后再去一一测试其中的每个功能属性。在Microsoft Forms这里，我首先测试的是其中的OData元数据，为此，我必须对其元数据格式进行一个深入的了解。这里，我可以请求微软官方的metadata接口来看看：
http://forms.office.com/formapi/api/$metadata

在上述微软的XML元数据结构中，并没有多少有意义的线索。接着，我又从网站https://pragmatiq *** /xodata/的OData结构描述中来了解不同OData实体类型的关系：

一番学习之后，我尝试着去发现包含敏感信息的实体类型。正巧就发现一个名为forms的实体，其中包含了email在内的用户生成相关数据：

这里的这个email线索让我有了去探寻其他人邮箱的思路。这里，用IDOR和CORS肯定是行不通的。几经测试，我发现了一种可以访问获取到他人email信息的 *** ，但前提是，我的这种 *** 需要受害者执行访问某个恶意网站的交互动作。这种受害者交互的限制条件大大降低了漏洞危害性，最终我把漏洞上报后只获得了微软方面的简单致谢。

深入构造-未授权的OData实体访问

为了去除受害者交互这个前提动作，我重新进行了测试构造。我想Microsoft Forms用户可以把他的调查数据分享给别人进行帮忙调查，那么我是否可以从这个方面来考虑考虑呢。用户A需要把他的调查数据分享给用户B，那么需要做到以下几步：

1、用户A选择需要分享的表单form，微软服务端自动为用户A生成一个分享链接；
2、用户A把该分享链接发送给用户B；
3、用户B打开该链接，并往里面填写提交调查数据时，就会向微软服务端有一个请求动作，而此时用户A可以在他的账户环境中看到用户B的提交数据。

在以上第3步的用户B提交数据过程，会有以下提交请求：

可以注意到其中包含了以下关键字段：

formapi/api/<ownerTenantID>/users/<ownerID>/forms(<formID>)/responses

用户B提交表单数据时，这里请求内容中的ownerTenantID, ownerID, formID与他相关，因此，我就想利用这些参数能否查看到用户B的相关信息，比如邮箱email呢？于是，我就用$select语法构造了以下查询请求：

但请求发出后，服务端却返回了404的状态。也即服务端不允许我访问createdBy属性或是其他用户的表单邮箱信息。但我又想到了另外一种 *** ："是否有另一个实体有createdBy属性？并且还具有与forms表单实体相同的实体键(formID)？这又引发了我的想像，假设我们要找的实体为X，什么情况下实体键应该与forms表单实体键相同？

实体X具备createdBy属性，而我们的点在于需要通过该属性访问到其中的用户邮箱email。另外，假设X有一个名为accountID的实体键，为了访问其中的email，我们需要向其发送以下请求：

formapi/api/<ownerTenantID>/users/<ownerID>/X(<accountID>)$select=createdBy

这里的关键是accountID，因为我们并不知晓其中包含了什么东西，但从前面的步骤来看，我们可以通过用户B提交的表单看到其中的formID。之后，经过几种实体类型的比对，我又发现了另一个名为runtimeForms并包含createdBy属性的实体，且其与forms表单具备相同的实体键！这样，就完全满足了我前述想像的漏洞利用条件了：

接下来，我把请求中的forms用runtimeForms代替，并用$select语法去请求受害者的邮箱email。请求发出后，终于成功获取到了受害者的邮箱信息：

据此，我就能无交互地实现受害者邮箱信息获取了，当然最终也收获了微软官方奖励的$2k奖励。

参考来源：medium?