Update 2016-10-20: Microsoft finally fixed this issue.
TL;DR; The shorten URL feature does not use encryption.
I am currently working as a software engineer developing with a web based B2B solution when I came across something interesting when performing some security analysis of the application.
A part of the application is to enable people within an organization to share information with each other and this will naturally lead to users linking to external resources. The application is HTTPS/TLS secured and all the external resources used at the moment resides on HTTPS/TLS secured servers. However, examining the links added by users I discovered somthing unsettling: Microsoft is not using SSL on their OneDrive URL-shortening service.
What this means in practice is that an even though OneDrive (Office 365) resides on a secure server, we break the encrypted chain when using the short link service. How this happens in practice is the following scenario:
- A user chooses to share a document to other users via a hyperlink.
- OneDrive generates a link:
- The user thinks the link is to long and clicks ”shorten URL”
- Microsofts generates the short link: http://1drv.ms/1LHw83B
- If the link is opened on an insecure network, for instance an open WiFi on a train or bus, anyone able to observe network requests can capture the URL ”http://1drv.ms/1LHw83B” which will lead to the document.
I think Microsoft needs to be more clear about the security implications of using the shorten URL feature since this is a security concern for every organization using OneDrive and the shorten URL feature. The solution in order to fix this problem is very simple and straight forward for Microsoft: ”Implement HTTPS on 1drv.ms”.
The solution for the rest of us is to not use the shortened URLs from Microsoft for anything sensitive for the time being.