[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