Recent research was presented raising security and privacy concerns around URL shortening services like bit.ly, goo.gl, and others. The services are used to shorten lengthy URL’s to more compatible URLs suitable for online use. Smaller URLs also provide ancillary benefit since they are easier to remember. My first impression was the recent research on URL shorteners was that it was specious since URL shortening was never intended or designed as a security and privacy control from the start. Reading the research softened my initial opinion. The seeming randomness of these short URLs provides the public unfounded confidence of their utility for security. Specifically, the false idea that others will not discover the link since it appears secure – difficult to guess. Unfortunately, the part of the URI providing the identity for the long URL, is as few a 6-characters for some shortening services, far too small a space to be cryptographically secure, and easily brute forceable by attackers and demonstrated by researchers.
The research paper was not the first cracks in the short URL armor. The following presents some concerns I gathered across different resources from other researchers. I also share some personal thoughts about short URL weaknesses that I have not noticed elsewhere. I don’t stake any claim to these and I’m simply passing them along to raise awareness. I’m betting we have not seen the last around security and privacy concerns with short URLs.
1) Short URLs not secure
As researchers mention these links are not secure and easily brute forced. This may or may not be a concern for you depending on how you use them.
2) Short URLs target host unknown until clicked
Phishing is a problem for everyone. Short URLs exacerbate an already bad email phishing problem. There are some services like checkshorturl.com where email users can unwind these URLs but most people will never do this. People are trusting and verification takes extra work. Clicking a shortened URL is like hitchhiking in a strangers car, you don’t know where it’s taking you.
3) Obfuscated redirects
Brian Krebs makes an interesting point, attackers can leverage an open redirect on a government host and create a short branded URL. The result is an authentic URL that looks like it navigates to a government web site but instead navigates to the attackers malware site.
Becomes this branded URL (notice the .gov domain, ouch!)
The combination of an open redirect and short URL branding creates a situation of misplaced trust or false sense of security. Users think clicking will take them to a government site when if fact it takes them to another site entirely. The moral of the tale, if you have any open redirects in your web site your in trouble but if you also use branded URL shorteners your setting the public up for malware and phishing attacks.
4) Obfuscate payloads
A spin on Krebs idea I considered is that any arbitrary payload can be saved in a long URL by attackers and hidden from prying eyes – a payload. For example, on some services it’s possible to create arbitrary URLs with invalid hosts and parameters so long as those URLs are syntactically correct. Meaning if I create a URL https://www.xyz.com/def some shortening services are not checking to ensure host xyz is a valid host. Even if the host is valid, URI parameters may be developed that legitimate hosts ignore entirely like the following, https://www.xyz.com/def?a=b,b=c. Some servers like Blogger ignore superfluous parameters like a=b,b=c in the request if you pass them. Attackers can create any URL they want. I used the following in a quick test,
http://www.xx100kaass.com/0 (x10,000 zeros, for a 10k URL)
I created a bogus URL with a 10KB URI that consisted of a slash (/) followed by 10,000 zeros and was successful. Attackers can store payloads in these bogus URLs to use for a variety of purposes. Outside of validating the syntax and host, shortening services have no idea of knowing if these URIs are valid and, in their defense, there’s probably not a good way for them to validate. Therefore, they must store the entire long URL. This means an attacker can use URL shortening services, to hide small chunks of arbitrary data for nefarious purposes like command and control for bot networks, torrent information, etc. URL shortening sites undoubtably provide security intrusion and content controls. There’s likely some limits in size or number of URL per second they will accept, etc. I’m not sure what they are but it’s likely they vary between shortening services.
5) Multiple indirection
Some of the URL shorting services will not accept their own URLs for a long URL but at least a few of them will accept shorted URLs of other services. Therefore it’s possible to create multiple levels of indirection. short URLs referring to other short URLs. How many levels can be created? I’m not sure. It seems like browsers must have some practical level of redirect control but I have no idea. I’m not sure if this serves a practical purpose yet but at the very least it complicates organizational IT forensics.
6) Infinite loops
I was wondering if I could create two or more short URLs referring to each other. To get this to working requires an understanding of the shortening algorithm such that the attacker can determine the shortened URI before it’s created. Or perhaps a shortening services that allows changing a long URL after the short URL has been created. This will allow an attacker to create short URLs that either directly or indirectly refer to each other. I didn’t spend much time looking at this. I tried to find some code online to see if there were any standard algorithms. I was thinking everyone may be leveraging an open source project so I could determine the algorithm easily. Nothing was obvious, I was not successful. Perhaps someone else may want to take this up. I’m not sure if the browser is smart enough to detect these types of infinite redirects or not. If not, it seems plausible it could be used to hang or crash the browser. Even if possible, I’m not sure this has any practical value for attackers anyway.
7) XSS in URLs
8) Shortener Service Unavailability
If the shortening services goes away temporarily or permanently it impacts the services anywhere shortened links are embedded. What happens to Twitter if bit.ly goes away? Not good. DDOSing bit.ly is essentially the same as DDOSing Twitter since a better part of Twitters content would be unreachable for users if bit.ly cannot respond. Bit.do has a big list of shortening services. Bit.do also tracks shortening services no longer available and there’s many more of them I was aware. If shortening is part of your business strategy, or your users are using it, you may want to consider all your available options and weight risks, reliable services, hosting your own, etc.
Keep in mind my tests were not comprehensive and exhaustive. I didn’t want to do anything that could be considered offensive. So if noted a test was successful it may not be successful across all services. Conversely if a test was unsuccessful if may not be unsuccessful everywhere. An important consideration, while there are some problems with URL shorteners there’s not a good immediate option for avoiding them. If your going to participate in social media your going to be using short URLs like it or not until improvements are made.
* Landminds image from World Nomads