Injection is, by far, the most dangerous attack that we could be exposed to. Specifically, a SQL injection is the most common form of injection that affects applications and it consists of an attacker forcing a SQL code in one of our application queries, leading to a different query that could compromise the data of our company.

There are other types of injections, but we are going to focus on SQL injection, as pretty much every application in the modern world uses a relational database.

SQL injection consists of the injection or manipulation of SQL queries in our application through the input from non-validated sources, such as a web form or any other data source with arbitrary input of text.

Let's consider the following example:

SELECT * FROM users WHERE username = 'username' AND password = 'password'

This query will give us the user that corresponds to a given name and password. In order to build the query from the client's input, we can consider doing something similar to the following code as a good idea:

var express = require('express');
var app = express();
var mysql      = require('mysql');

var connection = mysql.createConnection({
  host     : 'localhost',
  user     : 'me',
  password : 'secret',
  database : 'test_db'
});

app.get('/login', function(req, res) {
  var username = req.param("username");
  var password = req.param("password");
  
  connection.connect();
  var query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
  connection.query(query, function(err, rows, fields) {
    if (err) throw err;
    res.send(rows);
  });
  connection.end();
});

app.listen(3000, function() {
  console.log("Application running in port 3000.");
});

At first sight, it looks like an easy program that accesses the database called test_db and issues a query to check whether there is a user that matches the username and password and renders it back to the client so that if we open the browser and try to browse to the http://localhost:3000/login?username=david&password=mypassword URL, the browser will render a JSON object with the result of the following query:

SELECT * FROM users WHERE username = 'david' AND password = 'mypassword'

Nothing strange yet, but what happens if the customer tries to hack us?

Take a look at the following input:

http://localhost:3000/login?username=' OR 1=1 --&password=mypassword

As you can see, the query generated by it is the following code:

SELECT * FROM users WHERE username = '' OR 1=1 -- AND password = 'mypassword'

In SQL, the -- character sequence is used to comment the rest of the line so that the effective query would be as follows:

SELECT * FROM users WHERE username='' OR 1=1

This query returns the full list of users, and if our software is using the result of this query to resolve whether the user should be logged in or not, we are in some serious problems. We have just granted access to our system to someone who does not even know a valid username.

This is one of the many examples on how SQL injection can affect us.

In this case, it is pretty obvious that we are concatenating untrusted data (coming from the user) into our query, but believe me, when the software gets more complicated, it is not always easy to identify.

A way to avoid SQL injection is through the usage of prepared statements.

app.get('/login', function(req, res) {
  var username = req.param("username");
  var password = req.param("password");
  
  connection.connect();
  var query = "SELECT * FROM users WHERE username = '" + connection.escape(username) + "' AND password = '" + connection.escape(password) + "'";
  connection.query(query, function(err, rows, fields) {
    if (err) throw err;
    res.send(rows);
  });
  connection.end();
});

var mysql = require('mysql');
var connection = mysql.createConnection({
  host: 'localhost',
  username: 'root',
  password: 'root'
});

console.log(connection.escape("' OR 1=1 --"))

Cross-site scripting, also known as XSS, is a security vulnerability that mainly affects web applications. It is one of the most common security issues and the implications can be huge for the customer as potentially, someone could steal the user identity with this attack.

The attack is an injection code put into a third-party website that could steal data from the client's browser. There are a few ways of doing it, but by far, the most common is by unescaped input from the client.

In few websites on the Internet, users can add comments containing arbitrary input. This arbitrary input can contain script tags that load a JavaScript from a remote server that can steal the session cookie (or other types of valuable information), letting the attacker replicate the user session on a remote machine.

There are two main types of XSS attacks: persistent and non-persistent.

The persistent type of XSS consists of storing the XSS attack by crafting a particular string of text that resolves into the attack once it is displayed to the user in the website. This code could be injected via an arbitrary input text that is stored in the database (such as a comment in a forum).

The non-persistent type of XSS is when the attack is inserted into a non-persistent part of the application due to bad data handling.

Let's take a look at the following screenshot:

As you can see, we have searched for a book (this book) in http://www.amazon.co.uk/. It does not produce any output (as the book is not published yet), but it specifies that Your search "microservices nodejs" did not match any products, which is somehow using the input from the web browser as output. Even more, when I clicked on search, Amazon redirected me to the following URL:

http://www.amazon.co.uk/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=microservices+nodejs

We know Amazon is secure, but if it was sensible to XSS attacks, we could have modified the value of the field-keywords parameter to craft a request that injected a script tag in the content, leading to the attacker being able to steal the session cookie that could result in some serious problems for the website.

Cross-site request forgery (CSRF) is the reverse of cross-site request scripting. In cross-site request scripting, the problem is in the client trusting the data coming from the server. With cross-site request forgery, the problem is that the server trusts the data coming from the client.

After stealing the session cookie, the attacker can not only steal information from the user, but can also modify the information of the account associated with the cookie.

This is done by posting the data to the server via HTTP requests.

HTTP classifies its requests in methods. A method is basically used to specify what is the operation to be carried by the request. The most interesting four methods are the following ones:

There are more methods (such as PATCH or CONNECT), but let's focus on these four. As you can see, three of these four methods modify data from the server, and a user with a valid session could potentially steal data, create payments, order goods, and so on.

A way to avoid the cross-site request forgery attack is by protecting the POST, PUT and DELETE endpoints with a cross-site request token.

Take a look at the following HTML form:

<form action="/register" method="post">
  <input name="email" type="text" />
  <input name="password" type="password" />
</form>

This form describes a perfectly valid situation: a user registering on our website; very simple, but still valid and flawed.

We are specifying a URL and the list of expected parameters so that an attacker can register hundreds or thousands of accounts within a span of minutes, with a small script that issues a POST request with the two parameters (email and password) in the body.

Now, look at the following form:

<form action="/register" method="post">
  <input name="email" type="text" />
  <input name="password" type="password" />
  <input name="csrftoken" type="hidden" value="as7d6fasd678f5a5sf5asf" />
</form>

You can see the difference: there is an extra hidden parameter called csrftoken.

This parameter is a random string that is generated every time a form is rendered so that we can add this extra parameter to every form.

Once the form is submitted, the csrftoken parameter is validated to only let go through the requests with a valid token and generate a new token to be rendered on the page again.

Sometimes, our application might need to redirect the user to a certain URL. For example, when hitting a private URL without a valid authentication, the user will usually be redirected to the login page:

http://www.mysite.com/my-private-page

This could result into a redirect to the following:

http://www.mysite.com/login?redirect=/my-private-page

This sounds legit. The user is sent to the login page, and once he provides a valid set of credentials, it is redirected to /my-private-page.

What happens if someone tries to steal the account of our user?

Look at the following request:

http://www.mysite.com/login?redirect=http://myslte.com

This is a crafted request that will redirect the user to myslte.com instead of mysite.com (note the l instead of i).

Someone could make myslte.com look like the login page of mysite.com and steal your user's password and username by distributing the preceding URL in the social media as the users will be redirected to a malicious page.

The solution for the preceding problem is quite simple: don't redirect the user to untrusted third-party websites.

Again, the best way of doing such task is white listing the target hosts for redirects. Basically, we don't let our software redirect our customers to unknown websites.