CODEWITHSUNDEEP
phpsecuritydenial-of-service
Pere
Pere

Reputation: 2013

Security implications of ignore_user_abort() function

Has PHP's ignore_user_abort() function any security implication?

I'm thinking in DoS. For example, when having the function exposed to anonymous traffic in some code that is resource expensive.

Upvotes: 2

Views: 740

Answers (2)

Ulrich Thomas Gabor
Ulrich Thomas Gabor

Reputation: 6654

As addition to the previous answer I'd like to add that the risk is not bigger, but is being shifted a little.

If the goal is to overload the server by calling an expensive script a lot of times, it is clear that calling ignore_user_abort(true); relieves the attacker from the need to keep the connection open. The script will continue to execute nevertheless of the connection status and consume resources.
In contrast without ignore_user_abort(true); the script would end its execution on the first output (if there happens no output the script will be as consuming as the first variant [1]).

In case of a DoS attack (and especially a DDoS attack) the attacker likely has absolutely no problem in opening (and holding open) a lot of connections. Therefore from this perspective ignore_user_abort makes no difference.

I can't think of any further security related implications of using this functionality.

I would even claim that most PHP developers do not really know that the execution of their scripts might stop somewhere in the middle just because the connection is lost. I think most would guess that their scripts will execute until the end in all cases although this is not the default setting.

Upvotes: 2

Uours
Uours

Reputation: 2492

I don't see any direct security implications with ignore_user_abort() function .

In terms of DoS attack , considering the containing script is

  • resource expensive
  • exposed to anonymous traffic

the concern should be of server overload which could lead to temporary or indefinite interruption or suspension of services .

If possible it would be wise to find alternatives for such a resource expensive code :

  • If the containing script is used to simulate cron task , it would be wise to use crontab instead .
  • If possible it would be wise to put programmatic restriction in place to run only one instance of such resource expensive code irrespective of how many page hits the containing script would get .

Hopefully this is of some help .

Upvotes: 2

Related Questions