HTML5 Cross Origin Request Sicherheit

HTML5 Cross Origin Request Sicherheit

Marc Ruef
von Marc Ruef
Lesezeit: 7 Minuten

Die Weiterentwicklung der modernen Informationsgesellschaft schafft stetig neue Anforderungen an das Internet. Als Folge davon werden fortwährend neue Standards geschaffen und bestehende Technologien weiterentwickelt. Als Kernbestandteil des modernen World Wide Web gilt die Seitenbeschreibungssprache HTML. Gegenwärtig wird die Entwicklung von HTML5 vorangetrieben. Populäre Webseiten wie YouTube versuchen das proprietäre Flash durch die neuen Multimedia-Funktionen von HTML5 abzulösen und verhelfen so früher oder später der neuen Version zum breitflächigen Durchbruch.

Gegenwärtig ist der siebte Arbeitsentwurf herausgegeben worden. Noch nicht alle Webbrowser unterstützen die jeweiligen Spezifikationen. Es ist jedoch absehbar, dass so manches neue Feature schnellstmöglich implementiert werden will, um die Reichhaltigkeit des World Wide Web vorantreiben zu können.

Eine der zentralen Funktionen von HTML5 ist Cross Origin Request und erweitert die Möglichkeiten des Browsers, Ajax-ähnliche Zugriffe domänenübergreifend durchzuführen. Die traditionelle Same Origin Policy sah vor, dass mit Javascript umgesetzte HTTP-Anfragen nur für jene Domain umgesetzt werden kann, von der das Javascript-Dokument geladen wurde. Mit COR können nun auch HTTP-Anfragen für gänzlich andere Webseiten durchgeführt werden. Die Vernetzung unterschiedlicher Angebote wird damit vorangetrieben:

Web application technologies commonly apply same-origin restrictions to network requests. These restrictions prevent a (client-side) Web application running from one origin from obtaining data retrieved from another origin, and also limit the amount of unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application’s origin.

Vielerorts wird die Sicherheit von COR rege diskutiert. Die Diskussionen fokussieren sich dabei jedoch auf die Sicht der Webentwickler und Webadministratoren. COR-Rückantworten können durch den Browser nur dann angesteuert werden, wenn der Server in seiner Rückantwort die Header-Zeile Access-Control-Allow-Origin mitschickt, wobei als Parameter das Quellsystem angegeben werden muss. Beispiel PHP:

header('Access-Control-Allow-Origin: http://www.scip.ch/demo/cor/*');
echo 'This is a successful cor response.';

Als Hauptrisiko hiervon wird vorgetragen, dass freizügige Zugriffsmöglichkeiten (z.B. mit dem Wildcard-Zeichen *) zu unerwünschten Datenabfragen führen können.

Unseres Erachtens ist dieses Risiko im Verhältnis vernachlässigbar. Die Webapplikation sollte sowieso eine umfassende Prüfung durchführen, ob das Quellsystem den gewünschten Datenzugriff durchführen darf. Authentisierung und Session-Management sind nach wie vor erforderlich und können durch den Access-Control Header nur bedingt ersetzt – stattdessen aber ergänzt – werden.

Das grössere Problem von COR ist jedoch die Möglichkeit von Webadministratoren, dass diese Webbrowser zu automatisierten Zugriffen auf anderen Webseiten zwingen können. Durch den Besuch einer vermeintlich legitimen Webseite kann ohne Probleme eine Cross Site Request Forgery durchgesetzt werden. Nachfolgendes Javascript-Snipplet kann in onload aufgerufen werden, um automatisch eine weiterführende Anfrage durchzusetzen:

function req(){
	var cor;
	if(window.XDomainRequest){
	    cor = new XDomainRequest();
	    if(cor){
	        cor.onload = function(){
			alert(cor.responseText);
	        }
	    }else{
		alert('Your Browser does not support Cross Origin Request');
	    }
	}else{
	    cor = new XMLHttpRequest();
	    cor.onreadystatechange = function(){
	        if(cor.readyState == 4){
	            alert(cor.responseText);
	        }
	    }
	}
	cor.open('GET', 'http://www.scip.ch/labs/demos/cor/cor.php');
	cor.send();
}

Sieht die aufgerufene Ressource – in diesem Fall http://www.scip.ch/labs/demos/cor/cor.php – keinen Zugriff durch die Freigabe über Access-Control-Allow-Origin zu, dann kann zwar der Browser nicht auf die in cor.responseText vorgesehene Antwort zugreifen. Die Anfrage selbst wird aber in jedem Fall, wird COR denn durch den Browser unterstützt, umgesetzt. Es gibt eine Vielzahl an Angriffsszenarien, die mit diesen Möglichkeiten realisiert werden können (sie betreffen Teilweise auch SOP):

Wir empfehlen dem HTML5-Gremium, die Legitimität der COR-Zugriffe nicht erst durch die angefragte Ressource bestimmen und danach durch den Client anhand der Rückantwort limitieren zu lassen. Stattdessen sollte schon vor dem Zugriff eine Einschränkung durchgesetzt werden. Und genau hier täte es eigentlich aus Sicht der Sicherheit gut, bei der klassischen Same Origin Policy zu bleiben – Stattdessen wird jedoch die Browser-Sicherheit den technischen Möglichkeiten von COR geopfert.

Die Benutzer haben das Nachsehen, sind sie denn in erster Linie auf die Sicherheitsmechanismen der Browserhersteller angewiesen. Es ist zu hoffen, dass die Browserentwickler darum bemüht sind, dass sich granulare Einstellungen in der Konfiguration des Webbrowsers vornehmen lassen, um Ressourcen dediziert Sperren oder eine manuelle Freigabe angehen zu können.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv