Blogix

Damit sich z.B. Thumbnails perfekt in das bestehende Design einer Seite integrieren, kann es nötig sein dieses auf ein quadratisches Format zuzuschneiden. Das Originalbild soll dabei so skaliert werden, dass die kürzere Seite des Bildes der Seitenlänge des Thumbnails entspricht. Die überstehenden Ränder der längeren Seite des zentriert positionierten Bildes sollen abgeschnitten werden. Mit der IMAGE-Funktionalität von TYPO3 lässt sich diese Anforderung mit relativ wenig Aufwand bewerkstelligen – dafür ist lediglich folgendes TypoScript nötig:

thumbnail = IMAGE
thumbnail {
	file = fileadmin/user_upload/image.jpg
	file.width = 100c
	file.height = 100c
}

In einer eigenen Extension würde der PHP-Code wie folgt aussehen:

$thumbnail = array();
$thumbnail['file'] = 'fileadmin/user_upload/image.jpg';
$thumbnail['file.']['width'] = '100c';
$thumbnail['file.']['height'] = '100c';
$thumbnail = $this->cObj->IMAGE($thumbnail);

Manche Programme bieten die Möglichkeit ein Icon in der Menüleiste zu positionieren, zusätzlich werden sie allerdings noch im Dock angezeigt und vergeuden somit (zumindest auf kleinen Monitoren) wertvollen Platz. Manchmal findet man in den Einstellungen des Programms eine Option zum Verstecken des Dock-Icons, aber nicht alle Programme bieten diese angenehme Option. Cocoa-Programmen kann man allerdings sehr einfach beibringen, dass diese nicht mehr im Dock angezeigt werden sollen. Hierfür führt man auf das Programm im Finder einen sekundären Klick (i.d.R. Rechtsklick) aus und wählt “Paketinhalt zeigen” aus. Nun wird der Inhalt des Programm-Pakets angezeigt, hier navigiert man in den Ordner “Contents” und öffnet die Datei “Info.plist” mit einem beliebigen Texteditor. Zwischen “<dict>” und “</dict>” der ersten Ebene (am einfachsten direkt nach dem ersten “<dict>”) fügt man folgende Zeilen ein:

<key>LSUIElement</key>
<string>1</string> 

Nach dem nächsten Start des Programms sollte das Icon im Dock versteckt bleiben. Nachteil dieser Einstellung ist, dass die Menüleiste des Programms nicht mehr erreicht werden kann. Ein Programm, dass diese Aufgabe übernimmt ist Dock Dodger.

In alten Versionen war es möglich, dass RealURLs “baseURL” automatisch gesetzt wurde, indem man ihr den Wert “1″ zuwies. Das wurde allerdings als Sicherheitsrisiko eingestuft und deshalb besteht diese Möglichkeit in aktuellen Versionen nicht mehr. Die Anzahl der Domains sollte sich allerdings in Grenzen halten und man kann mit TYPO3-Conditions das Problem der unterschiedlichen URLs umschiffen:

config.baseURL = http://www.blogix.net/
[globalString = ENV:HTTP_HOST = www.example.com]
	config.baseURL = http://www.example.com/
[globalString = ENV:HTTP_HOST = www.example.net]
	config.baseURL = http://www.example.net/
[global]

In diesem Beispiel wird standardmäßig der URL http://www.blogix.net/ als baseURL verwendet. Wird die Seite über die Domain “www.example.com” aufgerufen wird “http://www.example.com/” verwendet, für die Domain “www.example.net” “config.baseURL = http://www.example.net/”.

Nun möchte ich noch auf das oben genannte Sicherheitsrisiko eingehen – da es keine offizielle Stellungnahme zum Problem gibt, hier meine Vermutungen, wie die automatische Konfiguration eigentlich nur zu einem Sicherheitsproblem werden kann:

Voraussetzungen am Server:

1. Der Webserver muss die TYPO3-Seite IP-basiert und nicht domainbasiert ausliefern, d.h. ein Aufruf der IP-Adresse im Browser würde die TYPO3-Seite zeigen.
2. Cache muss in TYPO3 aktiviert sein, warum sehen wir gleich.

Der Angriff:

1. Eine Domain so einrichten, dass sie auf die IP-Adresse des Servers verweist – da der Server IP-basiert und nicht domainbasiert auf die Anfrage antwortet, liefert dieser die TYPO3-Seite aus.
2. Die TYPO3-Seite über die in Schritt 1 eingerichtete Domain per Browser oder Skript aufrufen – nun müsste die Seite im Cache landen, dieser “vergiftet” werden, damit weitere Schritte des Angreifers zu seinem Erfolg führen.
3. Die in Schritt 1 eingerichtete Domain wird nun umkonfiguriert, sodass sie auf eine böse Seite (z.B. Malware oder eine Konkurrenzseite) zeigt.

Der Besucher und die Weiterleitung:

1. Die TYPO3-Seite wird über die bekannte Domain aufgerufen.
2. Eingebundene Bilder kommen von bzw. Links führen zu der Domain des Angreifers, da die baseURL aus dem “vergifteten” Cache von TYPO3 stammt.

Das Problem kann meiner Meinung nach nur entstehen, wenn der Webserver die TYPO3-Seite IP-basiert ausliefert. D.h. bei ausschließlich domainbasierter Auslieferung führt oben genanntes Szenario nicht zum Erfolg des Angreifers und die Verwendung der automatischen Konfiguration wäre meiner Meinung nach sicher. Dass kein weiteres Szenario für einen erfolgreichen Angriff existiert, kann ich nicht ausschließen. Mit dem Plugin “lt_basetag” kann die automatische Konfiguration wieder aktiviert werden – Verwendung natürlich auf eigene Gefahr.

In manchen Fällen kann es notwendig sein, dass man in TypoScript eine eigene Funktion für eine Condition benötigt. So könnte man z.B. dem Benutzer bei einer aufrechten HTTPS-Verbindung das Trust-Logo einblenden, damit dieser auf einen Blick weiß, dass er über eine gesicherte Verbindung auf die Seite zugreift.

Zuerst muss die Funktion implementiert werden, hierfür legt man z.B. die Datei “fileadmin/media/scripts/isHttps.php” mit folgendem Inhalt an:

function user_isHttps() {
	if ($_SERVER['HTTPS']) {
		return true;
	}
	return false;
}

Wichtig ist, dass die Funktion mit dem Prefix “user_” beginnt.

Die soeben erstellte Datei muss nun in TypoScript mit der folgenden Zeile eingebunden werden:

includeLibs.userFunc = fileadmin/media/scripts/isHttps.php

Nun kann die Funktion in einer Condition wie folgt verwendet werden:

[userFunc =  user_isHttps]
	temp.obj = TEXT
	temp.obj.value = die Ausgabe
[global]

Auch die Übergabe eines Parameters ist möglich (z.B. “[userFunc = user_Function('Parameter')]“) - die Funktion muss diesen dann natürlich auch erwarten (z.B. “function user_Function($parameter) {“).