A new wave of mass SQL injection attacks seen in mid-August to hit over half a million websites, including parts of Appleâs site serves as a weighty reminder of the growing prevalence of mass injections and of SQL injections in general as a favorite means of hackers to tap into organizationsâ infrastructure and data resources.
In light of these attacks, security researchers believe now is as good of a time as any to revisit some best practices necessary to prevent mass SQL injections and mitigate the risks associated with injection attacks. These practices are hardly revolutionary, but it is clear that they arenât being implemented as widely as they need to be.
âYou keep seeing the same issues come up over and over again for many years now,â says Alex Rothacker, manager of Team SHATTER, Application Security Inc.âs research arm. âEven with this Apple attack, they used a little bit more advanced attacks, but still itâs stuff thatâs been talked about at Black Hat for two years now.â
1. Never trust input
This should be one of the mantras of developers as they write Web application code. According to Jacob West, security research director for Fortify Security, organizations should âcreate and enforce secure coding guidelines for software developed in-house that requires SQL be constructed using parameterized queries, which prevent SQL injection attacks by differentiating code from data.â
Developers should work to ensure that inputs are sanitized before querying the database, Rothacker says. âMake sure that the data that people input into your website is exactly the data youâre looking for, so if youâre asking for a social security number, you want to make sure it is actually a social security number and there are no letters in there,â he says.
2. Implement filtering and monitoring tools
Filtering and monitoring tools (eg. Ax3soft Sax2, snort) at the Web application and database levels will help block attacks and detect attack behavior in order to mitigate risk of exposure to mass SQL injection attacks.
At the application level, West says that organizations should âwear suspenders,â by implementing runtime security monitoring to defend against SQL injection attacks and vulnerabilities in production systems. Similarly, Web application firewalls can help organizations put certain behavior-based rule sets in place to block attacks before they do damage.
On the database, database activity monitoring can also filter attacks from the back end, Rothacker says. âDatabase activity monitoring is a really great tool against SQL injections,â he explains. âFor known injection attacks, thereâs always filters out there that will help alert the DBAs that something bad is going on and thereâs also some pretty generic filters that look for things that are very typical in SQL injections â things like an uneven number of quotes that break up the SQL code and stuff like that.â
3. Craft error messages carefully
Hackers can and will use your own error messages against you to better dial in future attacks. Thatâs why both the development team and DBAs need to think about the error messages theyâre returning when users input something unexpected.
â[Organizations should] configure the Web and database servers to not output error or warning messages,â warns Neil Daswani, co-founder and CTO of Dasient. âAttackers can use such messages to learn about your database schema using techniques such as âblind SQL injection.’â
4. Patch and harden databases
The risks associated with SQL injections are escalated when the databases tied to the Web applications under attack are weak due to poor patching and configuration.
âKeep your databases patched, and also your Web applications and Web services while youâre at it,â says Rothacker. âI think that should be a no-brainer.â
Additionally, donât forget about how your databases are configured. âHarden the database and the operating system of the machine it is running on by disabling unnecessary services and functionality,â says Dasientâs Daswani.
5. Limit database privileges
Finally, organizations need to do a better job at managing how accounts associated with Web applications are interacting with back-end databases. Many problems arise due to DBAs giving carte blanche to these accounts in order to make developersâ lives easier. But these super accounts are very vulnerable to attack and greatly broaden the risks to databases posed by SQL injection and other Web app-based attacks.
âYou definitely want to run all of these accounts that serve as a Web account that have access to the back-end database at really low privileges so that they can really only access the data that theyâre supposed to access,â Rothacker says. âYou want to make sure they donât have any rights to make changes on the database.â