Once they decide to target your website one of the tricks they will attempt is to see if they can access your website.
The aim is that hopefully you will have stored passwords on the database, then they will try to find the admin and logon to continue their work.
So, how can they access your database from the public screens? Actually, it is frighteningly easy, but almost as easy to stop it.
Take for example a page in which you pass an id.
For example it ends mypage.
php?id=1.
You request the id and then use it in your MySQL as WHERE id = '$id'.
What they then attempt is to change the parameter.
For example mypage.
php?id=1′ AND '1′ = '1 becomes in your code WHERE id ='1′ AND '1′ = '1′.
Oops! As you can see, that would actually work (try it on your website).
So, how do you stop it? Well in this example it is easy.
If you are expecting an integer, then try a piece of code such as: $id = $_REQUEST['id']; if (!is_numeric($id)) {exit;} This would stop interference in its tracks.
It is more complicated when the field is non numeric.
Here, if there are a limited number of values expected then we can build an array of expected values and then compare the value received to all of those in the array.
By checking in PHP first, the syntax is different enough from SQL to be able to fail on one or the other.
If there are thousands of values, you could try substringing the received value to the first one or two characters (not enough for mischief to take place) and returning all valid values that start like that.
Again, just use a simple PHP check to see if it is a match and fail if not.
The problem comes with searches, as there we do not know what to expect.
It depends on how your search is working, but make sure you use a POST and $_POST to return the value so that parameters in the search bar don't count.
Maybe also make sure that the referring page is from your website and if you can, remove all non alpha numeric characters from the search string.
At the very least, backslash whatever type of quote you are delimiting the string with in your search function.
If you don't and someone innocently uses the string, they will get a failure anyway.
But by backslashing it (e.
g.
str_replace("'", "\'", $_POST[search]) you are preventing it from working to end the input string, which should hopefully again stop the hacking attempt.
It's not nice when you see on your server logs that this has been happening, so the earlier you can put a stop to it the better.
Protect your website now!
The aim is that hopefully you will have stored passwords on the database, then they will try to find the admin and logon to continue their work.
So, how can they access your database from the public screens? Actually, it is frighteningly easy, but almost as easy to stop it.
Take for example a page in which you pass an id.
For example it ends mypage.
php?id=1.
You request the id and then use it in your MySQL as WHERE id = '$id'.
What they then attempt is to change the parameter.
For example mypage.
php?id=1′ AND '1′ = '1 becomes in your code WHERE id ='1′ AND '1′ = '1′.
Oops! As you can see, that would actually work (try it on your website).
So, how do you stop it? Well in this example it is easy.
If you are expecting an integer, then try a piece of code such as: $id = $_REQUEST['id']; if (!is_numeric($id)) {exit;} This would stop interference in its tracks.
It is more complicated when the field is non numeric.
Here, if there are a limited number of values expected then we can build an array of expected values and then compare the value received to all of those in the array.
By checking in PHP first, the syntax is different enough from SQL to be able to fail on one or the other.
If there are thousands of values, you could try substringing the received value to the first one or two characters (not enough for mischief to take place) and returning all valid values that start like that.
Again, just use a simple PHP check to see if it is a match and fail if not.
The problem comes with searches, as there we do not know what to expect.
It depends on how your search is working, but make sure you use a POST and $_POST to return the value so that parameters in the search bar don't count.
Maybe also make sure that the referring page is from your website and if you can, remove all non alpha numeric characters from the search string.
At the very least, backslash whatever type of quote you are delimiting the string with in your search function.
If you don't and someone innocently uses the string, they will get a failure anyway.
But by backslashing it (e.
g.
str_replace("'", "\'", $_POST[search]) you are preventing it from working to end the input string, which should hopefully again stop the hacking attempt.
It's not nice when you see on your server logs that this has been happening, so the earlier you can put a stop to it the better.
Protect your website now!