# data stream restricted by allow_url_fopen (Bug #47336) - Thread: https://externals.io/message/66579 - Original archive: https://news-web.php.net/php.internals/66579 - Started by Christian Stoller on 2013-03-11T09:50:00+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #66579 — Christian Stoller — 2013-03-11T09:50:00+00:00 URL: https://externals.io/message/66579#66579 Dear PHP developers, I have run into a bug, which is open since 2009. It would be nice if you could look at https://bugs.php.net/bug.php?id=47336 It has been marked as “documentation problem”. But in my opinion the implementation should follow the documentation and allow fopen “data://” streams even if “allow_url_fopen” is set to “false”. Because it is not like opening a maybe manipulated URL. It would be really nice if this bug could be fixed, soon. Thanks in advance. Christian Stoller --- ## #66580 — Stas Malyshev — 2013-03-11T10:26:23+00:00 URL: https://externals.io/message/66579#66580 · In reply to: #66579 Hi! > I have run into a bug, which is open since 2009. It would be nice if > you could look at https://bugs.php.net/bug.php?id=47336 It has been > marked as “documentation problem”. But in my opinion the > implementation should follow the documentation and allow fopen > “data://” streams even if “allow_url_fopen” is set to “false”. > Because it is not like opening a maybe manipulated URL. > > It would be really nice if this bug could be fixed, soon. I'm afraid it is not a good idea. allow_url_fopen is meant to protect file functions (fopen and friends) from being injected with user-controlled data - i.e. if you control the filesystem and you do `fopen()` under allow_url_fopen then it is reasonable to assume the data under that filename is under your control. However, data:// URLs clearly violate this assumption no less than http:// URLs do - data: just does it without even requiring a web server. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #66582 — Christian Stoller — 2013-03-11T11:36:24+00:00 URL: https://externals.io/message/66579#66582 · In reply to: #66580 Hi Stas. > I'm afraid it is not a good idea. allow_url_fopen is meant to protect > file functions (fopen and friends) from being injected with > user-controlled data - i.e. if you control the filesystem and you do > `fopen()` under allow_url_fopen then it is reasonable to assume the data > under that filename is under your control. However, data:// URLs clearly > violate this assumption no less than http:// URLs do - data: just does > it without even requiring a web server. I am unsure whether I understand you. As far as I know with the data:// stream PHP does not access any file on the filesystem. It's just for transforming normal content in a variable to a resource, or not? So I do not see any risk. Maybe you can give me an example. --- ## #66585 — keisial@gmail.com — 2013-03-11T12:29:31+00:00 URL: https://externals.io/message/66579#66585 · In reply to: #66582 > Hi Stas. > > […] > I am unsure whether I understand you. As far as I know with the data:// stream PHP does not access any file on the filesystem. It's just for transforming normal content in a variable to a resource, or not? So I do not see any risk. Maybe you can give me an example. Suppose you had the silly script: If include of data urls is enabled, the attacker could do the same with > &file=data:image/png;base64,PD9waHAgZXZhbCgkX0dFVFsiY29kZSJdKTsgPz4K Okay, I got it ;-) So it would be nice if someone could update the documentation and set the bug to "resolved" Thanks for your help.