#SQL101: Raising awareness of SQL injection

(Image credit: XKCD.com)

I don’t think there’s an experienced web developer or DBA who isn’t familiar with the classic “Bobby Tables” XKCD cartoon above. Just about any time you mention “Bobby Tables” to most experienced IT people, (s)he will immediately know to whom you are referring. Most experienced web developers and DBAs are aware of SQL injection and will take steps to ensure that it’s addressed. Grant Fritchey has a presentation about SQL injection (you can view and download his slide deck here) in which he’s not shy about his desire to “kill Bobby Tables.” I’ve seen him present it at SQL Saturday, and I highly recommend it.

Of course, the keyword here is “experienced.” For people who don’t have that experience, and who build websites that connect to databases, I think it should be lesson #1. Today, I had an experience that reminded me of that.

Earlier today, my sister texted me, asking for help with editing SQL code. She asked me what I use to edit SQL. I told her I generally use SSMS, although you can edit SQL code with a straight-up text editor, if necessary (she is not a DBA, so I felt somewhat comfortable telling her this). She told me she had to clean up spam comments in her data.

That last comment immediately grabbed my attention. I then asked her, how are your security settings, and do you have data backups.

She told me: that IS her data backup.

If her earlier comment had gotten my attention, this one immediately set off alarm klaxons in my head.

I started thinking about what could have corrupted her data to this extent. I started asking questions about her admin setup (I should’ve asked her to make sure she wasn’t using “sa” or “admin” as her admin login — Sis, if you’re reading this, make sure you check this!), including her passwords. Her admin password was pretty secure (thankfully).

She then mentioned her website. I asked if her website was accessing her data. She said yes.

I asked her about Bobby Tables (admittedly, in my advancing age, the term “SQL injection” didn’t immediately come to my mind). Her response: “who?”

At this point, I was convinced that I had my answer. Her database had been corrupted through SQL injection attacks. I told her to make sure you address your SQL injection issue before you even think about your data backups. Worrying about your data backups before addressing your SQL injection issue is like trying to rebuild your house before you’ve put out the fire.

I’ve been talking about SQL injection all throughout this article. For a brand-new web or database developer who has no idea what SQL injection is, here’s a quick primer: it’s a data security attack in which a hacker breaches your database by sending SQL commands through your web interface. I won’t get too much into how it works; instead, here are a few links that explain what it is.

• SQL injection (Wikipedia)
• SQL injection (OWasp)
• Running an SQL Injection Attack – Computerphile (YouTube video)

And make no mistake: SQL injection attacks can cause major damage.

So consider this a warning to any fledgling developers who are interested in web or data development: data security issues, such as SQL injection (and there are many others) are a big deal and need to be considered when building your setup; it’s not as simple as just setting up your website and connecting it to a database. By not considering this when you first assemble your system, you might be setting yourself up for major issues down the road.

Advertisement

I “speak” Oracle. Can I go to SQL Saturday?

I’ve been involved with SQL Saturday for a while — since 2010, to be exact — and have worked with SQL Server for even longer than that. However, I currently work in an Oracle environment. This likely begs the question: if I work in Oracle, is SQL Saturday still worth my while?

The short answer: yes, absolutely!

The longer answer: there is more to SQL Saturday than just SQL Server.

Although Oracle and SQL Server are different platforms, they are both relational databases. Granted, there are differences between the two — having worked with SQL Server for so long, I’m still trying to grasp some of the concepts of Oracle. However, many of the concepts between the two relational databases are the same. Both databases share the same SQL language — albeit with some differences (akin to, say, differences between American and British English). Table structures are largely the same (again, there are differences, but they share enough similarities that knowing one allows you to grasp the other).

While differences persist between the two environments, cross-pollination between them is not necessarily a bad thing. Understanding their differences can often lead to a better understanding as to how they work.

On top of that, SQL Saturday is more than just the technologies. Speakers, myself included, present on a variety of topics that aren’t limited to just SQL Server. A number of speakers present on BI topics (some SQL Saturdays, in fact, are BI-specific; look for any event labeled “BI Edition”). Other topics include strategy, architecture, disaster recovery, and professional development. (As I’ve stated time and again, my own presentations are all professional development talks; they have nothing to do with SQL Server.)

And SQL Saturday isn’t just about attending presentations and learning. SQL Saturday is a huge opportunity for networking, which is essential for surviving today’s professional market. I’ve written and presented extensively about the importance of networking. A number of other people have also presented on the importance of networking; for PASS events, I highly recommend Matt Cushing‘s presentation about getting ready for a SQL event!

And if that’s not enough, SQL Saturday is just plain fun! I always have a blast at every event I attend!

So even if you work with Oracle, or NoSQL, or Access, or whatever your database of choice, SQL Saturday likely has something for you. Find an event near you, and come join us in the community!