Why the repetition? It's that serious a threat. As the number-one exploit on the OWASP Top 10 list of digital security issues (and one of the easiest attacks to successfully pull off), injection is a major tool for novice scripters and skilled hackers alike. With little more than basic knowledge and a sufficiently vulnerable target, black hat types can use the technique to do all sorts of nasty stuff: view users' log-in details, access sensitive info stored in a compromised database, make unauthorized changes to an app's or site's content — the list goes on and on and on.
In other words, relative ease of use and hugely detrimental results make injection an exploit worthy of any web- or mobile-app developer's concern. A combination of smart administration, solid coding and that good old-fashioned security awareness we keep talking about goes a long way toward keeping any vulnerabilities in check — and as anyone who has suffered the ill effects of an injection attack will tell you, wrangling your apps in such a way is a very good idea.
At its core, SQL injection is all about taking parts of a site or app designed for one purpose and exploiting them to view data or access functions the developers never intended to make available. SQLZoo compares the process to "solving a puzzle that is a cross between Hangman and 20 Questions"; by simply plugging various SQL queries into user-input areas, noting the results and applying a little deductive reasoning, a malicious visitor can cause tons of trouble.
The SQLZoo link above has a good, if simplified, example of the concept at work: Using simple SQL queries, the site walks a user through a constructed environment where it determines the first username listed in a database table and if a given letter is present in that user's password, then finds the letter's location within the password — a repeatable process that allows attackers to figure out someone's entire password with a little persistence.
And that's just one example. In many cases, the exploit is just the first step to nastier stuff: Attackers could use various injection techniques to determine which version of a back-end software program an app's or site's server is running, for instance. From there, they could formulate more specific attacks based on the info they receive, or use acquired administrator credentials to make unauthorized changes or access other sensitive information.
Preventing injection attacks comes down to a few simple concepts, and most of those break down to two key terms: validate and parameterize.
Since SQL attacks are all about using input areas to run less-than-wholesome queries and commands, a safe product will define rules that prevent attackers from monkeying around. As Veracode's cheat sheet says, input should be validated against rules for length, type and syntax, as well as business-specific rules.
Even at a high level, this makes sense. The "safe product" in our example is basically stopping an injection attack by preventing the sort of input that causes that attack. If a site or app needs a user's email address, for instance, it's fair to assume the user won't need 1,000 (or more) characters to do it.
Parameterization is a bit trickier, but it's just as important to the prevention process. In essence, a properly parameterized product (say that one 10 times fast) uses placeholders for the queries it handles instead of allowing users to dynamically interact with the database. This, in turn, gives the database direct instructions on how to act instead of leaving it up to the user to provide the correct input.
Unlike some attacks, where testing a live site or app produces better results, it's far easier to find potential injection issues in the code itself. SQL injection as a term carries a lot of different meanings; where testing the site or app in question may stop a few different types of attack, a look at the code can defend against the issue as a concept. It's a minor distinction in theory, but a huge one in practice.
Understanding the high-level aspects of SQL injection is one thing. Preventing it in an actual production environment is entirely another, and it requires an expert's touch. If you have general questions or want to protect your products from the horrors an injection attack can represent, reach out to security experts who have the experience and knowledge to ensure your code is as injection-proof as possible.
Photo Source: Flickr