This post is a little more technical than our norm but I think it’s important to understand some of the buzzwords around security. SQL Injection attacks (pronounced see-kwel) are a tactic that a hacker can use to get your computers to do more than they should.
SQL stands for Standard Query Language and is the code that almost all databases use when answering your questions. SQL is what brings up your account when you log onto your bank to see your latest statement. Any but the most rudimentary website uses a SQL database to hold, sort and present the content to you, the reader.
As long as the user plugs in things that make sense (like a name into the username field), the query will run properly and will return only the results for your account. But what happens if you type something unusual into that field? What if you put in an account number instead? If the website was well-designed, the request will simply fail. If, however, the website was not designed properly, the computer may return something – but it won’t be anything that you intended.
For example, a hacker might try typing ' OR 1=1 -- into a date field. The “OR 1=1” part will always be true. The -- characters tell the computer to consider everything after as a comment (that is, a note the programmer left to him/herself as an explanation of the code). The result is a request for all lines of data where the first part is true. But 1=1 is always true so the computer spews out all the data in that table. Not only does the hacker get his own account details, he gets yours and everyone else’s as well.
Other commands can be crafted to modify data, add tables, execute commands, etc. If a site is vulnerable to a SQL-injection attack, there is little that the hacker can’t do.
How do you stop it? The easiest way to prevent a SQL-injection attack is to design your application to validate its inputs. The username field should have only text characters (or maybe also some numbers but nothing that looks like computer code), the credit card number field should only accept numbers, etc. Define the acceptable character sets and enforce those whitelists. Force the inputs to conform to specific patterns when special characters are needed (i.e. dd-mm-yyyy). And validate the data length of all inputs.
These are all basic checks that the folks building your website should be making. Put the IT processes and controls in place to make sure that they are building you a quality product and won’t leave your data vulnerable to the world.
By the way, to test whether a site has their own security in place, type something unusual into a field and see what happens. If you get a simple error telling you the allowable format (or if the computer simply rejects the request), you’re probably okay. If you see a lot of computer gobbledy-gook, you might not want to let that company have your confidential data.
Leave a Reply