My last couple of blogs have been pretty heavy going – lots of jargon and definitely not the easiest pieces of text to read if you don’t have much background knowledge on web development. This time I decided this time to try something a little different – I will attempt to explain the 5 biggest threats any website owner should be aware of and try to keep it as simple as possible. Let’s get started!

SQL Injection

SQL Injection is where an attacker maliciously gains access to a database, usually via a front-end or website which is joined to the database in question. If we take a step back for a moment, SQL stands for Structured Query Language and acts as a means of communication between the user of the database and the data stored inside. SQL is certainly not hard to learn; in fact the syntax is relatively straight forward:

SELECT * FROM tblCustomer WHERE customerName = "Casey";

The SELECT keyword is used to read data from the database and the * signifies that we want the database to bring back data for every single column within the tblCustomer table. The second half (just before the WHERE clause) kind of acts like a filter, we only want to see results on customers named Casey so we implement this within the WHERE clause. So far so good?

You see these kind of SQL statements all the time – imagine you’re stalking an old friend on Facebook, behind the scenes the SQL command won’t look much different from the above; however, there is one crucial and incredibly dangerous difference.

SELECT * FROM tblCustomer WHERE customerName = $customerName;

In our first SQL statement, we hardcoded “Casey” into the query, when in reality we need to dynamically grab the name a user is searching for from a form the user has submitted. Above is a quick mock-up of what we could end up with – we pass a variable (which is set to the value a user has searched for) and the database goes off and returns any records which match the search query.

What’s the danger? Well imagine if someone typed the below into our customer search form:

This image has an empty alt attribute; its file name is image.png

Suddenly our query becomes:

SELECT * FROM tblCustomer WHERE customerName = "Casey"; DROP TABLE tblCustomer;

We are no longer running a single query to innocently get customer data back; the attacker has injected an additional query for our database to run. Here we are still receiving a list of all customers called Casey, but once that info has been returned to the user the database immediately deletes the tblCustomer table. This is because the DROP command in SQL is used to delete a table and all of its data contained inside itself permanently. As far as the database is aware, these are two separate and legitimate queries, it has no idea someone is accessing the database maliciously via a web front-end. so it has no reason to doubt the requests.

How Do We Stop This?

Every modern day back-end web language has their own implementation of how to solve this, but the common fix is to implement something called Prepared Statements. Prepared statements take the parts of a query which a user could previously manipulate and tells the database that everything at the location of the placeholder should be treated as text and text only.

Cross Site Scripting (XSS)

Cross Site Scripting is one of the most common attacks currently out there and is such a brutal attack due to the limited options a user has to protect themselves against it.

Every single webpage in the world, at its core is made up of small building blocks which we call HTML. Just like SQL, HTML is pretty simple to get started with, if you want to make some text on a webpage bold then you wrap your text with opening and closing <b> tags like so:


If we want to make something italic, then we stick opening and closing <i> tags around the text

<i> This will be Italic </i>
 This will be Italic 

Cool, nice and simple right?

In HTML we have all kinds of different tags for different purposes, but the tag which causes issues with Cross Site Scripting is the <script> tag. Anything between the two opening and closing script tags will be treated as JavaScript code, which is not meant to be seen by a user and will just be compiled by the browser and quietly run in the background while you view the page.

An example of Cross Site Scripting could be if an attacker left a comment on a poorly designed blog, containing something like the below:

window.alert("You are our 1 millionth visitor!! Enter your details on the following page to claim your prize")

When the attacker submits their comment, the malicious comment is sent off, stored inside of the websites database and the next time someone visits the page the latest comments will be fetched from the database and outputted to the page. If the site has not taken measures to escape the comments and ensure they are treated purely as text, then the user will not see a comment with the text above, they will instead have the JavaScript code compile, see a worrying pop up and be redirected to

Cross Site Scripting gets scary when you consider that the attacker does not have to display anything visual to the user, they don’t have to redirect a victim to another site or show a pop up, they instead could quietly sit there in the background recording everything they do, grabbing their session cookies from their other, open and logged in online banking tab, impersonate them and spoof a bank transfer from the victims bank account. This is called Cookie Stealing.

Shameless Plug – Read More about session cookies HERE

How Do We Stop This?

As mentioned briefly above, the way to stop cross site scripting is to escape all text which comes from untrustworthy sources. If we escape “<” and “>” characters, then we limit our chances of having Cross Site Scripting vulnerabilities as JavaScript cannot be injected maliciously.

Cross Site Request Forgery (CSRF)

Cross Site Request Forgery, as well as being a mouthful to say, is the lesser prevalent attack of the three we’ve discussed so far. The basic idea is that you can disguise a form on a malicious site and make it target a legitimate site instead. If we keep in line with the example of a dodgy blog, you could have a comment section take a message from a user and when the user posts the comment instead of sending those details off to the blogs database we could instead send them to the users Twitter account that they’re already logged into via another tab.

