Implication of URL injection in an URL shortener service

Question

EDIT There have been upvotes retracted or downvotes due to, I think, a serious misunderstanding of my question. In the following I'm not concerned about the URL leading to a site containing malware or exploits (not that it's not a concern: it's simply not what this question is about): I'm concerned about injection in the URL string itself. What I don't want is a pirate being able to dodge "whatever framework" security and be able to inject, say, JavaScript code in an URL that I would then display to other users. In other words: I'm looking for an additional measure to lower the risk of rogue JavaScript running as if it was coming from my webapp.

In order to harden a webapp, I'm thinking about never ever displaying URLs input by users and yet allow them to input URLs but always use an URL shortener service. This is not meant to replace other good security practices but to be used in addition to other security practices.

Here's a very simple scenario:

1. the only thing that one user can input to the website is a single URL
2. the URL sent by the user is sent to an external URL shortener service
3. the shortened URL is then served from my website

If during the first step we consider that my parser doesn't have flaws while parsing the POST parameters sent by the user, what can go wrong later on if there's a succesful exploit in the URL that would affect the URL shortener service?

Basically my idea would be to serve, say, an hardcoded:

http://bit.ly/

followed by a very strict rule saying someting like: "insert at most 9 characters and these characters have to be alphanumeric".

I'd do that in order to simplify the rule concerning which characters can and cannot be sent by the user: the output of a bit.ly URL is way simpler than what legit URLs allow (I used bit.ly as an example, any URL shortener service using a very strict subset of characters in the shortened URLs it returns would do).

So what would the worst case scenario be if we consider that the rogue user is unable to exploit my website but still manages to exploit a flaw in the URL shortener service?

What I'd like to better figure out is what it means when it comes to same origin policy / XSS and CSRF and other types of exploits.

And, I guess, my question could be resumed like this: "If security is done correctly on my website, would XSS exploits affecting the URL shortening service still be my concern or not?"

The whole idea would be to add defense-in-depth and to consider that URL shortening service probably know how to defend themselves about URL injections.

Answer 1

This is an inefficient way of doing things.The only security you would get from an external URL shortening service is that they will only shorten valid URLS, and not javascript code etc. However, you are still relying on their security that they will indeed shorten the URL provided by the user, they will be up 100% of the time, and have 0 security vulnerabilities. Why not write your own little parser that verifies URL's. Somethings like this: https://stackoverflow.com/questions/205923/best-way-to-handle-security-and-avoid-xss-with-user-entered-urls

Some things you can look for:

1-The users have indeed entered a url starting with http:// and not some random java script code.

2- you can also use google safe browsing api to check the URL for malware. https://developers.google.com/safe-browsing/, this is very helpful as the google safebrowsing API will return malware for malware and 200 for valid URLS, for anything else such as invalid URL's the google api will return nothing.

Answer 2

It depends on what the URL shortener service does. Presumably it takes an input (the full URL) and produces an output (the smaller URL), storing the mapping from the smaller URL to the full URL in the database. It may also store a hash of the smaller URL to be more efficient and make lookups faster. I am just speculating because the way it works would really depend on your implementation. However, component wise, the SQL likely going to use a database to store the mappings. Also, the service itself might have access to that database to ensure that duplicate mappings do not occur. It would be possible to produce a SQL injection if the URL service directly uses the database and does so poorly. SQL injection can be prevented by using parameterized queries.

Secondly, your URL shortening service would be vulnerable to DOS attacks where more requests than it can handle are performed. This especially applies if it is written poorly and cannot quickly generate unique URLs. However I would not really worry about that too much, DDoS attacks can be launched against anyone.

I think you edited your post to indicate that it's an external shortener service. This does change things because it means it isn't your database that's vulnerable to SQL injection, but someone else's. Really, there's not too much risk involved with this type of service. If someone can manage to inject the database or otherwise hack it, they can cause users to be redirected to the wrong URL, one that they have set up with malicious code. This external service could also be a danger to you because it can return any old URL it wants to. There's nothing forcing them to implement the mapping in good faith. They can easily send you 99% good URLs and 1% malicious URLs to malicious sites that the author of the shortening service has set up. Or the shortening service itself could be compromised, which will indirectly affect your website. Basically, the URL shortening service being hosted externally saves you a lot of headache because you have fewer attacks to worry about. But the most serious attack if the external service is compromised, is that your users will be fed incorrect or malicious URLs. Depending on how the web service to retrieve these URL mappings from the URL service is authenticated, you have the possibility of a MITM attack being executed in order to serve you fake URLs as well. And your web service could potentially be exploited to hack your server also. Again, all of these things depend on implementation of the url shortener service and of the web services and authentication... a lot of factors you have not given us information about.

Answer 3

How would your server know if the URL is coming from the shortening service or not? Couldn't the attacker simply act as if they were the URL shortening service and submit information in a way that would break your system?

I don't see how this is any different from accepting URLs but then doing a URL Rewrite to ensure that the information they passed in on the URL is not displayed, unless I'm missing something about your proposed scenario.

If you are simply using the URL Shortening service to provide random tokens for particular pages to your site, then why not simply store a bookmark internally in your DB. This way you control the input being used to prevent abuse. Even if you are calling the shortening service directly, what would prevent a malicious user from making their own shorted URL for your domain? (Unless you have a shortening service that will only return results from your account.)