Practice Safe XSS
Hacking, cracking, and codejacking have exploited application vulnerabilities from the time the earliest programmers wrote their first “Hello World”. In the past, only application developers were vulnerable to such attacks. The dynamic web brings these attacks into the domain of the common website, as more contemporary sites use a database to drive their content.
In the early 2000s, common websites were composed of several static HTML pages, and only programmers (and wealthy corporations) could enjoy the luxury of a database-driven content management system (CMS). When I wanted a database-driven site, I had to build one myself using PHP and MySQL. Sure, there were bulletin board systems (now referred to as forums), wikis, and web site building applications, but their use was nowhere near as popular as today.
With affordable website hosting came the deluge of database-driven websites. Blogs, forums, wikis, and open-source and commercial CMSs now drive most websites. Every one of these sites can accept user-generated content (UGC), and every one of these sites can be exploited. The web-based forms that interface with the database can open the door for SQL injection or cross-site scripting (XSS) attacks that can do anything from redirecting traffic from your site to an online pharmaceutical company to turning your server into a drone machine that attacks other servers.
At the time of this writing, Google returns over 16,000 results for ‘sql injection’ and 30,000 for ‘cross-site scripting’ OR ‘xss’ from articles indexed within the past 24 hours. Click the links to compare that number with the current articles at the time you read this. There shouldn’t be much difference. If anything, code exploits should become more frequent. After all, it is a numbers game, the number of database-driven sites increases exponentially.
We can’t lay blame on Microsoft vs. *nix based servers, open-source vs. commercial software, or even specific companies, as all machines connected to a network are at risk. My fellow bloggers have had their WordPress sites hacked through their comments forms. When I explored Moodle on my server a couple of years ago, the landing was replaced by a “YOU’VE BEEN HACKED” page even though I hadn’t publicized the link to anyone. It was only set up for a week.
While some users are malicious, some are just experimental. I recall a story of one user who hacked MySpace to exploit a hole that bypassed both the captcha and confirmation usually required to add “Friends”, and successfully befriended over a million users in the span of eight hours. Maybe I’m exaggerating, but over two days that script effectively shut down MySpace. The point is that regardless of how secure your site is today, you need to monitor your security, constantly.
Fred Salchli, Duo’s Chief Technical Officer, told me a story of how SQL injected into an unmanaged web application once corrupted a series of websites hosted on the same server. Duo was called in to rescue the data by running a script on each of the websites to determine which fields were affected with this code. Then they proceeded to update the applications to block the holes and prevent any future attacks.
He also gave some tips to reduce the possibility of your site being attacked. Initially, insulate your database from raw information submitted through web forms by cleaning the input through validation and encoding and escaping strings. Within your code, enforce strong typing of variables that work with data input. Additionally, incorporate a database abstraction layer to provide a buffer between submitted data and your database.
Once your code is secure, keep it secure by keeping abreast of security issues and applying patches and updates as required. And if your database still gets attacked, be sure that you have a current backup to restore your data.
Most attacks use JavaScript in combination with SQL. Some involve more complex code execution from image header information. However, a new threat has made recent news, that uses neither of these methods. The first report I read about ‘clickjacking’ was so vague it was unclear whether even the author knew the exact nature of the problem.
However, other coders developed sample code exploits based on speculation of how these attacks could happen, and the results were downright scary. One turns your MySpace profile from private to public, and another sends an email to cyberspace using your gmail account. (Note: if you are not already logged into these systems, these examples won’t work. You can bet the more malicious clickjacking scripts monitor your system, waiting for you to shop or bank online, and then send your keystrokes to remote locations.)
More recently, a quick scan of my server logs found an unusually high number of requests for aedating4CMS.php, as that script contains some apparent vulnerability. I would have been a lot more worried if I actually used that application. Nonetheless, because I treat invalid page requests as directives to search my WordPress database, allowing that request would tie up server resources and poses a security risk. Rather than letting this sort of behavior go through, I hacked my server script to redirect all requests containing ‘aedating’ back to the originator. Problem solved.
Most users don’t have the interest, the understanding, or the time to manage their server and database security to this extent. In these cases a web services company is your best friend, as their staff will test and troubleshoot your applications, apply upgrade patches, and even maintain backups in the event something happens. Hiring others to manage your hosting services frees you up to work on and build the core of your business.
