[TYPO3-core] TYPO3_MODE "die" in Configurations/TCA

Helmut Hummel helmut.hummel at typo3.org
Thu Jun 12 23:41:14 CEST 2014


Hi!

These die() statements are there for security reasons.

On 12.06.14 18:31, Frans Saris wrote:

> Op 12 jun. 2014 18:10 schreef "Bernhard Kraft" <kraftb at think-open.at>:
>>
>> + It inhibits direct access to those files.

Exactly.

 > If you acces these files direct and error display is on it can expose 
paths
 > etc as there are calls made to methods etc that will result in fatal 
errors.

>> Any other ideas about those? Maybe someone remembers more "+" reasons for
>> those.

It is there to protect php files from being executed in a context they 
are not designed for.

Ideally all php files that are not an entry point should not exist in 
the document root, but we all know that this is currently not possible.

The protection does not make sense for php files that are free fo side 
effects like:

* pure class files (no require, no other code outside class statement)
* files that return a static array (like LocalConfiguration.php)

Protection makes sense for *all* other php files. We had security issues 
in the past where this could be exploited, by executing these files 
directly under certain circumstances.

However, sometimes protection by TYPO3_MODE or die is not possible for 
some files.

Just one example (the one type that caused the security issue):

==============================
<?php
require $BACK_PATH . 'init.php';

...
==============================

Clearly a file with side effects, but protecting it with above mentioned 
condition does not work as the constant is defined in init.php

So we could add the die statements where possible and hope files where 
this is not possible cannot cause security related side effects (non are 
know at least)

I would support such a "better some protection than none" approach, but 
would suggest to shorten the statement to:

defined('TYPO3_MODE') or die();

Note the one-liner and the empty die, not giving a potential attacker 
any further hint.

Real consistent solutions would be:

1.
Reduce the number of entry scripts to (at best one or) let's say a hand 
full and all required static resources to defined folders 
(Public/Resources) and move all other files outside the document root

2.
Rename all such files with a dedicated prefix ("Inc.") or suffix 
(".inc.php") so that they could be targeted with a web server 
configuration to deny access to such files



I would go for

defined('TYPO3_MODE') or die();

in the short run (adding it when touching the file anyway, maybe even 
adding it to cached PHP code)

and 1. in the long run.

Kind regards,
Helmut

-- 
Helmut Hummel
Release Manager TYPO3 6.0
TYPO3 Core Developer, TYPO3 Security Team Member

TYPO3 .... inspiring people to share!
Get involved: typo3.org


More information about the TYPO3-team-core mailing list