Sanitize your Inputs.
If you’ve been following cyber security news over the past few months, you’ve probably seen ‘SQL Injection’ somewhere. It’s usually in reference to a security failure – maybe a breach happened, and you saw it written in the post-mortem of the attack. What is it?
SQL
What is SQL? SQL stands for ‘Structured Query Language’. It’s widely considered the language of databases! Essentially, SQL is really good at handling structural data, which is data that keeps the relationships between variables coherent. SQL is more like an umbrella term than a thing in and of itself: language for controlling data, language for relating data, language for defining data, etc. all fall under the scope of SQL. Different vendors also have different methods of implementing SQL, so even SQL that does the same thing across websites may look different. It’s basically everywhere!
Especially on the back-end side of websites. Passwords and login info have to be stored somewhere, and preferably somewhere where they are A) secure and B) accessible. That’s not as simple as it sounds. If a website stores its data in a simple table, with no hiding, hashing, or scrambling of the credentials, it’s only a matter of time before some malicious party comes for it. Hashing is mandatory nowadays, and in fact, hashing and hiding data is often the only thing turning major breaches into minor events. See Blizzard’s hack, for instance – having the data somewhere else and scrambled saved them. Proper SQL usage saved them.
Retrieving that information is also important, and SQL does that too. SQL specializes in uniting all of these tasks. However, it’s widespread use doesn’t mean it’s invulnerable, and mistakes while putting it together for a site can render it a dangerous weapon.
SQL Injection
An SQL injection is an attempt to interfere with the requests the SQL is sending to the database. If a hacker can deliver a little bit of code to that otherwise impossible-to-reach database, they may be able to grant themselves access to it, or damage it, among other things. For example: a new user signs up. They put their name and password in. SQL directs that information to the database with the instructions “Store this (USERNAME)”. However, in an injection attack, the username actually contains code, which then leads to the SQL misreading the instructions as “Store this (AND DELETE ALL DATA)”.
These are so incredibly simple to execute that it would be foolish not to try at least a couple of times. It’s as simple as figuring out what kind of inputs the data field will allow (i.e are semicolons allowed in passwords? Can I use @ in my username? Are brackets included, or not?) and then trying to abuse that as hard as possible to get results.
Even big websites are susceptible. Why? The process to prevent it is separate from the process of putting SQL into the website in the first place. Picture trying to drive a car with no automatic headlights at night. Eventually, you may forget to turn them on manually – and that may cause an accident even if you’re an otherwise excellent driver. Turning the headlights on, or sanitizing the inputs, is the safest way to prevent harm from coming to that database behind the scenes, but it’s easy to forget.
Sanitizing Inputs (Or Making Them Unreadable)
This method of hacking doesn’t work if the program doesn’t see the code. Now, there is some contention as to what sanitizing actually means specifically – generally, it means make computer not read input wrong, which can be achieved in a number of ways with coding.
There’s telling the database to convert data, which may produce undesired results in the database.
There’s telling the code that’s taking the input to split the query used to ask for data and the resulting data itself apart, which prevents that data from being misinterpreted as a command.
And then there’s simply not allowing certain things to be used in the input fields, which is kind of sanitizing by elimination.
If the database never gets anything it doesn’t expect, then it can’t do things that its programmers weren’t expecting, thereby making it safer. Validating the inputs is equally as important to prevent attacks! You’d never see letters in a phone number or brackets in a name, anyway, so this is also good for the data itself.
Sanitizing, validating, or otherwise controlling inputs, no matter how a business decides to approach it, is good for database security. However, it’s often difficult to do right if the website is assembled by the business owner themselves. Luckily, Wix, Squarespace, and other big DIY-website places do this automatically. The folks in the most danger are people and companies with just enough expertise to make a public-facing webpage from the ground-up, without enough expertise to secure it ground-up.
Dangerous, Even Now
Technology improves, and some things get better.
And then there’s things like sanitizing inputs. The code may be cutting edge, the machines themselves may be top of the line, but forgetting to include some verification for data is just like forgetting to put out a candle before leaving your house for the day. The action is insignificant… the consequences are not. And, just like candles, there isn’t really tech that turns that off. Either you blew out the candle, or you didn’t. If you’re lucky, nothing happens while it’s unattended.
SQL injections have compromised tens of millions of files of legal and healthcare data around the world because they’re so simple! It’s easy to automate, and often overlooked. It’s painfully easy to introduce weaknesses via plug-ins as well – WordPress has over 50,000 plug-ins, and many are outdated or obsolete when it comes to SQL security, so using a DIY website designer is no guarantee of safety if the customer strays too far outside the presets.
SQL injections are a big threat that’s easy to avoid… if the website creator knows to look for it. Free resources for fixing vulnerabilities scatter the web, but nothing beats expertise. (Don’t just slap something into a site willy-nilly – go to an expert!)
Sources: https://www.veracode.com/security/sql-injection
https://kevinsmith.io/sanitize-your-inputs/
https://www.smashingmagazine.com/2011/01/keeping-web-users-safe-by-sanitizing-input-data/