php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #81210 Disable XML External Entities by config
Submitted: 2021-06-30 11:29 UTC Modified: 2021-08-18 12:58 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: mail at 12live dot de Assigned:
Status: Open Package: XML related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: mail at 12live dot de
New email:
PHP Version: OS:

 

 [2021-06-30 11:29 UTC] mail at 12live dot de
Description:
------------
As XML External Entity is still a serious security risk, i would like to have the ini option to disable this globally PHP level. Ideally it would be disabled by default (as GO does) but I can understand if this is not feasible. At least not if PHP claims to be XML standard compliant by default. 


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-06-30 11:34 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
such switches are a terrible idea because you can't know where your code will run in the future - instead write good code you rely on luck of a server config which could change tomorrow
 [2021-06-30 11:40 UTC] mail at 12live dot de
Can´t agree on that. Of course your code should be secure but the ini option could be another element regarding "Defense in depth". PHP already has such switches. Also if i completely run php on my own controlled environment this would help harden the environment. Especially regarding libraries beeing used where it is not always obvious that there might be a XML Ecternal Entity sink
 [2021-07-02 16:32 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-07-02 16:32 UTC] cmb@php.net
As of libxml2 2.9.0, substitution of external entities is disabled
by default.  You need to explicitly pass XML_NOENT to the
respective functions to enable it.  Are you suggesting that an ini
setting should make XML_NOENT to have no effect?
 [2021-07-02 16:48 UTC] mail at 12live dot de
-Status: Feedback +Status: Assigned
 [2021-07-02 16:48 UTC] mail at 12live dot de
Yes correct. I want to enforce that noone can enable External Entity substitution on my environment. The security risk is far too high and I don´t want to rely on the hope that any code/library is secure enough to mitigate that risk correctly. I do not have any use case where External Entities might be needed. Probably the vast majority of users does not have such use cases. Xternal Entities are a very dangerous security risk. It should be treated adequate and it should be possible to disable that completely on system/PHP level
 [2021-07-02 17:07 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2021-07-02 17:07 UTC] cmb@php.net
Well, you can build a custom PHP where LIBXML_NOENT is defined[1]
as 0.  If you prefer the INI setting, please pursue the RFC
propcess[2].

[1] <https://heap.space/xref/PHP-7.4/ext/libxml/libxml.c?r=498eb8e0#848>
[2] <https://wiki.php.net/rfc/howto>
 [2021-07-02 17:54 UTC] mail at 12live dot de
A custom PHP in my opinion is not a solution which treats such a risk appropriately. I was hopening that someone of PHP recognizes the potential risk. An ini option would be the right solution as  it would be available for anyone and might be helpful to mitigate such a risk. PLease note that this is one of the higher rated risks in the OWASP Top 10. 

Sadly I do not have the necessary insights to provide a sufficient RFC. So I am hoping someone might help here.
 [2021-08-18 12:58 UTC] cmb@php.net
-Package: PHP options/info functions +Package: XML related
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 05:01:30 2024 UTC