TYPO3 Core

I had this problem when the directory had a "-" in its name. When I removed the "-" the page tree appeared.

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

In typo3_src-4.2.10/t3lib/class.t3lib_div.php Line 3878
Should look like

$whitelistPattern = '/^[a-zA-Z0-9_\/\.&=\?~-]+$/';

Greetings Marco

Hello Marco

Yes, that works perfect.

FYI.

Stefan, are you using the new BE (backend.php) or the old BE (alt_main.php)?

Hi Oliver, we use the backend.php.

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.

Could you try to find out about all characters allowed in directory names? So we have a full solution here. Thanks in advance!

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.)

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).

I agree about the Umlauts, Peter.

this should match the most chars:

$whitelistPattern = '/^[a-zA-ZäöüÄÖÜß0-9_\/\.&=\?:~%$§!-]+$/';

Opposite question: which chars should be denied?

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 : % § $

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

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.

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!

one addition: in this case we are talking about "names". Think about languages (russian, arabic, chinese etc) and all possible charsets.

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.

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

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.

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.

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

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

I agree with Marcus here.
Using

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

would be the cleanest solution

• Trunk - part of TYPO3 4.3-beta3
• TYPO3_4-2 - part of TYPO3 4.2.11

Pending for TYPO3_4-1

Hello Olly,

should we close this issue?

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