How to protect a website from SQL injections? They attack, pour shells and all sorts of filth. Need a scanner

Question

PHP

There is a site, kind and for people. He interfered with someone or what was the matter, I don’t know, but they got into the habit of “breaking” him. Apparently, there are a lot of holes in it (or maybe not many, who knows), the site was built by “Moldovan builders” from free-lance.ru who didn’t really do the job, somehow. But somehow the site lived for the time being.

One intelligent friend suggested one page where the script was vulnerable to SQL injection. There was no check for the integer value of the parameter passed in the GET request. Like this code:

if($_REQUEST[xid])
$id = $_REQUEST[xid];

Closed by cast to int.

The question is. Pts a lot of pages, sometimes a lot of code. How to find all such errors on the site? Are there any scanners for finding such vulnerabilities? I'm afraid that this may not be the only script with such "holes".

Or how else?

If there are experts, then be so kind as to unsubscribe in a personal.

Answer 1

To begin with, it is worth starting by looking at the code, in the code above there are at least two notices in case of the absence of a variable and the use of a constant instead of a string.
You don't need a scanner. and the person who will audit the code. He knows the right tool and can catch logical errors.

Answer 2

We open the editor and look for $_REQUEST or $_GET or $_POST - where we found the vulnerability there

Answer 3

All - nothing. The best way to initially organize the logic of work so that all processing of variables occurs according to the same principles in all modules.
When each page has its own check, it is very likely that you will forget and miss something.
Also, I think it’s not a matter of course that you should not work directly to access the database, but use special frameworks that have an additional layer of checks. For example PDO or analogues.
There are special scanners for finding vulnerabilities, for example Acunetix, havij ... here is a good overview habrahabr.ru/post/125317/
However, not a single scanner will find all vulnerabilities, because they may not be completely obvious.
For example, even if you stick a check here, this will not protect against a vulnerability when register_globals is enabled,
if($_REQUEST[xid]) $id = (int)$_REQUEST[xid];
because the id variable can simply be passed in the parameters, and you can simply “forget” about xid. Then it will be possible to transfer anything to $id.
Those. the correct code in this case would be something like this
if (!isset($_REQUEST[xid])) {die(); } $id = (int)$_REQUEST[xid];

Answer 4

What about hosting? They also have holes.

Answer 5

If it's a popular CMS, it's wise to update it to the latest version. And if the site is self-written, then either those who know the code attack, or the vulnerabilities are really easy to find, and even a simple audit will help identify some of them.

Answer 6

The right, but financially unprofitable decision: do not hire bydlokoderov and remake the site.
Quick and cheap solution: write/fasten a filter that will not skip requests with the words SELECT, where, JOIN, UNION (in any case), script, onload, onerror, onmouseover (and all other JS events), object, applet, iframe, frame and so on. Search the Internet for a list of words. If your visitors, for example. communicate in Russian, obviously, they hardly use such words.
Also, you can replace single, double quotes and apostrophe in the input with Unicode slash quotes. They look about the same, but the injection can no longer be done. You can also use Durov's trick - in words like script, change from to Russian - it looks the same, but does no harm. The site works, but injections don’t, school hackers painfully stare at the monitor, but they can’t do anything.
Also, if you know how to administer linux, you can shove the web server and the database server into separate containers on the server and isolate them (or even enable selinux). Plus firewall tightly. This is generally an ideal option - even if your site represents one big backdoor, the hacker will not be able to get any benefit from it. If you properly configure the server, firewall and isolation, you can even hire schoolchildren to write code.

Answer 7

Have a look at Acunetix Web Vulnerability Scanner , there's a Trial.

Answer 8

I am also for manual labor. If you figured out the problem, go through all the code for these things yourself, as recommended by Wott. Of course, since the program leaves such things in the code, anything can be there. This time. If there is another side of the coin, which is important to remember. Namely, the programmer could have made the backdoor intentionally, and now he or his accomplices are using it. You simply need a code audit, you can upload a lot of all sorts of nasty things to the site, then prove that it’s not you who steal Google accounts ...

Answer 9

As a workaround, try installing mod_security in Apache www.modsecurity.org/projects/modsecurity . This will not solve the problem completely, but it will close and log obvious holes.

Answer 10

If shells are uploaded, check all forms with the appropriate tag for uploading files

<input type="file" />

See how the file is processed there, if there are restrictions, if not, organize it.
And quietly check file by file, for input data and organize the appropriate processing of this data.
But if it's all expensive, adapt which thread of the engine (CMS, CMF, FW) to your base, guided by the importance of getting rid of bugs and the cost of adapting the engine.

Answer 11

Can you walk through the code yourself?
Look for $_GET $_POST $_REQUEST and filter.
For numbers (int)… or intval(...)
For strings htmlspecialchars(..., ENT_QUOTES)

Answer 12

> How to find all such errors on the site?
View the source code of queries, try to inject all scripts using the OWASP methodology, use ready-made tools like sqlmap.
Yes, there are: acunetix.com, detectify.com, metascan.ru