HTML5 Cross Origin Request Sicherheit

HTML5 Cross Origin Request Sicherheit

Marc Ruef
by Marc Ruef
time to read: 7 minutes

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.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You need support in such a project?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here