Blogix

Statische Dateien (z.B. CSS, JS, Bilder) verfügen in der Standardkonfiguration von diversen Webservern über keine Expires-Header. Dies führt dazu, dass Dateien i.d.R. vom Browser nicht im Cache zwischengespeichert werden und stets eine Anfrage an den Server gesendet wird. Neben einer größeren Belastung für den Server führt es außerdem zu langsameren Ladezeiten der Webseite. Mit dem Apache-Modul mod_exprires – bei Debian z.B. standardmäßig mit Apache installiert – kann der Expires-Header gesetzt und dem Browser mitgeteilt werden, wie lange sich dieses Element nicht ändern wird. Hierfür fügt man der .htaccess-Datei folgende Zeilen hinzu:

<IfModule mod_expires.c>
	ExpiresActive On
	#ExpiresDefault "access plus 7 days"
	ExpiresByType image/bmp "access plus 7 days"
	ExpiresByType image/gif "access plus 7 days"
	ExpiresByType image/jpeg "access plus 7 days"
	ExpiresByType image/jpg "access plus 7 days"
	ExpiresByType image/png "access plus 7 days"
	ExpiresByType image/x-icon "access plus 7 days"
	ExpiresByType text/css "access plus 7 days"
	ExpiresByType text/javascript "access plus 7 days"
	ExpiresByType text/x-js "access plus 7 days"
	ExpiresByType application/javascript "access plus 7 days"
	ExpiresByType application/x-javascript "access plus 7 days"
</IfModule>

Die Verwendung von ExpiresDefault (hier nicht aktiviert) würde dazu führen, dass für jede ausgelieferte Datei ein Expires-Header gesetzt werden würde. Dies sollte bei dynamisch generierten Webseiten vermieden, da diese aus dem Browser-Cache und nicht vom Server geladen werden und somit nicht den aktuellen Stand widerspiegeln würden. Header für JPG-Bilder und JavaScript werden in diesem Beispiel mehrfach gesetzt, damit unterschiedliche Mime-Types aufgrund verschiedener Konfigurationen von Servern und Ausgaben von Skripts abgedeckt sind.

Alternativ ist es auch möglich, den Expires-Header anhand der Dateiendung zu setzen:

<FilesMatch "\.(bmp|gif|jpg|jpeg|png|ico|css|js)">
	<IfModule mod_expires.c>
		ExpiresActive On
		ExpiresDefault "access plus 7 days"
	</IfModule>
</FilesMatch>

Diese Methode zeigt allerdings nur bei statischen Dateien Wirkung, weshalb bei z.B. dynamisch generierten Bildern die Mime-Type-Lösung gewählt werden muss.

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 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 =
	}
}

Dank steigender Bandbreiten und günstigeren Monatsgebühren für das Internet nehmen die Anzahl der Webapplikationen wie Google Apps immer weiter zu. Wer selten Textverarbeitung oder Tabellenkalkulation benötigt, möchte nicht unbedingt unnötig Speicherplatz für kostenlos erhältliche Office Suiten wie OpenOffice oder NeoOffice belegen, oder gar Microsoft Office kaufen. Auch häufig verwendete Applikationen in Firmen wie Support- und Customer Relationship Systeme sind meist nur als Webapplikation verfügbar. Der Nachteil dabei ist allerdings, dass für jede Applikation ein eigener Tab im Browser benötigt wird. Besonders ärgerlich wird es, wenn nicht gespeicherte Arbeiten aufgrund eines abgestürzten Browsers verloren gehen.

Abhilfe schafft das für Mac OS X kostenlos erhältliche Programm Fluid. Aus Webapplikationen werden eigenständige Cocoa-Programme (wie z.B. Safari oder Mail) erzeugt, die als Icon im Dock oder in der Menüleiste abgelegt werden können. Diese Webapplikationen sind dadurch schnell griffbereit, ohne zuerst einen Browser starten oder den Tab wechseln zu müssen. Hervorragend geeignet ist Fluid übrigens auch für Webmail-Benutzer.

Bei der Entwicklung von Webseiten werden (logischerweise) sehr oft Änderungen an HTML, CSS, JS, etc. durchgeführt. Dabei kann es passieren, dass Änderungen nach dem erneuten Laden der Seite (Refresh/Reload) nicht angezeigt werden, da die Seite bzw. die eingebundenen Dateien aus dem Cache des Browsers und nicht wie gewünscht erneut vom Server geladen werden. D.h. es sieht so aus, als ob die durchgeführten Änderungen (auch) nicht den gewünschten Effekt hervorrufen, obwohl sie das (wenn die komplette Seite vom Server geladen werden würde) vielleicht machen.

Abhilfe schafft es, wenn man den lokalen Cache im Browser deaktiviert. Dafür kann man entweder in den Einstellungen des Browsers die gewünschte Einstellung vornehmen, was aber beim Besuch von anderen Webseiten (beim “normalen” Surfen) nicht unbedingt erwünscht ist.

Für auf der Gecko-Engine basierende Mozilla-Browser gibt es die Web Developer Toolbar von Chris Pederick. Diese erlaubt es den Cache sehr einfach zu deaktivieren bzw. auch wieder zu aktivieren:

Eine weitere und wohl die bequemste Möglichkeit ist es, die Tastenkürzel der einzelnen Browser zu verwenden, die nicht nur die Seite neu laden, sondern auch den lokalen Cache der aktuellen Seite löschen:

• Internet Explorer: Strg + F5 (Windows)
• Firefox: Strg + F5 oder Strg + Umschalt + R (Windows) bzw. Cmd + Umschalt + R (Mac)
• Safari: Cmd + Umschalt + R (Mac)