Going a bit off topic here
Originally my pages were set up with the URLs displaying the whole of the filename and full variables, like: example.com/shipping.php?id=52
The first hint was in Analytics, pages visited sometimes show the URLs with a quote mark added on the end.
I then set up my script to detect any unwanted characters in the variables.
In this instance the only thing I expect in the variable is an integer, so it’s easy enough to strip out everything else and make it safe.
$id = preg_replace('#[^0-9]#i', '', $_GET['id']) ;
But what if, in addition to that we check what else may be in that variable?
You can use a second preg_replace or preg_match to check for “unwanted” characters, such as single quotes, double quotes, semi colons and equals, in $_GET['id'] and if any are detected, take appropriate action. Record, report, ban, redirect, whatever you want to do with them.
A common one I found was the addition of 'A=0 on the end or sometimes just a single quote.
But there was no real threat.
For one, as you see the variable to be used is stripped down to just an integer, anything else is removed.
The actual SQL query is a PDO prepared statement with the already sanitised $id bound after preparation.
Also the database user account used by the script to connect to the database is “read only”, it only has privileges to run SELECT queries. So in the unlikely event they did make a successful injection, all they would be able to do is retrieve data that the website is displaying publicly anyway. Why? Because any more sensitive data is stored in a separate, private database which this user account does not haver access to.
Likewise a script that records user input, such as the contact form, to a database which will contain peoples contact details, will be accessed by another user account which has only INSERT privileges, so it can’t possibly retrieve any data.
With this I was catching a whole load of would be hackers, recording and blocking them from the site, to the point it was getting boring.
It turned out with a bit of snooping that the site had been listed on some “SQL Dorks” sites as being “vulnerable”, presumably due to the URL structure /shipping.php?id=50.
The funny thing being that they assume “shipping” to be related to an e-commerce site sending out goods, where as in fact “shipping” refers to pages about historical sea-going vessels.
Anyway, the next step was to alter my URL structure via htaccess so as not to appear vulnerable and seem less appealing to the would be hackers, at the same time making the URLs more user and Google friendly. So now the query strings are less obvious and more readable to humans. So now /shipping.php?id=50 looks like /shipping/50-silvery-wave with the id number still there for the database query with the ships name also for human readability. It would have been nice to just have the ship name for the query, but they are not unique, so I still need a unique id.
The attempted attacks did continue for a while, with the old URLs still being in indexes and redirecting to the new ones, but they gradually died down as they stopped bothering with me. Now I have not seen one of these attempts in several months.