Secure Your Web Application With OWASP

What Is Injection?

We're talking about the number one top attack here! 👿

I talked about getting an injection in the doctor's office, but we need to talk about securing your code from attacks. What does it mean to have an injection attack on your web app?

Injection is when an attacker is injecting code, a script, or command using your web application.

Some common injections are SQL queries to manipulate the database, Javascript and HTML scripts executed in your web app, and Operating System (OS) injections that control your OS! An injection on a web application is like an insertion. You are inserting something into the web page.

Anywhere you are allowed to type in text and hit the Enter key.  

For example, instead of putting in a username and password on a login page, a malicious user will input an SQL command to delete parts of the database.  This malicious command is called a SQL injection attack.

Injection attacks are one of the oldest methods used to attack a business. Did you know that over half of the hackers today use an injection attack?

An injection attack can be used to take down an entire system, access files, and delete them. It causes a lot of damage, and all a hacker needs is a place to input code in an application.

All web applications typically connect to another system and that system is the target of the injection attack. For example, if a criminal wants to run a terminal window on an operating system, a command to run it will be injected through an application running on the operating system. Once a criminal gains access to the terminal window with access rights, it’s game over.

The most famous type of injection attack is the aforementioned, SQL injection. This attack will use the web application to send a database query to the database.

Can you guess what the target of that attack would be?

In this case, the database is the target of the injection attack!

Let’s consider the following SQL query:

SELECT * FROM accounts WHERE username='$username' AND password='$password'

• SELECT is a command in the query that will choose from some options.

• The * key is is a wildcard, so it will choose everything.

• FROM chooses the database table you will use; accounts is the name of the table!

• WHERE specifies what you want to select.

• username='$username' AND password='$password' is the specific parameter this query is looking for.

For example, let’s say someone set up an account with the username: WonderWoman, and the password: ILoveSuperman.  When the input SQL query carries  SELECT * FROM accounts WHERE username='WonderWoman' AND password='ILoveSuperman', the statement would be true because of the AND operator.  If the input was  SELECT * FROM accounts WHERE username='WonderWoman' AND password='ILoveAquaman', it would be false, because the username AND the password are not correct.

This is a normal query used with people that work with databases; however, hackers have found a way to use it to their advantage. In an SQL injection query, this type can be jumbled up a little bit. It will look strange, but it actually works!!!!

Let’s take a look at some malicious code that pulls up every username and password!

$username = 1' or '1' = '1’

$password = 1’ or ‘1’=’1’

This is called a conditional statement in programming languages.

In this statement, $username = 1 is compared to the statement ‘1=1’. Since $password  is now equal to 1, the statement, 1 or 1=1 ends up with a true value.

In conditional SQL queries, the output always depends on what is true in the query, so in the following statement:

SELECT * FROM accounts WHERE username='1' or ‘1’=’1'

Cybercriminals tell the database what the username and password is, and they are true for all the usernames in the accounts table. Now those criminals have access to all the accounts!

On top of that, they can add another clause to the SQL query to delete all the accounts! This is how that SQL injection attack would look:

SELECT * FROM accounts WHERE username='$username' AND password='$password'

These warlords have tricked the web applications database into authenticating them and are logged in as anyone they want to be!

How Can I Prevent It?

A lot of people may tell you that having a good Web Application Firewall (WAF) should prevent most of these attacks. It’s like having an antivirus on your computer. But, if you securely code your web application to make it difficult, won’t that lessen the chance of an issue?

Think about it.

What if you had an antivirus, so you decided it should be fine to download viruses. You wouldn’t do that because you know that your antivirus might not always work, right? So what are some ways you can keep your database safe?

Every framework has libraries that are created for security.  Integrating the functionality from these libraries, plugins, and modules into your code can ensure that you can secure your code.  You should research what is available based on your language.

Let’s take a look at some of the best practices.

Input Validation

Input validation is a great practice as a web developer.  It limits what the user can put into the text box. Have you ever gotten frustrated when creating an account because it won’t accept the password without numbers or capital letters?

That is because input validation was coded in; the input is parsed and analyzed after you hit Enter. In the same way, coding your input to not accept anything outside of what is required can help. It won’t prevent an injection, but it is one step you can take.

What kinds of characters can we limit?

If you said the equal sign and the single quote, you are on the right track!

Parameterize Your Variables!

You can write your SQL queries by parameterizing the variables, or binding them. This is also called a prepared statement.  Now, what on earth does that mean? Let’s look at the previous example.

SELECT * FROM accounts WHERE username='$username' AND password='$password'

This statement can be parameterized by binding the variables: username, and password.

Right now, the code connects $username directly to the database.  When you connect a variable directly to the database, you make it vulnerable to injection.  With variable binding, the code would now look like this:

SELECT * FROM accounts WHERE username='@username' AND password='@password'

The username and password variables are parameterized, so they will now be passed into a method to run the query instead of connecting directly to the database.

$username = setUser(username)

$password = setPassword(password)

There are many ways to do this, but since the query does not connect directly to the database, it is one of the best practices in securing your input from SQL injection.

Should I Use Stored or Dynamic SQL Queries?

When coding the input on your web application, you have to write a SQL procedure so the database will know what data to pull.  There are two ways to do it: stored and dynamic. 😊

Your input can call a stored procedure in the database such as with the previous examples. This is one way to secure your input in a world where dynamic SQL queries are targeted.

So, how can you secure dynamic SQL queries?   You can use the function sp_executesql inside your dynamic SQL procedure. Look at the implementation with parameterized variables below to see what I mean.

CREATE PROCEDURE sp_owaspLogin

@bind_username varchar(10)

@bind_password varchar(10)

AS

BEGIN

DECLARE @myquery varchar(100)

SET @myquery = N’SELECT login FROM accounts WHERE username = @username AND password = @password’

DECLARE @bind_user nvarchar(10) = N’@username’;

DECLARE @bind_pass nvarchar(10) = N’@password’;

EXEC sp_executesql @myquery, @bind_user, @username = @bind_username;

The above dynamic SQL query binds the variable as well as thesp_executesql function to secure the script.

Use an Object Relational Mapper (ORM)

Many languages have Object Relational Mapper (ORM) tools that can obfuscate your query.  ORM modules such as pg and knex can be used with Javascript frameworks.

Let’s consider the SQL query:

SELECT * FROM accounts WHERE username='@username' AND password='@password'

First, note that @username  and @password are parameterized!

Here’s an example of how a proper query will run through your web application using knex Node.js

knex('accounts').where('username',wonderwoman ).orWhere({password: ilovesuperman , user: 'knex'})

In the above code,  knex obfuscates the query.  That means that it hides how the SQL query really looks. Think of it this way: You write a sentence, and it gets sent over jumbled up but makes sense when read by its intended user. It might be a little work, but you should try it out!

OWASP Has a Library!

The OWASP organization has a library called The OWASP Enterprise Security API (ESAPI) can be used to secure your web applications, so check it out to see if it works with the language and database that you are using!

Let’s Recap!

• Injections can include (but not limited to) SQL, Javascript, HTML, or OS commands.

• They work by using a form of input on a web application to connect to another system and manipulate it.

• You can prevent injection attacks by securing your code with input validation, parameterized variables, ORM, and stored SQL procedures.

• Dynamic SQL procedures can be unsafe, so be sure to use the executesql() function in the database to secure them.