Blogix

Wenn man mittels AJAX Daten von TYPO3 laden möchte, stößt man auf das Problem, dass TYPO3 grundsätzlich immer das Template rendert und somit eine Ausgabe von reinen Daten (z.B. XML oder JSON) nicht ohne weiteres möglich ist. Da aber die Ausgabe von reinen Daten (ohne Template) des Öfteren benötigt wird, stellt TYPO3 bereits ein Feature namens eID bereit. Sobald in der URL der Parameter eID vorkommt, wird eine alternative Rendering-Engine benutzt und es kann eine reine Daten-Ausgabe mit PHP erzeugt werden, ohne auf die gewohnten Funktionen aus dem TYPO3-Framework verzichten zu müssen.

Um dieses Feature nutzen zu können, muss man wie folgt vorgehen (analog zu TYPO3 CLI):

1. Erstellen eines Ordners namens “eid” im Ordner der Extension (z.B. in “typo3conf/ext/extensionkey/”)
2. Erstellen einer Datei (z.B. “class.tx_extensionkey_eid.php” – Name grundsätzlich egal) im in Schritt 1 erstellten Ordner “eid” mit dem Inhalt [1]
3. Erstellen (sofern noch nicht vorhanden) der Datei “ext_localconf.php” im Ordner der Extension (z.B. in “typo3conf/ext/extensionkey/”) mit dem Inhalt [2] (vorhandenen Inhalt nicht überschreiben, sondern nur hinzufügen)
4. Aufrufen des Skripts (z.B. “http://localhost/?eID=extensionkey”)

[1]:

<?php
/***************************************************************
*  Copyright notice
*
*  (c) 2009 Your name <email@example.com>
*  All rights reserved
*
*  This script is part of the TYPO3 project. The TYPO3 project is
*  free software; you can redistribute it and/or modify
*  it under the terms of the GNU General Public License as published by
*  the Free Software Foundation; either version 2 of the License, or
*  (at your option) any later version.
*
*  The GNU General Public License can be found at
*  http://www.gnu.org/copyleft/gpl.html.
*
*  This script is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
*  GNU General Public License for more details.
*
*  This copyright notice MUST APPEAR in all copies of the script!
***************************************************************/
if (!defined ('PATH_typo3conf')) 	die ('Access denied: eID only.');
require_once(PATH_tslib . 'class.tslib_pibase.php');

class tx_selfadmin_eid extends tslib_pibase {
	var $prefixId      = 'tx_extensionkey_eid';		// Same as class name
	var $scriptRelPath = 'eid/class.tx_extensionkey_eid.php';	// Path to this script relative to the extension dir.
	var $extKey        = 'extensionkey';	// The extension key.

	function eid_main() {
		$GLOBALS['TSFE']->fe_user = tslib_eidtools::initFeUser();
		tslib_eidtools::connectDB();
		var_dump($GLOBALS['TSFE']->fe_user);
	}
}

$extensionkey = t3lib_div::makeInstance('tx_extensionkey_eid');
$extensionkey->eid_main();

?>

Möchte man in diesem Skript nun auf Funktionen (z.B. Datenbank) aus dem TYPO3-Framework zurückgreifen, so muss man für die Instantiierung selbst sorge tragen. In der Datei “typo3_src/typo3/sysext/cms/tslib/class.tslib_eidtools.php” findet man vorgefertigte Methoden um auf die Daten eines FE-Users oder die Datenbank zugreifen zu können (Verwendung siehe im Code oben).

[2]:

<?php
  ## Adding alternative output engine to eID mechanism
$TYPO3_CONF_VARS['FE']['eID_include'][$_EXTKEY] = 'EXT:'.$_EXTKEY.'/eid/class.tx_extensionkey_eid.php';
?>

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

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

In der Standardkonfiguration von TYPO3 werden externe Links mit target=”_blank” versehen, entsprechen somit nicht mehr dem XHTML 1.0 Strict-Standard und überschreiben die Browser-Voreinstellungen des Benutzers. Anstelle von XHTML 1.0 Strict könnte man den DOCTYPE wechseln, z.B. XHTML 1.0 Transitional verwenden. Meine Meinung ist allerdings, dass man als Webentwickler nicht in die bevorzugten Einstellungen der Benutzer eingreifen sollte und deshalb sollte man unter anderem target=”_blank” nicht verwenden. In TYPO3 sind zahlreiche Einstellungen mittels TypoScript vorzunehmen, um (alle) target=”_blank” aus den Links zu entfernen. Folgende Einstellungen sind hierfür erforderlich und müssen in das “CONSTANTS”-Feld des Templates der Root-Page eingefügt werden:

PAGE_TARGET =
content.pageFrameObj =
styles.content {
	links {
		extTarget =
		target =
	}
	loginform.target =
	mailform.target =
	searchresult {
		resultTarget =
		target =
	}
}