Nginx block sql injection and file injection

→ Are you a new visitor? Please visit the page guidance for new visitors ←

Nginx block sql injection and file injection

Currently most hackers are looking for two major things when trying to hack a website, they are testing if its possible to inject their own sql queries for reading the actual database for other information, but also testing for file injection, and this is a major security that needs to be looked over. Injecting a shell script on a hosting account will give the hacker direct access to the hosting account whenever they want and without any limits. Furthermore if the hosting service is not secure enough, referring here for shared hosting services, from one hosting account they can get access to other hosting accounts on the same server or directly to the entire shared hosting server. This is really not a joke, I’ve seen this happening before and was a mess trying to clean up after the hacker. Better to reinstall everything.

In this article I’m going to show you some basics ways how you can use nginx to block sql injection and file injection directly and giving the hacker a forbidden message or you could give a connection reset so that the hacker would see it as a ‘hosting gone down’ error like, but actually you reset his connection to the site.

Using nginx as a reverse proxy

In my other articles I showed you how you can install Nginx as a standalone server and also how you can set Nginx as a reverse proxy. In both cases you can use the rules below, but I recommend using the later one, as a reverse proxy since we’re trying to minimize damage to the backend server by actually taking the hit as a reverse proxy.

Custom rules to block sql injection

What is a sql injection? Really now, sql injection is referred to a code injection technique specifically made to attack data driven application in order to get some information from the database back to the attackers screen. This would only work if the application itself is not properly secured, eg. the input filter of the application does not filter properly the input data. In such cases the attack will abuse the security holes of the application and run the sql queries. I’m not going to show you sample of such sql injection codes since we are trying to prevent this, not to spread it, but you can find a lot of examples on the internet, just google a bit.

Currently I’ve been using the following custom rules on my little test box and was working really nicely:

The above will return a 403 error, forbidden message, however you can use code 444 to reset connection without replying anything to the attacker.

Custom rules to block file injection

Same as with the sql injection code, only this time the attacker will try to inject a file, in most cases a shell script. In such cases we try to block again GET requests that contains the string “http://” or directory tree”../..”. Normally you should not use such codes in your links or images, but I know there are certain scripts, for example timthumb which uses the approach of using http:// to access the image and creates the thumb. We can create a whitelist for such cases of course, but we should really advise the user to not use such scripts.

The code I’ve been using so far is:

This will block 99% of all file injections out there and will save you the trouble afterwards. Again as before, we can use status code 444 instead of 403.

Common nginx block exploits

Using the same approach you can also block other requests that match “<script>” tag or “base64” strings in the query string, for eg:

Basically that is how you can block them. Now using the $host variable in Nginx you can easily whitelist the domains you wish for these rules to not trigger. Of course that’s not the recommended solution.

That’s it for now, see you again in our next article.

Request an article ←