Início > Programação, Tecnologia > Protecting your HTML forms from SQL Injections

Protecting your HTML forms from SQL Injections

sql_injectionSQL Injection is one of the most common attacks your website can receive. Yet, there are a lot of programmers that do not give special attention to it. In this post, you will understand how SQL Injections are make (with examples) and how you can protect your applications from it.

SQL (Structured Query Language) is the most common language used to retrieve and put information into relational databases. The most famous databases all use it, like MySQL, Oracle, PostgreSQL… Also, SQL is really easy to learn. With that in mind, isn’t absurd to assume that a huge percentage of the web applications around the Internet use SQL.

Let’s start the examples with a simple login page. It will be use to exemplify all next examples:

form

And here is the database (I’m using MySQL, but you can use any DBMS you like):

sql_databases

From now on, on the server side, I’ll be using JSP and Servlets to handle the login stuff, but you could also use any other server-side language (like PHP and ASP). Here is the Java class that will handle the authentication:

java_total

Now, we can make the login into the system by using the user “User_here” and the password “password123”.

The server side authentication expects something like this:

SELECT sqlinjection.id FROM sqlinjection WHERE BINARY sqlinjection.user = ‘X’ AND sqlinjection.password = ‘Y’

Where X is the value you put into the field “User” and Y is the value you put into the field “Password”. So, when you type the correct username and the correct password, the expression above turns out into this:

SELECT sqlinjection.id FROM sqlinjection WHERE BINARY sqlinjection.user = ‘User_here’ AND sqlinjection.password = ‘password123’

But, what if the person (the attacker) just know your username and have no idea what your password is? They could use SQL Injection to make the login without knowing the password. On the user field, the attacker would type User_here and, on the password field, they could type something like: a’ or ‘1’=’1. So, your SQL would turn out into:

SELECT sqlinjection.id FROM sqlinjection WHERE BINARY sqlinjection.user = ‘User_here’ AND sqlinjection.password = ” or ‘1’=’1′

Which is the same as:

SELECT sqlinjection.id FROM sqlinjection WHERE BINARY sqlinjection.user = ‘User_here’ AND (sqlinjection.password = ‘a’ or ‘1’=’1′)

That means if the password is ‘a’ OR ‘1’ = ‘1’ than the right part of the AND will be true. Once 1 is always equals to 1, than (sqlinjection.password = ” or ‘1’=’1′) will always be true. Bingo! The attacker has successfully entered into your system just by knowing your username.

But it could be worse. The attacker could even delete your table. They could type something like this into the password field: a’; DROP TABLE sqlinjection —

So, the SQL would turn out into: SELECT sqlinjection.id FROM sqlinjection WHERE BINARY sqlinjection.user = ‘User_here’ AND sqlinjection.password = ‘a’; DROP TABLE sqlinjection — ‘

SQL Injection Webcomic

Following this idea, the attacker could also delete an entire database. They could type something like this into the password field: a’; DROP DATABASE injection

Now, I know what you’re thinking: “How does the attacker would know the name of my tables and my databases?”. That’s simple: they can find that out by making a statement syntactically incorrect. For example: if you type anything’ into the password field, that will turn out on the following SQL:

SELECT sqlinjection.id FROM sqlinjection WHERE BINARY sqlinjection.user = ‘X’ AND sqlinjection.password = ‘anything’

That SQL is syntactically incorrect (because of the double ) and, as a result, an error will be thrown. If that error is not appropriately catch, then it will be showed on the screen. That is more than enough to find the tables (and the databases) names.

The video below shows a SQL Injection attack been made:

So, how to protect your applications from SQL Injection attacks?

That’s the most simple part. You can deny all kind of strings with contains , and ;. Also, you can limit the size of the data been received. The most important thing is: make sure that all of those verifications are made on the server-side (otherwise the attacker could pass through it easily by editing your page’s source code or even by making a HTTP request from scratch).

That’s it! If you have any question, feel free to ask.

PS: If you detected some mistake in any part of my post or in my English, please, send me an email or a comment correcting me! I’m Brazilian, so I’m not an English native speaker. I would really appreciate being corrected! Thank you in advance! :)

Anúncios
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s

%d blogueiros gostam disto: