How to ensure the security of PHP application?

Started by ezhabchik, Sep 06, 2022, 02:36 AM

Previous topic - Next topic

ezhabchikTopic starter

Hi everyone. There is a application written in php. Everywhere I've stuck traps that write incoming and after validation data from form handlers to my internal logs. GET requests are not used, only POST. I would like to ask experienced people what else can be done to improve security?
What I have:
1. processing of fields by removing any characters from them with the trim function
2. Search and delete any special replace symbols inside the unnecessary fields
3. Only the originally conceived field length is taken (as limited in the HTML form)
4. And finally I use mysqli binds for example:
...
$stmt = $mysqli->prepare('INSERT INTO test (name1,  name2,  name3) VALUES (?,?,?)');
$stmt->bind_param('sss', $name1, $name2, $name3);
$stmt->execute();
...

Here, forum members, I recently noticed an attack, fell for my "Traps" and saw that they were trying to do sql injections and just as easily spam with requests.... they clog the tmp folder and there are private and not very private requests...
Naturally, the IP changes... I would like to know your opinion on how to get rid of such requests. I turned to the operator, they turned on the filter, the requests stopped, but then the requests from the payment systems do not work (they confirm the fact of payment), gave out a list of IP addresses from which the payment card sends answers, they said they handed over to the administration department and for the 5th day silence, requests then stop and resume again.
Tell me please what is better to do in such a situation?
  •  

matrice

Firstly, "1. processing fields by removing any characters from them with the trim function" - trim() is inherently designed to remove spaces and various non-displayed characters from the beginning and end of the line. The use of that function is recommended, but has nothing to do with security.

Secondly, "2. Searching and deleting any special replace symbols inside unnecessary fields" is an erroneous way of setting the task. NEVER correct the input data! Input data can be checked or processed, but not cleaned. In addition to the fact that you will simply create an unnecessary load on the server, there is a high probability that your cleaning will either be incomplete or bypassed using complex structures. Therefore, if you know that the parameter value does not correspond to what is intended, you just need to issue the appropriate error, preferably indicating the problem (so as not to confuse crooked visitors).

Thirdly, in addition to SQL injections, there are also cross-site scripting (XSS) attacks. If you then output the entered data on the pages, they must either be processed by the htmlentities() function, or, if tags or JS code are found in the data, reject the input.

Regarding flood protection and the load caused by attacks. There are no guaranteed solutions here. In general, there are two recommendations. First, you can enable cloud protection. This is what you did. At the same time, you will always have to rely on web hosting, with the resulting problems. The second is to optimize the operation of your web application. In particular, do not attempt to process the request if it is clear to you that it is malicious. As soon as you see that something is wrong at the entrance, give an error.

Regarding the connection with billing. There is a standard solution for such a problem: place scripts that process billing requests on a separate subdomain or, preferably, a domain, preferably with a separate IP address. At the same time, you can simply restrict access to that separate domain in the firewall, or, at least, in the Apache config. Accordingly, requests to that host will not overload the server, and you can put cloud protection on the main domain.

Regarding htmlentities(). You need to be able to work with it and at the same time remember three things. Firstly, it provides protection only in ENT_QUOTES mode, i.e. when it encodes both double and single quotes. Secondly, it does not encode a backslash.
Accordingly, if for some reason you need to allow a backslash in the input, then after processing the input with the htmlentities() function, you will still need to manually replace the backslash with its HTML representation. Thirdly, it is important to remember about the input encodings. In general, in modern life it is better to almost always work with UTF-8, but if for some reason you need to work with a specific encoding like KOI8-R, you will need to specify it in the call of that function.
  •