Share with your network!
The title of this article is a quote from our new Senior Director of Security Research and Operations, Chris Barton. Welcome aboard, Chris! Chris brings a wealth of anti-malware experience to Cloudmark. I must say that from down here in the trenches, fighting spam day to day, I echo his feelings on Javascript except that I would add several extra expletives.
For any social network, or indeed, any site that allows user generated content, there are some unpleasant tradeoffs. The first is the front door - the easier you make it to sign up for a new account, the more users you get, but also the more opportunity you have for spammers to set up farms of thousands of fake accounts used for message spamming. Of course, you can throw your hands up in the air and delegate the problem to other people as Pinterest does, but if you use Twitter or Facebook for account validation you are putting one of the most important aspects of your security in the hands of your competitors.
Once your users have accounts, there is an even bigger trade off. The more flexibility you give them in what they can post, the richer the user experience, but the more scope there is for abuse. There are some reasonable ways you can deal wit some common attack vectors – host all pictures on your site so they don't suddenly start advertizing kiddie porn sites, remove iframes from HTML so they don't start serving up malware, scan PDFs for known exploits, and of course, use Cloudmark's state of the art spam detection on all messages and postings.
However, if you allow users to post Javascript, then you are exposing yourself to vulnerabilities that are extremely difficult to manage. Right now we are seeing two highly respectable sites, one of them in the top fifty ratings in Alexa, being used by spammers to redirect a call to action. What looks like a link to a personal page on a social network, with one line of Javascript takes you straight to a porno or pharma site instead. Not only is it easy to redirect with Javascript, it is easy to hide what the Javascript is doing. Techniques for obfuscation are many and mutable. There is no way you can just grep the code for "document.location" and hope that this will show up all the redirectors. The only way to tell what Javascript is going to do is to actually execute it in a browser, and unless you are willing to do that for every single page that users post on your system, then like the man said, "Blindly publishing javascript is <expletive frenzy> bad practice!"