Posts Tagged


SQL Injections

Elizabeth Uncategorized October 13, 2021

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?


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!)


Small Sites Vs. A Big Internet

Art projects


Some little art project websites deliberately avoid indexing their page, so it’s well-hidden from traffic. Web development classes, modern art classes, and all sorts of other classes will ask students to make something online. They don’t necessarily want those websites getting shared outside of the class. Keeping a page un-indexed makes it much harder to stumble upon, but it’s not a perfect cure – people with the direct link can still post it elsewhere. If they retain it after they leave the class, and remember how cool it was, and then it ends up on Reddit… suddenly it’s a curse, especially if identifying information like names are left on-site.

Websites made as a joke in the first place can turn into a curse too! Youtuber Drew Gooden’s “Hot Dog” website was made as part of an advertising campaign for Wix, but it’s unclear if he actually wants to maintain it. It’s still in his ownership today. This is a unique problem to have! It may cause him more issues to close the site, now that it’s address has been immortalized in videos. Besides, they’ve come to expect the website to function, they’ve bookmarked it, and they’re demanding that their entertainer dance.


Real Retail Hours


Tiny DIY shopping websites sometimes get cratered by that same ‘hug of death’, especially if they accidentally go ‘viral’. Look at TikTok advertisers for example: anyone can post, and because of the app’s algorithm, it’s possible for a creator with no followers to suddenly end up with 100,000+ views on a particularly entertaining video. No ad dollars were spent, the creator was just super funny that day and it spread. This is great! Until their traffic jumps from an expected 500/day to 20,000/day, because their product has gotten much more reach than they could have prepared for. Sellouts are inevitable, frustrated users are also inevitable.

In fact, a broken or slow website will even push away people who did get to make a purchase. Unpleasant shopping experiences steer consumers away from online retailers at a horrifying rate! The same goes for lag – mobile users are unwilling to wait for an item they don’t really want, or don’t really need from that specific store. I could get a hat anywhere, for instance – why should I wait five seconds to get through to a store on mobile when I could go ding a different store? Obviously it’s not that simple, but big websites have resources that little ones don’t, and the especially wishy-washy buyers will be put off by the difference in experiences.

There are ways to handle this, but unfortunately many businesses don’t have the chance to prepare.


Welcome, But…


And then there are websites that are really hoping for growth, and it suddenly happens. It’s rare to have a site blow up overnight – most repeat visits are the result of hard work and consistent effort to capture the visitor’s attention. Unfortunately, in this era of social media, it’s very easy to accidentally blow a website out of the water. Yay, Growth! Turns into Oh No, They Aren’t Stopping. The server for the website crashes, and a lot of potential viewers are shut out from it. If the website’s lucky, the interested folks will bookmark the page and come back, so they’ve got a better distribution the second time around.

Some websites go offline a few hours after Reddit’s discovered them, to recover. The ‘hug of death’ is a well-known phenomenon – nobody’s DDoSing the website on purpose!


Lonesome Town


Single-person websites are often hoping to not be discovered by somewhere huge. Think about it: if they haven’t paid for advertising, if they don’t get revenue from hosting ads, if they don’t sell anything on their site, then they don’t make money from page views. They’re probably not looking for a giant spike in page views out of nowhere, with some exceptions like ‘public service’ projects made by civilians, or ARGs.  

 Tiny websites and tiny forums alike struggle to handle being “discovered” on websites like Reddit, Digg, or Youtube. Famously, a Buffy the Vampire superfan’s website (which I’m deliberately not linking here) was crashed by new visitors after forums made it a spectacle. Sure, the superfan posted a lot – as is their right. The information they posted helped other fans find information about meetups and appearances by the actors. The flood of people showing up on other social media to comment on and harass the single poster was unfortunate, and it could have been avoided if people hadn’t dogpiled. Even deeper, maybe people wouldn’t have dogpiled if the website hadn’t shown up on blogs. The sole commentator, maintainer, and moderator made the website private after people showed up to screw around.


Similarly, small sites get flooded when a big site ‘discovers’ them, and then suffer from community collapse and site breakdown. A forum with 200 or so regular posters isn’t going to be able to moderate new conversations from other, bigger sites – and even worse, newcomers who might have been interested in the topic get the idea that the website’s a total dumpster fire when it’s just understaffed. These sites want traffic, yeah, but they want the right kind of traffic. Well-intentioned traffic. On-topic traffic. If a community behaves itself, there’s no reason to have a team of 20 moderators. People showing up to flame the forum are going to stretch resources thin.

Don’t go spread news about some wacky website on big forums without knowing the site first. The consequences may be greater than you could imagine!