[RFC][DISCUSSION] Script only includes

Hi Matteo, On Tue, Feb 10, 2015 at 5:22 PM, Matteo Beccati <php@beccati.com> wrote:

I proposed script()/script_once() at first. Considering new names that might break existing apps, I choose INI. The INI may be removed in the future, if include/require has an option. e.g. require string $filename [, bool $embed_mode_flag]; Would you like me to include this change proposal in the RFC? Even if we have embed_mode_flag, we are better to have the INI option for a while for smooth migration. Regards,

Hi Markus, On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer <markus@fischer.name> wrote:

Yes. Since we have custom script loader, file content cannot be used for "pure" PHP script detection. However, parser can detect if it's a "pure" PHP script. i.e. Detect <?php token at first, no ?> in the file. Regards,

Hi Pierre, On Tue, Feb 10, 2015 at 6:19 PM, Pierre Joye <pierre.php@gmail.com> wrote:

I think I understood your point of view perfectly and thank you for your comment. We just have different point of views. This is the last serious PHP design issue for me. I've been thinking how it could be resolved for a long time and this is the best. I hope you agree to remove risks of script inclusions. Let's be nicer to new PHP users! Don't let them down by embedded mode include()/require()! Regards,

Hi Pavel, On Tue, Feb 10, 2015 at 7:06 PM, Pavel Kouřil <pajousek@gmail.com> wrote:

We have been tried to educate users already and introduced some mitigations e.g. allow_url_include, open_basedir. However, enough time is passed to prove that wasn't enough, isn't it? PHP (many and these are _only_ few of them in the wild) http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=PHP&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_exploit_text=inclusion&filter_port=0&filter_osvdb=&filter_cve= PERL (0 result) http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=&filter_exploit_text=PERL&filter_author=inclusion&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve= Rails (0 result) http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=Rails&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve= Python (0 result) http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=Python&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve= JSP (1 result - This is famous) http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=JSP&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve= The picture is clear. I value education as one of the most important security measure indeed. However, education is not perfect. If there is effective counter measure, it is better to be adopted. We can write web apps by PHP, not only because it's faster to write, but easier to write secure code. We removed "script embedding" from regex functions, why not include? My new proposal is simple and does not require performance penalty. Regards,

Hi Stas, On Wed, Feb 11, 2015 at 4:32 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

File disclosure issue is not scope of this RFC. 2. Legitimate files can include <? as byte sequence - in fact, it is

Good point. User needs compression/encryption to avoid issues. I may make move_uploaded_file() more strict. How about syntax check? If it detected as script and there is no syntax errors, then reject. This will never happens binaries. However, this is not enough. User may upload text with PHP program sample. So add and options that force to move embedded PHP script? Another possibility is use of filename extension(s). It's going back to old approach, but register script extension and allow execution only for matched extension. This may be the way to go. 3. General approach of this RFC is, given site with glaring security

I'm not trying to be perfect, but I would like to make PHP as secure as other languages from script inclusion attacks. It's too easy currently... I hope we have consensus for a resolution. Regards,

On 11/02/15 09:34, Derick Rethans wrote:

First 5? ... Yasuo ... I don't think this is going in the right direction. The principals are right, but we have been through a lot of this trying to secure included files in the past and nothing has worked yet. I don't think that anything implemented in a PHP distribution will change what is happening in practice?