Next Gen Phishing Scams

Still playing catch up after my recent travels – but this article still bears mentioning.

I saw this article about Web 2.0 phishing a while ago and was intrigued.  The basic premise is that new “Web 2.0” phishing attacks will overtake phishing emails as spam filters get better.  This is an excellent idea and deserves more specific discussion.

First of all – any self-respecting organization that does web development has hopefully purchased a web application scanner by this point and they are running it against any public-facing application.  These scanners are great (well, reasonably good) at finding Cross Site Scripting (XSS) and SQL Injection flaws.  Anyone who is deploying web applications ought to be using one because that is just good due care.  <shameless_plug>If you don’t have one, please give us a call at Denim Group – we are resellers for all of the good ones and we provide training on how to use them, what they do, and what they won’t do so you can understand where they fit into a comprehensive application security program.</shameless_plug>

Next – and this gets more to the point of the article – now that attackers are getting smarter about using Web 2.0 techniques in their Cross Site Scripting (XSS) attacks you need to understand that the damage potential has increased quite a bit.  Before an attacker would try to inject a little JavaScript that would forward cookies along and help steal sessions.  That is certainly bad.  Now, using the power of JavaScript it is possible for the attacker to take control of the browser and force much more serious behavior.  Rather than waiting for someone whose session cookies had been stolen to log in, attackers using Web 2.0 techniques can craft their own (authorized) requests to the server to do … whatever the attacker wants the application to do.

If a malicious attacker can run JavaScript of their choosing on your browser, they can force you to send any request they like to the server.  They can mimic traffic that would sign you up for a new account, transfer money, change your password or any other nightmare scenario where the attacker knows what the HTTP request would look like.

How do you defend against this?  Unfortunately I can only repeat advice from the past:

  • Positively validate incoming inputs (especially for length!) – If something is supposed to be an 8 character username field – make sure the field is 8 characters and that all of those characters ought to be used in a username.  Limiting length is especially important here because while it is relatively easy to craft cookie-stealing JavaScript in a small space if an attacker is going to make more advanced XmlHttpRequest calls they will need some more room.  Limiting the length of allowed inputs on the server side will pay extra dividends here.  Don’t take that as a license to stop filtering HTML and JavaScript-y characters like < though.  That is more important than ever.
  • Escape untrusted data before it is sent to an output stream – Whether this comes directly from user input or from a data store that isn’t completely under control of your application this is the only sure-fire way to prevent Cross Site Scripting (XSS) attacks.  If, any time you display input from a potentially malicious source, you HTML escape the output you will not have any problems with cross site scripting.  Remember that untrusted sources include user inputs as well as data pulled from data sources.  Think you can trust the data in your database?  Ask yourself how many other applications have write access to that database and how confident you are about the filtering your application has had in place over time.  When in doubt – filter.  We find that 98% of the time you don’t need special characters from datasources and when that is the case there is no harm in HTML escaping everything before it gets sent out the door.

Yes – Web 2.0 technologies allow for much more interesting and sophisticated payloads to be used in Cross Site Scripting (XSS) attacks.  And yes as spam filters get smarter this may become an easier attack vector.  However the countermeasures against these problems haven’t become any more sophisticated – only the sophistication of the attackers who are looking to exploit age-old issues in applications that should have been solved long ago.  A more sophisticated exploit against a common problem doesn’t matter if that common problem has already been appropriately remediated.

–Dan
dan _at_ denimgroup.com

About Dan Cornell

A globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application vulnerability management platform.
More Posts by Dan Cornell

Leave a Reply

Your email address will not be published. Required fields are marked *