As part of our assessment it was required for our CMS system to be ‘hack proof’, this means that it had to be written in a way that made sure it was not susceptible to SQL injection. To understand how I can make my CMS system SQL injection proof I first had to understand what was incorporated in SQL injections. After googling a bunch of websites I have a basic understanding of how it works. The most helpful piece of information that I found was this infographic:
The website went on to say that SQL injection is a query that goes through an input field to the database. It can cause a lot of damage to your system from deleting entire tables to writing in a script tag that creates an action that can ether trigger an action that can break the database or the website.
The php manual defines SQL injection in much the same way however I found it easier to understand.
“Direct SQL Command Injection is a technique where an attacker creates or alters existing SQL commands to expose hidden data, or to override valuable ones, or even to execute dangerous system level commands on the database host.”
A common injection that can be used to break the database ‘id’ field. If out type ‘1=1’ in to an input field it will:
“the reply to the query will expose all IDs in the database, since the condition ‘1=1′ is always true” – Veracode
$(document).ready(function() {
location.reload();
}));
This function allows the window to load and then reload when the page loads ultimately creating an infinite refresh loop and you can’t do anything to it. I found this out accidentally last year when I was trying to trigger a reload function to animate text at a certain point of the screen so that it would write itself when you scrolled to certain point of the page.