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:
- the only thing that one user can input to the website is a single URL
- the URL sent by the user is sent to an external URL shortener service
- 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:
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.