Tag: php

Usage of PHP’s json_decode on user input should be considered dangerous

No one expects the spanish inquisition and no developer expects that parsing data by itself can lead to a security weakness, but still PHP is always happy to help you have an interesting life.

So what is the problem with json_decode? the problem is that with a properly crafted JSON structure an attacker can force a very slow parsing of the JSON and hang up the CPU. The weakness comes from the way PHP internally stores arrays in memory that in the normal use case is very fast to access and retrieve data, but the worst case is horrible and json_decode by default tries to create an array from a JSON string, Not sure if the object option of the API is any better.

Mitigation? It doesn’t seem like you can guess anything about the content/structure of a JSON string without actually parsing it therefor it is probably a good idea to check that the length of the input “make sense” before processing it.

The possible impact of changing wordpress (and php) max memory settings on site performance

In the  last several days there where several questions in wordpress answers on stackexchange related to out of memory errors. This was mostly related to some plugin which required more memory to function, and people asked what is the way to change/overcome the default memory limit of a PHP process.

My impression from the questions and answers was that people fail to understand why there is a limit at all and treat the limit as some bizarre PHP thing that you need to overcome instead of trying to understand it. There is even a plugin “Change memory limit” that its description says

Update the WordPress default memory limit. Never run into the dreaded “allowed memory size of 33554432 bytes exhausted” error again!

To understand why there is a limit you need to understand the most hidden secrets of linux and windows that will surprise most developers – After an application had allocated memory from the OS it can not free it back.Yes, when a program call the free() function, an object destructor or any other dealoocation method, the memory is returned to the free memory pool of the application from which it might allocate its next memory, but it will never be returned to the OS as long as the software is running*.

Since software doesn’t really deallocate, a server software, that is supposed to run all the time, once reached its pick memory usage will stay there.This has to be taken into account when you want to ensure specific performance with the way apache works.

Appache in prefork mode basically run itself several times, where each instance can handle one request. If no instances are free to handle the request, the request has to wait in a queue. The maximal number of concurrent requests the server can process is the number of instances we can run at the same time. Assuming we don’t do any heavily CPU bound process, our limitation is the memory that can be allocated to each instance.

And how can we calculate the amount of memory an apache needs? The naive approach is to try and use average memory consumption, but once a software passed its “average” allocation, the memory will not be released. potentially an apache instance running one memory hungry process can take control over all the available memory leaving no memory available for the other instances which will probably lead to them failing in handling request. you might think that you configured your server to enable 10 request to be handled but 9 of them fail.

It is important to understand that once the memory was allocated it is of no importance that the instance never need again all of that memory and handles only small request. The memory is attached to the instance forever.

And this is why the memory  limit exists, to protect the whole server from one faulty piece of code. If you set the limit to 128KB then you can be assured that atleast the rest of the memory is available to the other instances.

So basically the number of apache instances we can run safely without the fear of the server suddenly breaking down for no apparent reason, is (amount of memory available on the server) / (max memory limit). The higher the limit the less requests your server can process in the same time which potentially leads to less responsive server.

Apache actually can be configure to kill instances after serving a certain amount of requests and by that actually free memory. This will improve the server performance on average but it also has a cost, the cost of running a new instance. You should probably always plan for the worst case scenario and experiment very carefully with relaxing the memory restriction.

Prefork is not the only way to configure apache to run, and there are also the worker and event configurations, but they require that the PHP library you use will be thread safe. Some people claim it actually works for them but the PHP developers don’t recommend running that way.

And then, if you use fastcgi to execute php instead of mod_php, you basically change it from being an apache problem to fastcgi problem which might actually be better since while fastcgi might hurt the performance of pages generated with PHP, apache itself will be able to serve static files.

* Mainly because memory from the OS is being allocated in big chunks and it is very likely that when you dynamically allocate and free memory from that chunk some allocated “live”  memory will be in every chunk.