XSS in Dynamics 365

I recently tested an application hosted within Microsoft’s Dynamics 365 online services platform. During the test I discovered a Cross-Site Scripting (XSS) vulnerability.

Dynamics 365 is typically extended with customer code which can be a source of trouble, however the vulnerability discovered was in the Dynamics 365 product itself.

After obtaining permission from the client, I worked with the Microsoft Security Response Center to fix the issue. Now that it has been patched (as of the 18th October 2018) I can disclose the details of this vulnerability:

Within Dynamics 365, the “Personal Document Template: Information” page reflects the user’s name without encoding it properly, so if the field is injected with a JavaScript payload, it will be run unchecked.

In the Dynamics 365 tenant being tested, I was able to change the First Name and Last Name values for the “Application User” (this appears to be separate to the Azure AD User, which was locked down).

I set the First Name field to contain a JavaScript payload. No special tricks needed; the payload was simply “</script><script>alert(‘xss’)</script>”.

The First Name and Last Name fields are used throughout the application and are usually encoded safely. However the “Personal Document Template: Information” page reflects these fields without encoding and runs the payload.

With this payload set, a malicious user can create or update any template they have access to, and direct a victim to the template information page. When the owner and last modified fields are loaded into the victim’s browser, the payload is fired.

As you can see, this was not a complicated attack in hindsight but it has the potential to have a large impact. It is also a good example of how assumptions should not be made about the code base being tested. If I had assumed the product code had been extensively tested and was secure, then this simple XSS injection would have been overlooked.

The takeaway is to try and remember to sanitise and encode all inputs/outputs, regardless of what they are used for, and not to make assumptions but rely on empirical evidence as a penetration tester!

Thanks to Microsoft for acting as a responsible vendor in accepting and patching this vulnerability in such a short period of time.