I started my career with a software development company as a software tester in 2002. Back then, much less was generally known about web application security, and there were much fewer tools to help you keep your code clean and hackers out of your site. As a software tester, I got a few thrills when locating critical defects in software, but my favorite ones by far were security vulnerabilities. If I could get into your site without logging in, or perhaps worse, gain complete access to your data through a simple text box, those were my favorite days of software testing.
Now sitting on the other side of the fence as a software developer, I have to ensure that the work I create does not have these same vulnerabilities. Fortunately, software development tools have gotten better and most of the common security vulnerabilities from years ago are easily avoided now.
I want to quickly touch on one of the worst web application security offenders from back in the day: SQL Injection (database query injection). Imagine a programmer created a line of code in your site’s login function that looks similar to this:
user = RunDatabaseQuery(“select * from users where username=’” + Username.text + “’ and password=’”+ Password.text + “’”);
The programmer would then check that the user looks good and if so, they would log the person in. The problem with the line of code above is that the Username and Password came directly from the inputs on the webpage. In a normal circumstance it might execute a database query such as:
select * from users where username=’mike’ and password=’ilovecats’
However, a clever hacker could simply type in other values to really mess up your query since you are just taking their input and using it. What if the password was:
‘;delete from users;–
Then the resulting query that gets run from the bad code above would be:
select * from users where username=’mike’ and password=’’;delete from users;–
You do need some knowledge of how database queries work, but basically the second query just terminates the first query, which likely won’t return any results (no user mike with a blank password) AND actually adds on another command to the end…To delete all your users! The trailing dashes on the query also “comments out” any SQL code that may be after the password check so that it’s not executed.
So clearly, if this type of problem exists in your website, users do have the potential to cause major issues. In this example, they just deleted all the users in your system just by typing in the right password into your login form!
The good news is that most modern development tools protect against these types of attacks with tools such as Entity Framework (in .NET) or the Laravel framework (PHP) as well as others. These frameworks get added right into the development environment and allows programmers easier ways to query the database without a possibility of an injection attack such as this.
The bad news is that there are still MANY websites in existence that were created several years ago that might still have this type of issue. Unfortunately, it’s not always as clear as the example shown above, and it may not be on a login page. It could in theory be on any input field that gets posted to the server if they are using it in conjunction with the database.
Fortunately, with access to the source code, this is a very easy problem to identify, and not too difficult to correct.
If you suspect you have web application security issues such as SQL injection, or anything else, you can always contact us at www.wddsoftware.com to take a look and get it fixed asap!
P.S. – Now that you understand SQL Injection a little better, enjoy this great web comic!