SharePoint 2013 and Office Web Apps communicate authorization via a JSON Web Token. This JWT contains important information about the caller, such as the username, SID, time-related information, as well as where the request is originating from. JSON is insecure by default and the JWT is easily unpacked to reveal the contents of the JWT. So, how does this apply to SharePoint? If you’ve followed what I do for any period of time, you’ll probably know I’m in the SharePoint-related TechNet/MSDN forums on a daily basis. I see a lot of fun configuration issues, and so forth. But one thing I’ve seen on a fairly regular basis is Office Web Apps administrators setting their WAC farm to AllowHTTP = $true. This means the insecure JWT is being passed over the wire in plain text, instead of WAC’s default setting of leveraging an SSL certificate for transport encryption. To demonstrate this, two Domain User accounts are created. NAUPLIUS\User1 and NAUPLIUS\User2. User1 is granted Contribute rights on a Word Document in a SharePoint site. User2 has no access to the Word Document or the SharePoint site. When the user opens the document in Word Web App, a packet capture will be performed to capture the JWT and URI. Here we can see three key pieces of information, the access token value (“eyJ0eXAiOiJKV1QiL…”) and the Web the file is located on (“http://spwebapp1/sites/team”). The JWT can be unpacked to examine the contents: [crayon-541e2af396a3b089217980/] From the JWT, using the first value in appctx (“def25ded79194e09bf5e340635599a85″), it is trivial to construct a web request to view this document. Using a custom console application that fires off the WebBrowser control, the above information can be inputted and viewed under any user account, regardless of their access level in SharePoint. In this example, NAUPLIUS\User2 has leveraged the JWT token from NAUPLIUS\User1 to view the previous document. And remember, NAUPLIUS\User2 has no access to the Site Collection or the Word Document. Based on this, it is technically feasible to leverage the JWT to impersonate another user. Having access to the JWT is the same as having a username and password when it comes to applications that use JWTs. The lesson on display here is that transport encryption is vital to securing a JWT, typically in the form of SSL communications. If SSL was enabled on the WAC farm, it would not be possible to view the JWT. Always use SSL in production environments, and consider it in development environments that traverse networks or contain sensitive data.
The post The Dangers of AllowHttp for SharePoint appeared first on Nauplius.
