 |
By Sandra Carielli, Senior Product Manager, Access and Data Protection It amazes me that SQL injection attacks are still prevalent, much less that they remain one of the most popular forms of attack. You don’t read as much these days about organizations being compromised due to hardcoded passwords, bad cryptography, or buffer overflows; organizations have mostly managed to control those issues via overlying technologies and good coding practices. But SQLi attacks continue to rise. The fact that they are still so popular (and so effective) surprises me because … well, we’ve been talking about SQL injection for so long that I thought that SQLi protections would be institutionalized by now. Ten years ago, I was teaching application security classes to rooms of engineers and explaining the dangers of SQL injection. “Data validation, data validation, data validation” was one of our mantras. But we’re still having trouble doing that 100% of the time. A SQLi attack occurs when an attacker is able to embed SQL commands into a field on a web form; perhaps instead of entering a username at a login page, they enter a carefully constructed SQL statement. If the application doesn’t perform proper data validation and instead just sends this string along to the application database, the attacker is able to execute that command. What sort of commands does an attacker try to execute? A common one is to dump the database, getting them access to most of the data stored in the database: usernames, e-mail addresses … and (probably hashed and salted) passwords. Many people have speculated about the high profile password thefts over the last couple of years and suggested that SQLi may have played a role (in many cases we don’t know for certain, but there are some cases where the attacker has shared their method). What if after executing a SQL injection attack and dumping the database, an attacker discovered that there wasn’t very much of value there? Or that that he needed to find a way to compromise a completely different server (which does not execute SQL commands from an application) in order to reconstruct the information he had stolen? The idea behind distributed security is to increase the cost to an attacker by splitting information among multiple locations and forcing an attacker to compromise each location in order to reconstruct that information. If the data in the SQL database is encrypted, and the encryption key is sitting somewhere else, that’s a form of distributed security. So is RSA’s recently released Distributed Credential Protection, in which authentication credentials are split between multiple servers. It’s like taking a secret formula written down on a piece of paper, ripping it into multiple pieces, and storing each piece in a different safe. Even if the guard in charge of the first safe forgets to lock it one night, an attacker doesn’t steal anything useful. If SQLi attacks are still happening after all these years, perhaps distributed security can reduce the attractiveness of that attack vector. Sandy Carielli leads product management for Distributed Credential Protection and the BSAFE portfolio at RSA, The Security Division of EMC. Ms. Carielli has over ten years of experience in the security industry, including engineering (at BBN Technologies), consulting (at @stake) and product management. Ms. Carielli holds a Sc.B. in Mathematics from Brown University and an MBA from MIT. |
| Update your feed preferences | |
