Page tree will not be shown in the typo3 backend
|Priority:||Must have||Due date:|
|Assigned To:||Oliver Hader||% Done:||
|PHP Version:||5.2||Is Regression:|
If you don't use a real domain like www.mydomain.ch/typo3 (example http://194.150.249.xxx/~mydomain/typo3 the page tree will not be shown in the typo3 backend by firefox. There is only an error message:
The requested URL /~mydomain/typo3/¤tSubScript=sysext/cms/layout/db_layout.php was not found on this server.
With IE7 this message will disappear and the page tree will be shown if you click again on the page icon. On firefox unfortunately not.
(issue imported from #M12324)
#1 Updated by Stefan Terborg almost 7 years ago
I had this problem when the directory had a "-" in its name. When I removed the "-" the page tree appeared.
#2 Updated by Stefan Hug almost 7 years ago
We haven't any - in the directroy. And the problem is only in the newest Version 4.2.10. All other Version works correct. The problem is that we have many accounts on a multihoster and as long as the dns is not configured we have only access this way (http://194.150.249.xxx/~mydomain/typo3). As soon as you work with the real domain you don't have any problems with the Version 4.2.10
#3 Updated by Marco Gilbert almost 7 years ago
In typo3_src-4.2.10/t3lib/class.t3lib_div.php Line 3878
Should look like
$whitelistPattern = '/^[a-zA-Z0-9_\/\.&=\?~-]+$/';
#6 Updated by Oliver Klee almost 7 years ago
Stefan, are you using the new BE (backend.php) or the old BE (alt_main.php)?
#8 Updated by Peter Niederlag over 6 years ago
This is indeed a serious problem to all users who operate a TYPO3 installation in a subdirectory with '~' or '-' in the name, which is perfectly valid and reasonable.
Can't find ethe pending patch on core list to fix the issue, I'll attach one right away.
#9 Updated by Ingmar Schlecht over 6 years ago
Could you try to find out about all characters allowed in directory names? So we have a full solution here. Thanks in advance!
#10 Updated by Oliver Klee over 6 years ago
I think we only need to allow characters that make sense as part of URLs. So eg. spaces shouldn't be allowed. (I'd like to keep the whitelisting as narrow as possible and as wide as needed.)
#11 Updated by Peter Niederlag over 6 years ago
I second Oliver here, '~' and '-' are rather common in subdirectory names. However it is even valid to have a ':', '"' or other "weird" charcters in directory names. This might evend depend on the OS. My sggestion would be to stick with "common" characters for now.
A rather usefull addition probably would be to allow additional internationl/UTF-8 characters (ü,ö and alike).
#13 Updated by Steffen Kamper over 6 years ago
this should match the most chars:
$whitelistPattern = '/^[a-zA-ZäöüÄÖÜß0-9_\/\.&=\?:~%$§!-]+$/';
Opposite question: which chars should be denied?
#14 Updated by Oliver Klee over 6 years ago
Most important is : because this blocks URLs liks http://myeveilserver.com/. % also needs to be blocked because it allows encoding other possibly dangerous characters.
I don't think we need to allow § $ either - they're not expected to be used in file names that are part of URLs.
So, to sum it up, we should block : % § $
#15 Updated by Steffen Kamper over 6 years ago
then create a blacklist with this 3 chars, more easy ;)
#16 Updated by Oliver Klee over 6 years ago
I strongly object. Blacklisting is less secure than whitelisting because it allows any potentially dangerous characters which we might have forgotten. We want this to be as secure as possible.
#17 Updated by Steffen Kamper over 6 years ago
i object your objection. If you forget something you have to add it, same in whitelist as in blacklist.
If you create whitelist you have to include te complete universe "except" the things you want to prevent. Result is that you forgot some chars and many users can't use BE anymore, that's more worse!
#18 Updated by Steffen Kamper over 6 years ago
one addition: in this case we are talking about "names". Think about languages (russian, arabic, chinese etc) and all possible charsets.
#19 Updated by Oliver Klee over 6 years ago
I agree that we need to add the stuff which we've forgotten.
In this case, it's all about directory names that are part of URLs. Do we really need to cover the case of non-ASCII-characters for this? I'm referring to what's common, not what is possible if someone tries to create file names that might break the BE login.
#20 Updated by Oliver Klee over 6 years ago
(I'm concerned that we might open new security holes if we freely allow lots of characters.)
#21 Updated by Steffen Kamper over 6 years ago
comparing to what we had before you don't open new holes, you close known holes. That should be the policy, same with XSS - instead of forbid all you only forbid the methods you know.
#22 Updated by Rupert Germann over 6 years ago
I'd say the whitelist pattern from marco is sufficient. In any case we must block the colon : because if not, then the attack which is described in the original bug, works again.
#23 Updated by Marco Gilbert over 6 years ago
What about using \w in the RexExp? So the Webserver can do the language specific stuff.
#24 Updated by Marcus Krause over 6 years ago
It's probably too late but:
Revisions 6235-6237  are clearly the root cause for this bug. I simply wonder why the methods, introduced with #0010724, haven't been used to prevent "external frame inclusions".
In addition, the name of the newly introduced method t3lib_div::sanitizeBackEndUrl() is a bit misleading; the method is not sanitizing, it's only accepting or denying a given string. And that is what we like to have for "prevention of external frame inclusion", either the url is valid or not. We do not want to sanitize anything.
#25 Updated by Helmut Hummel over 6 years ago
I agree with Marcus here.
would be the cleanest solution
#26 Updated by Oliver Hader over 6 years ago
- Trunk - part of TYPO3 4.3-beta3
- TYPO3_4-2 - part of TYPO3 4.2.11
Pending for TYPO3_4-1