A-level Computing/AQA/Problem Solving, Programming, Operating Systems, Databases and Networking/Databases/Security





SQL injections
Badly formed SQL can offer crackers a way to read and edit data on your server through something called an SQL Injection attack. This involves an SQL statement in the code behind a web page being made up of one or more variables defined by user input. For example when you are searching for a users login information on an online shopping catalogue, the code behind the items being returned might be like this:


 * 1) Fetch the data input by the user on the web form
 * 2) Construct SQL for query by concatenating user input:
 * 3) Perform Query

This may look absolutely fine if the user inputs  or something similar:

But if the user is a criminal and guesses what your SQL statement looks like, they can inject some malicious SQL. For example instead of inserting, they might insert   instead. This would make make the server list every row as 1 always equals 1. The attacker now has access to all of your customers details which may include addresses and payment details.

Luckily for numeric values this is very easy to fix by using validation.


 * 1) Fetch the data input by the user on the web form
 * 2) Check that the user input contains only numbers
 * 3) Construct SQL for query by concatenating user input:
 * 4) Perform Query

This means that the user input cannot contain anything that the SQL server would interpret as executable code. Stupidly, even big firms still suffer from SQL injections.

For example when you are searching for a users name and password on an online banking site, the code behind the items being returned might be like this:
 * 1) Fetch the data input by the user on the web form
 * 2) Construct SQL for query by concatenating user input:
 * 3) Perform Query

Here the attacker could enter  for the password and access to everyone accounts as the sql would be.

However a better solution to this is to used parameterised queries. With parameterised queries the SQL is sent to the database separately form the SQL and is added into the query after the database has interpreted the instructions so cannot contain executable code.

For example when you are searching for an users name and password on an online banking site, the code behind the items being returned might be like this:
 * 1) Fetch the data input by the user on the web form
 * 2) Construct SQL for query without user input:
 * 3) Perform Query

Here if the attacker entered  the database would search for a user with name   and password Make sure when designing your code you don't fall victim to this.

Hashing passwords
No system should ever be considered secure, however well you think you have coded it. One thing that people really don't like having criminals gain access to are passwords. You might be tempted to make a database like this: Let's ignore the fact that the password is rubbish, it is never a good idea to leave passwords as plain text. If the database was cracked then the cracker would have access to all the plain text passwords and could use these to crack into other systems (people tend to use the same password in multiple locations). You should instead use a hash of the password through a system such as sha2. For more information about hashing see Hashing. This means that if the attacker has the hash it would take too long to work out the password to use it in most circumstances.

Salting
However if you are planning to hack a large number of hashed passwords you can use a rainbow table which is a precomputed hash table of the passwords. These can be generated relatively quickly for short length passwords. Many are available online for common hash functions to certain lengths. This can be prevented by using salting. Salting is the process of adding a short random string on the front of the password and then storing it alongside the password. For example:

This may seem to not improve security but effectively prevents the use of rainbow tables as you would have to construct the table for each salt.