Researchers Find Vulnerabilities In Microsoft's and Google's Short URL Services (arstechnica.com) 48
An anonymous cites an article on Ars Technica: Two security researchers have published research exposing the potential privacy problems connected to using Web address shortening services. When used to share data protected by credentials included in the Web address associated with the content, these services could allow an attacker to gain access to data simply by searching through the entire address space for a URL-shortening service (PDF) in search of content, because of how predictable and short those addresses are. Both Microsoft and Google have offered URL shortening services embedded in various cloud services. Microsoft included the 1drv.ms URL shortening service in its OneDrive cloud storage service and a similar service (binged.it) for Bing Maps -- "branded" domains of the bit.ly domain shortening service. Microsoft has stopped offering the OneDrive embedded shortener, but existing URLs are still accessible. Google Maps has an embedded a tool that creates URLs with the goo.gl domain. Vitaly Shmatikov of Cornell Tech and visiting researcher Martin Georgiev conducted an 18-month study in which they focused on OneDrive and Google Maps. "We did not perform a comprehensive scan of all short URLs (as our analysis shows, such a scan would have been within the capabilities of a more powerful adversary)," Shmatikov wrote in a blog post today, "but we sampled enough to discover interesting information and draw important conclusions." One of those conclusions was that Microsoft's OneDrive shortened URLs were entirely too easy to traverse.
Rinse and reuse (Score:5, Insightful)
Click it or, well, just click it (Score:3)
What is the point of such things? Originally it seemed to be to let people type in such things from a magazine, without causing a half hour, error-prone headache.
That is no longer the case. It is all web magazines and articles and hyperlinks with labels instead of the actual URL. So what is the point?
Re:Click it or, well, just click it (Score:5, Informative)
The Google Maps URLs are nice because they contain the entire view you're seeing (including a place you have highlighted or directions). Those URLs get pretty massive and if you post them in a chat window, they tend to break (special characters and such). So I can see use cases there.
Re: (Score:1)
The whole point of providing such a service is to serve as a data source for the provider. Google and Microsoft get to basically MITM any shortened link and collect all sorts of data... all largely tolerated only because of the limited message length of services like Twitter.
Is it really so surprising that 3rd parties can also mine some of that data?
Re: (Score:2)
Horseshit. There are plenty of use cases for not having to type in a URL that is 300 characters long, a lovely side-effect of encoding data in the URL which the world wide web provided us.
By the way your tin-foil fly is undone.
Re: (Score:2)
You missed his point, which was to summarize the business case for a company to provide URL shortening services (MITM data mining).
Your point about use cases seems to be from the users' point of view, which is different. I agree with your view (who wouldn't?), but it is orthogonal to the parent post.
Not a URL shortening vulnerability (Score:5, Insightful)
If you want information to be private, require authentication to access it. The real problem here is that files are shared in the cloud allowing read and, sometimes, write access without requiring authentication. The default needs to be requiring authentication and then prompting the user if they want to change the permissions. Otherwise, you're relying on security through obscurity, which isn't security at all. It's too easy for URLs to end up being found through things like the clipboard and the browser history that nobody should expect them to remain secret. Don't rely on security through obscurity. It doesn't work.
Yeah, credentials in the URI==doing it wrong (Score:5, Informative)
> data protected by credentials included in the Web address
You're doing it wrong.
A web address, or URI, is a universal resource IDENTIFIER (or locator, for the older terminology). It specifies which data you wish to access. That's not the place for authentication to be.
Sharing a long URL which includes your user name and password is stupid too.
Re: (Score:3)
Right. And further to that, the authors talk about a brute force scavenging of the entire database of URLs being possible because the "active bytes" at the end of the short URL are so short. Well, one could add two, or four, bytes to the end of the URL, and only use "one in every hundred numbers, determined randomly" as their algorithm, and then it wouldn't be quite so brute forceable.
So there are _two_ implementation problems (in the case of Microsoft's 1drv.ms, and arguably one problem with the other sh
Re: (Score:2)
There is an easy solution to discourage people from trying to read all short URLs. Make the algorithm pick one in every thousand, or ten thousand URLs, and have the others automatically serve ads. Large, content-heavy ads. Make sure those pages have every possible type of bandwidth-heavy content -- auto-playing video, Flash, animated GIFs, and tons and tons of individual elements. In other words, redirect them to Huff.
Re: (Score:2)
There is an easy solution to discourage people from trying to read all short URLs. Make the algorithm pick one in every thousand, or ten thousand URLs, and have the others automatically serve ads.
Someone clever enough to search a shortener's address space is probably smart enough to skip ads (i.e. not bother downloading ad content). Now, if you put an annoying CAPTCHA before redirecting to the original link, that might keep people from searching the address space. Of course it would also kill your user base, since CAPTCHA is a PITA.
Re: (Score:2)
Is there any expectation of security? (Score:5, Informative)
The goo.gl shortener says, right below the URL entry field "All goo.gl URLs and click analytics are public and can be accessed by anyone". I always figured that it was obvious you shouldn't use this sort of service for any URL that needed to be kept secret, and didn't have some additional access control behind it.
Re: (Score:2)
Users may not realize that the URL should be kept secret.
And services that embed credentials in URLs should EXPIRE those credentials after a (short) amount of time.
Re: (Score:2)
Or just, you know, NOT do something completely stupid in the first place.
Re: (Score:2)
Exactly. I know people that send long URLs generated to privately share, like Google photos and send them using Twitter direct messages, believing they are not being shared with the world and they are wrong. Those long URLs know to be relatively secure even by Bruce Schneier [schneier.com] are being converted to short ones, and accessible to the public. There is or was a lawsuit related to that [hollywoodreporter.com]
Re: (Score:2)
The link to lawsuit you provided has NOTHING to do with what you said in the first half (which is more important). However, the way you said implies that Google/Twitter are sharing secret with the world. Whether or not they share your secret, you can't use the link as your proof.
The only thing from the link I would assume is that Twitter scans any messages for URL and converts those long URL to a shorter version of its own. That does not prove that the message is being shared to the world.
From the link
If a user privately tells a follower through the service to check out a story on nytimes.com, providing a full URL, Twitter will modify this into a custom link such as “http:/t.co/CL2SKBxr1s” (while still displaying the text “www.nytimes.com” to its users).
Re: (Score:2)
Well, if you send a long URL, that by being long is very difficult to guess, and Twitter convert it to something so small that can be crawled, It is some kind of sharing. They should not be shorting URLs sent as direct messages, as this vulnerability shows, they are breaking the security of the long URL by shortening it.
I am not saying the Google is sharing anything. They give you a long URL that you can send to people you trust, then Twitter shorten it and that short URL can be crawled easily, au contraire
Re: (Score:2)
and by the way, the lawsuit has something to do with why I am talking. Twitter is shorting URLs on direct messages. The lawsuit want that stopped. Sending a private long URL using a direct message is being shortened, do you see the relation now?
Re: (Score:2)
Users may not realize that the URL should be kept secret.
The warning is literally on the line under the line where you type the URL. Stevie Wonder could see it. The only users you're talking about are those which have a nurse come in every 15 seconds to remind them to inhale, and then again 15 seconds later to remind them to exhale.
Re: (Score:2)
Congratulations! You have confirmed your lack of reading comprehension.
Does this URL need to be kept secret?
https://slashdot.org/comments.... [slashdot.org]
Re: (Score:2)
The goo.gl shortener says, right below the URL entry field "All goo.gl URLs and click analytics are public and can be accessed by anyone".
It does now; did it always say that? I rarely use it so I can't remember. They may have just added this as a response to the disclosure.
I can't say when it was added, but I first noticed it quite a while ago.
Re: (Score:1)
Re: (Score:3)
Re: (Score:1)
I'm not sure whether you're being facetious, but there was a time when Slashdot would give you a URI that logged you in. You could bookmark it and bypass having to enter your userid and password, as your credentials were stored in the URI itself. I just quickly checked "Options" and "Account" and I don't see it anymore, maybe they got rid of that feature after slashleak 2000 [slashdot.org].
"binged.it"? (Score:1, Troll)
Perhaps someone should tell Microsoft that "binged" is already a word [thefreedictionary.com], and it's neither pronounced nor defined they way they apparently hope it will be.
Who cares? (Score:2)
No bulk request protection? (Score:2)
I am working on implementing something similar. Not an URL shortener, but semi-private shared data with a short URL. My first thought was the risk of someone trying to attack and steal all the records via brute force. Then I decided to track invalid requests and present a CAPTCHA after 3 failed requests from the same IP.
Isn't this easy to solve? Even with a distributed attack, each IP would only get a few hits and it's a large search space. And even if CAPTCHAS are broken, there can be more aggressive
Re: (Score:2)
Even with a distributed attack, each IP would only get a few hits and it's a large search space...
Quick questions... How long would the same IP be used again after 3 tries??? Would this propose solution be easily DNS???
Re: (Score:2)
I don't know what you're asking.
Re: (Score:2)
I am working on implementing something similar. Not an URL shortener, but semi-private shared data with a short URL. My first thought was the risk of someone trying to attack and steal all the records via brute force. Then I decided to track invalid requests and present a CAPTCHA after 3 failed requests from the same IP.
Isn't this easy to solve? Even with a distributed attack, each IP would only get a few hits and it's a large search space. And even if CAPTCHAS are broken, there can be more aggressive measures to follow if invalid requests still come in - including slowing down loading times on flagged IP addresses.
I did exactly this for a company I worked for. I skipped the whole captcha thing though. When I start seeing failures from an IP then I start randomly increasing the response time of the service and once I had too many failures in a fixed window then I started randomly returning "url not found" even for valid urls. We implemented it for text messages. Also, unlike most url shortening services, our urls expire after 24 hours because that is all the longer that we need them to be valid.
This is not a security vulnerability (Score:2)
The headline says "Researchers Find Vulnerabilities In Microsoft's and Google's Short URL Services." Regardless of the ability to reverse-guess the shortened URLs, this is really the user's fault.
If a user creates a shortcut that contains their login credentials, then that is their choice. Embedding the credentials into the URL means they are not credentials any longer, they are just part of a long obfuscated URL. Further shortening it completely defeats the purpose.
yeah but, permissions? (Score:1)
Re: yeah but, permissions? (Score:1)
Hardly a discovery (Score:1)
Sorry, but I don't see how is that news or a secret. Just like tinyurl, the ID of the url is supposed to be as short as possible, hence it is sequential.
The funny thing I found a few years ago was with tinyurl. Apparently, the first links were created by their developers, hence links like tinyurl.com/1 and so on (2,3,...a,b,c...1a,1b) belong to owners of the service and tell something about them.
Therefore link shorteners should have password protection for redirection, at least as an option. For example, as