Bug #21346

Page tree will not be shown in the typo3 backend

Added by Stefan Hug almost 7 years ago. Updated about 6 years ago.

Status:Closed Start date:2009-10-23
Priority:Must have Due date:
Assigned To:Oliver Hader % Done:

0%

Category:- Spent time: -
Target version:-
TYPO3 Version:4.2 Complexity:
PHP Version:5.2 Is Regression:
Tags: Sprint Focus:

Description

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/&currentSubScript=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)

bug_12324.patch Magnifier (486 Bytes) Administrator Admin, 2009-10-26 10:31

0012324_typo3_4-3.patch Magnifier (8 kB) Administrator Admin, 2009-11-13 11:44

0012324_typo3_4-2.patch Magnifier (5.4 kB) Administrator Admin, 2009-11-13 11:45


Related issues

related to Core - Bug #21971: Changed PHP System requirements with Minor Release Versio... Closed 2010-01-16
related to Core - Bug #21544: Pagetree frame shows HTTP 404 error Closed 2009-11-13
related to Core - Bug #21600: Page tree will not be shown in the typo3 backend Resolved 2009-11-18
duplicated by Core - Bug #21441: I can't access to Tree Folder in the background Resolved 2009-11-03

History

#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_\/\.&=\?~-]+$/';

Greetings Marco

#4 Updated by Stefan Hug almost 7 years ago

Hello Marco

Yes, that works perfect.

#5 Updated by Ingmar Schlecht almost 7 years ago

FYI.

#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)?

#7 Updated by Stefan Hug almost 7 years ago

Hi Oliver, we use the backend.php.

#8 Updated by Peter Niederlag almost 7 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 almost 7 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 almost 7 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 almost 7 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).

#12 Updated by Ingmar Schlecht almost 7 years ago

I agree about the Umlauts, Peter.

#13 Updated by Steffen Kamper almost 7 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 almost 7 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 almost 7 years ago

then create a blacklist with this 3 chars, more easy ;)

#16 Updated by Oliver Klee almost 7 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 almost 7 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 almost 7 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 almost 7 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 almost 7 years ago

(I'm concerned that we might open new security holes if we freely allow lots of characters.)

#21 Updated by Steffen Kamper almost 7 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 almost 7 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 almost 7 years ago

What about using \w in the RexExp? So the Webserver can do the language specific stuff.

#24 Updated by Marcus Krause almost 7 years ago

It's probably too late but:
Revisions 6235-6237 [1] 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.

[1] http://forge.typo3.org/repositories/revision/27/6235

#25 Updated by Helmut Hummel almost 7 years ago

I agree with Marcus here.
Using

t3lib_div::isURL($url)
and
t3lib_befunc::isAllowedSite($url)

would be the cleanest solution

#26 Updated by Oliver Hader almost 7 years ago

Committed to SVN:
  • Trunk - part of TYPO3 4.3-beta3
  • TYPO3_4-2 - part of TYPO3 4.2.11

Pending for TYPO3_4-1

#27 Updated by Benni Mack over 6 years ago

Hello Olly,

should we close this issue?

#28 Updated by Benni Mack about 6 years ago

Fixed (and released) in all maintained versions, so I close this issue.

Also available in: Atom PDF