One sneaky thing an attacker can do with HTML forms is create hidden input fields which aren’t visible to visitors of a site. This means an attacker could prefill what they would like the victim to tweet inside of a hidden field and quietly send this off to Twitter in the background.

How Do We Stop This?

Modern browsers counter-act CSRF pretty easily these days; they include inbuilt checks to compare what’s called Referrer Headers of each request. Referrer Headers tell the browser where the request is originating from and if the origin does not match the target then it is denied submission.

Nowadays most websites also attach what the American’s like to call a “nonce” to each request – a random string of characters which verifies and signs the request to ensure (in our example) that the user wants to post the tweet. What do the British like to call it? Ummm I’m not sure, but its definitely not a nonce!

Denial-Of-Service (DoS & DDoS)

Denial-Of-Service attacks are probably the most well-known web attack out there and honestly, there’s not really much to explain about this one.

If you’re running your own web server for your personal website at home and you’re on let’s say a 20MB internet connection, then you’re limited to the amount of bandwidth you can use to serve your website to visitors. The idea behind DoS is just to saturate the bandwidth of the targets network by requesting so many resources the victim’s internet connection gives up. If you are hogging all of the bandwith then no one else can make requests to the site which can be catastrophic for small businesses who rely on ecommerce sales.

DDoS (Distributed Denial-Of-Service) is exactly the same concept but instead of using a single, powerful computer to take down a site, you use an army of computers to achieve the same outcome. DDoS is usually undertaken by innocent peoples infected computers; the attacker will install BotNet software which makes the chorus of zombie computers rise and attack the victim’s server.

How Do We Stop This?

Don’t host your own website!! Use a host such as SiteGround to handle your hosting needs for you. Companies like SiteGround have huge internet connections, teams of Network Engineers and complex firewall setups to combat DoS attacks.

If you’re a large enterprise, you can combat DoS by undertaking what;s called Horizontal Scaling I.E adding additional web servers to take the load off of a single web server. There are all kinds of different variations of Load Balancing and Reverse Proxying settings you can configure if you want to go the manual route. *Cough* Reverse Proxying in NGINX *Cough*.

The Slow Loris

Image result for slow loris

Don’t let the cute looks fool you, they’re venomous and they are actually meant to be pretty vicious to humans… did you hear one actually nearly killed a guy?!

Oh yeah about the web attack…

Slow Loris is without a doubt the most elegant attack out of all the 5 we’ve discussed so far. It’s so simple and so hard to prevent which consequently makes it so attractive to attackers.

The concept behind the Slow Loris is to make multiple , separate requests to a web server so slowly that you tie up all of their available connections and keep them busy. It is classed as a DoS attack, but it differs from the previously discussed DoS attacks as we focus on targeting the web server software as opposed to the victim’s bandwidth.

How does it work?

When you open a web page, your browser sends a HTTP GET request which asks the web server which hosts the site for the HTML document along with any images/assets required to build the page which you see. The request looks like a little like this:

Get /yoursite/index.html HTTP/1.1\r\n
Accept: */*\r\n

The part we are interested in here is the final two “\r\n” at the end of the HTTP call. A HTTP call must always end with two new blank lines, which is exactly what the two “\r\n” indicate.

So, what does this have to do with the Slow Loris?

If we never send those two final “\r\n” line breaks, we never end the connection to the server and therefore we tie up a connection spot which could be allocated to a genuine visitor of the site. As far as the web server is concerned, the attacker does not look like they’re doing anything malicious – Some people do genuinely have really poor internet connections so it’s not out of the ordinary to see a client requesting resources this slowly.

If you request a web page from your mobile but run out of battery or lose 4G halfway through the request then the web server keeps talking to you until the request times out (usually 30 seconds or so); after this point your thread is terminated and your place on the server is allocated to someone else. Slow Loris gets around this by sending a single character every 30 seconds or so to the web server which keeps the connection alive and keeps the server patiently listening.

If we theorize that a server can have up to 200 concurrent connections I.E clients requesting resources from the server, then we can easily utilize one of the many open source implementations of Slow Loris to open 200 sessions from a single computer which will grind a small server to a complete halt.

The most interesting part about the Slow Loris is that we are theoretically sending 1 character every 30 seconds per connection, so 200 characters in total every 30 seconds as per the 200 connections. This bandwidth is so insanely small you would not notice any drop at all in your normal internet browsing – you would be able to stream HD video or watch live TV without noticing any effect on your side.

I recorded a short video to show how easy it is to carry out a slow loris attack – you can check it out below:

How Do We Stop This?

The Slow Loris really only targets web servers running Apache, this is because of the underlying design of how Apache works is that it spins up a new thread for each and every visitor and this is exactly what is exploited by the slow loris attack. Other web server software such as NGINX do not fall as easily to the Slow Loris.

Just like the previous DoS attack, make sure you avoid hosting your own web server as much as you possibly can. Pay another company to deal with the nightmare of hosting and you will a lot less likely to become victim to a Slow Loris attack.