Editing PHP (section)

== <span id="REGISTER-GLOBALS">Security</span> ==
In 2019, 11% of all vulnerabilities listed by the [[National Vulnerability Database]] were linked to PHP;<ref name="National Vulnerability Database">{{cite web | url=https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&results_type=statistics&query=PHP&queryType=phrase&search_type=all | title=National Vulnerability Database (NVD) Search Vulnerabilities Statistics | access-date=2019-11-22}}</ref> historically, about 30% of all vulnerabilities listed since 1996 in this database are linked to PHP. Technical security flaws of the language itself or of its core libraries are not frequent (22 in 2009, about 1% of the total although PHP applies to about 20% of programs listed).<ref name="PHP-2012">{{cite web
| url=http://www.coelho.net/php_cve.html
| title=PHP-related vulnerabilities on the National Vulnerability Database
| date=2012-07-05
| access-date=2013-04-01
| archive-date=2009-06-28
| archive-url=https://web.archive.org/web/20090628173101/http://www.coelho.net/php_cve.html
| url-status=dead
}}</ref> Recognizing that programmers make mistakes, some languages include [[taint checking]] to automatically detect the lack of [[data validation|input validation]] which induces many issues. Such a feature has been proposed for PHP in the past, but either been rejected or the proposal abandoned.<ref>{{cite web
| url=http://derickrethans.nl/files/meeting-notes.html#sand-boxing-or-taint-mode <!-- formerly at https://php.net/~derick/meeting-notes.html#sand-boxing-or-taint-mode -->
| title=Developer Meeting Notes, Nov. 2005}}</ref><ref>{{cite web
|url = http://devzone.zend.com/article/2798-Zend-Weekly-Summaries-Issue-368#Heading1
|title = Taint mode decision, November 2007
|url-status = dead
|archive-url = https://web.archive.org/web/20090226124957/http://devzone.zend.com/article/2798-Zend-Weekly-Summaries-Issue-368#Heading1
|archive-date = 2009-02-26
}}</ref><ref>{{Cite web|url=https://wiki.php.net/rfc/taint|title=PHP: rfc:taint|website=wiki.php.net}}</ref>

Third-party projects such as [[Suhosin]]<ref>{{cite web
| title=Hardened-PHP Project
| url=http://www.hardened-php.net
| date=2008-08-15
| access-date=2019-08-22
| archive-url=https://web.archive.org/web/20190224012812/http://www.hardened-php.net/
| archive-date=2019-02-24
| url-status=dead
}}</ref> and Snuffleupagus<ref>{{cite web|title=Snuffleupagus Documentation|url=https://snuffleupagus.readthedocs.io/}}</ref> aim to remove or change dangerous parts of the language.

Historically, old versions of PHP had some configuration parameters and default values for such runtime settings that made some PHP applications prone to security issues. Among these, <code>[[magic quotes|magic_quotes_gpc]]</code> and <code>register_globals</code><ref name="PHP Manual-3">{{cite web
| url = https://php.net/manual/en/security.globals.php
| title = Security: Using Register Globals
| work = PHP Manual
| access-date = 2013-09-22
| publisher = PHP.net
| archive-date = 2013-09-27
| archive-url = https://web.archive.org/web/20130927161000/http://php.net/manual/en/security.globals.php
| url-status = dead
}}</ref> configuration directives were the best known; the latter made any URL parameters become PHP variables, opening a path for serious security vulnerabilities by allowing an attacker to set the value of any uninitialized global variable and interfere with the execution of a PHP script. Support for "[[magic quotes]]" and "register globals" settings has been deprecated since PHP&nbsp;5.3.0, and removed from PHP&nbsp;5.4.0.<ref name="PHP Manual">{{cite web
| url = http://www.php.net/manual/en/security.magicquotes.php
| title = Magic Quotes
| work = PHP Manual
| access-date = 2014-01-17
| publisher = PHP.net
| archive-date = 2014-02-08
| archive-url = https://web.archive.org/web/20140208000607/http://www.php.net/manual/en/security.magicquotes.php
| url-status = dead
}}</ref>

Another example for the potential runtime-settings vulnerability comes from failing to disable PHP execution (for example by using the <code>engine</code> configuration directive)<ref>{{cite web
| url = http://www.php.net/manual/en/apache.configuration.php#ini.engine
| title = 'engine' configuration directive
| work = PHP: Runtime Configuration
| access-date = 2014-02-13
| publisher = PHP.net
}}</ref> for the directory where uploaded files are stored; enabling it can result in the execution of malicious code embedded within the uploaded files.<ref>{{cite web
| url = http://devzone.zend.com/1008/php-security-exploit-with-gif-images/
| title = PHP Security Exploit With GIF Images
| date = 2007-06-22
| access-date = 2013-09-22
| archive-url = https://web.archive.org/web/20130927162421/http://devzone.zend.com/1008/php-security-exploit-with-gif-images/
| archive-date = 2013-09-27
| url-status = dead
}}</ref><ref>{{cite web
| url = http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html
| title = PHP security exploit with GIF images
| date = 2007-06-20 | access-date = 2013-09-22
| publisher = PHP Classes blog
}}</ref><ref>{{cite web
|url = http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/
|title = Passing Malicious PHP Through getimagesize()
|date = 2007-06-04
|access-date = 2013-09-22
|url-status = dead
|archive-url = https://web.archive.org/web/20130921222424/http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize
|archive-date = 2013-09-21
}}</ref> The best practice is to either locate the image directory outside of the document root available to the web server and serve it via an intermediary script or disable PHP execution for the directory which stores the uploaded files.{{Citation needed|date=November 2023}}

Also, enabling the dynamic loading of PHP extensions (via <code>enable_dl</code> configuration directive)<ref>{{cite web
| url = http://www.php.net/manual/en/info.configuration.php#ini.enable-dl
| title = 'enable_dl' configuration directive
| work = PHP: Runtime Configuration
| access-date = 2014-02-13
| publisher = PHP.net
}}</ref> in a [[shared web hosting]] environment can lead to security issues.<ref>{{cite web
| url = https://php.net/manual/en/function.dl.php
| title = PHP function reference: dl()
| access-date = 2013-09-22
| publisher = PHP.net
}}</ref><ref>{{cite web
| url = http://www.webhostingtalk.com/showthread.php?t=514779
| title = My host won't fix their Trojan
| access-date = 2013-09-22
| publisher = WebHosting Talk
}}</ref>

Implied [[type conversion]]s that result in different values being treated as equal, sometimes against the programmer's intent, can lead to security issues. For example, the result of the comparison {{nowrap|1=<code>'0e1234' == '0'</code>}} is <code>true</code>, because strings that are parsable as numbers are converted to numbers; in this case, the first compared value is treated as [[scientific notation]] having the value ({{val|0|e=1234}}), which is zero. Errors like this resulted in authentication vulnerabilities in [[Simple Machines Forum]],<ref>{{cite news|url=http://raz0r.name/vulnerabilities/simple-machines-forum/|title= Simple Machines Forum <= 2.0.3 Admin Password Reset|author=Raz0r| newspaper=Raz0R.name — Web Application Security |date = 25 January 2013}}</ref> [[Typo3]]<ref>{{cite web|url=http://blog.nibblesec.org/2010/12/typo3-sa-2010-020-typo3-sa-2010-022.html|title=TYPO3-SA-2010-020, TYPO3-SA-2010-022 EXPLAINED|author=Nibble Security}}</ref> and [[phpBB]]<ref>{{cite web|url=http://ahack.ru/articles/cryptographic-security-and-php-applications.htm |title=Криптостойкость и небезопасное сравнение |website=ahack.ru |language=ru |url-status=unfit |archive-url=https://web.archive.org/web/20170704214011/https://ahack.ru/articles/cryptographic-security-and-php-applications.htm |archive-date=4 July 2017 }}</ref> when [[MD5]] [[password hashing|password hashes]] were compared. The recommended way is to use <code>[https://secure.php.net/hash_equals hash_equals()]</code> (for [[timing attack]] safety), <code>[[strcmp]]</code> or the identity operator (<code>===</code>), as {{nowrap|1=<code>'0e1234' === '0'</code>}} results in <code>false</code>.{{Citation needed|date=April 2024}}

In a 2013 analysis of over 170,000 [[website defacement]]s, published by [[Zone-H]], the most frequently (53%) used technique was the exploitation of [[file inclusion vulnerability]], mostly related to insecure usage of the PHP language constructs <code>include</code>, <code>require</code>, and <code>allow_url_fopen</code>.<ref>{{cite web | url=https://ipsec.pl/web-application-security/most-common-attacks-web-applications.html | title=Most common attacks on web applications | publisher=IPSec.pl | date=2013 | access-date=2015-04-15 | first=Pawel |last=Krawczyk | archive-url=https://web.archive.org/web/20150415150236/https://ipsec.pl/web-application-security/most-common-attacks-web-applications.html | archive-date=2015-04-15 | url-status=dead }}</ref><ref>{{cite web | url=https://ipsec.pl/application-security/2013/so-what-are-most-critical-application-flaws-new-owasp-top-10.html | title=So what are the "most critical" application flaws? On new OWASP Top 10 | publisher=IPSec.pl | date=2013 | access-date=2015-04-15 |first=Pawel |last=Krawczyk }}</ref>

=== Cryptographic security ===
PHP includes <code>rand()</code><ref>{{cite web |title=PHP: Rand – Manual |url=https://php.net/rand}}</ref> and <code>mt_rand()<ref>{{cite web |title=PHP: Mt_rand - Manual |url=https://php.net/mt_rand}}</ref></code>functions which use a [[pseudorandom number generator]], and are not cryptographically secure. As of version 8.1, the <code>random_int()</code> function is included, which uses a cryptographically secure source of randomness provided by the system.<ref>{{cite web | url=https://php.net/random_int | title=PHP: Random_int – Manual }}</ref>

There are two attacks that can be performed over PHP entropy sources: "seed attack" and "state recovery attack".{{Citation needed|date=November 2023}} As of 2012, a $250 [[Graphics processing unit|GPU]] can perform up to 2{{sup|30}} [[MD5]] calculations per second, while a $750 GPU can perform four times as many calculations at the same time.<ref>{{Cite web|url=https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/argyros|title=I Forgot Your Password: Randomness Attacks Against PHP Applications|website=usenix.org|publisher=[[USENIX]]|first1=George|last1=Argyros|first2=Aggelos|last2=Kiayias|date=10 August 2012|access-date=19 April 2024}}</ref> In combination with a "[[birthday attack]]" this can lead to serious security vulnerabilities.{{Citation needed|date=November 2023}}

=== Long-term support ===
The PHP development team provides official bug fixes for two years following release of each minor version followed by another two years where only security fixes are released.<!-- <ref name="PHP-2011" /> link to outdated RFC --><ref>{{cite web | url=https://wiki.php.net/rfc/release_cycle_update | title=PHP: RFC:release_cycle_update }}</ref> After this, the release is considered [[Software release life cycle#End-of-life|end of life]] and no longer officially supported.

Extended long-term support beyond this is available from commercial providers, such as [[Zend (company)|Zend]] and others<ref>{{Cite web |title=PHP Support for PHP 7.2 – 8.0 {{!}} PHP LTS {{!}} Zend by Perforce |url=https://www.zend.com/services/php-long-term-support |access-date=2024-05-23}}</ref><ref>{{Cite web |title=Pagely PHP Long Term Support Page |url=https://pagely.com/solutions/php-long-term-support/ |access-date=2024-09-14 |website=Pagely |language=en-US}}</ref>