Geschrieben von: Christoph Wille
Kategorie: Sicherheit
This printed page brought to you by AlphaSierraPapa
Wer mehr als eine Site pro Server betreibt - und nicht nur ISP's sind davon betroffen - kommt möglicherweise irgendwann einmal in die Situation, daß eine am Server installierte Komponente nur bestimmten Websites zur Verfügung stehen soll. Entweder ist der Grund, daß nur der zahlende Kunde diese verwenden können soll (und keine andere zufällig am gleichen Server laufende Site), oder daß bestimmte Komponenten sicherheitssensitiv sind (Businesslogikkomponenten zum Beispiel).
Wie immer führen mehrere Wege nach Rom, aber grundsätzlich haben alle etwas mit der Sicherheit von NT zu tun - den Access Control Lists (ACL). Im Prinzip sorgt man einfach dafür, daß nur berechtigte Accounts Zugriff auf die für die Komponente wichtigen Daten bekommen: das ist einerseits die DLL/EXE in der die Komponente "lebt", andererseits die Informationen zur Komponenteninstanzierung in der Registrierdatenbank.
Der schnellste Weg zum Ziel sind NTFS Berechtigungen auf der DLL/EXE der Komponente. Als Beispielkomponente habe ich AspTear verwendet, und ein wirklich sehr minimales Testscript:
<%
Set xObj = Server.CreateObject("SOFTWING.ASPtear")
%>
Normal aufgerufen ist der Output dieses Scripts exakt gar nichts - eine leere Seite. Ändert man die NTFS Permissions auf asptear.dll allerdings von Everyone/Full Control (Standardeinstellung) auf zB Administrator und SYSTEM/Full Control, dann sieht das Ergebnis so aus:
Microsoft VBScript runtime error '800a01ad' ActiveX component can't create object /aspheute/DllCage/doasptear.asp, line 2
Achtung ASP und IIS cachen die Class Factories der Komponenten, um die Performance zu erhöhen. Um daraus resultierende Seiteneffekte für Komponententests zu verhindern, rufen Sie nach der Änderung immer zuerst net stop iisadmin /y gefolgt von net start w3svc auf.
Mit dieser Radikalkur ist mir nicht geholfen, da nun niemand mehr Zugriff auf die Komponente hat. Wie bringe ich die Komponente wieder zum Laufen? Nun, da Sites standardmäßig Pooled laufen (siehe Screenshot),
muß man Read und Execute für den IWAM_machinename Account hinzufügen:
Und schon funktioniert die Seite wieder! Der Haken an der Sache - es funktioniert wieder für alle Sites, die Pooled laufen - also alle Sites. Wenn man sich eine neue Applikation im Internet Services Manager (ISM) erstellen läßt, wird diese in Component Services eingetragen (hier ist die Standard-Pooled Applikation selektiert, nur damit jeder weiß, wo sie zu finden ist):
Die letzten beiden Applikationen in der Liste sind eigenständige Applikationen, denen man - genauso wie der Pooled Applikation - einen anderen Account zuweisen kann (und muß, wenn man die verschiedenen Sites auf diese Weise auseinanderhalten will):
Also muß man folgendes beachten, um eine Komponente per NTFS ACL's abzusichern:
Die oben vorgestellte Methode funktioniert bis zu einem genau definierten Knackpunkt: was macht man, wenn Site A Komponente X verwenden darf, und Site B Komponente Y - aber X und Y in ein und derselben DLL gespeichert sind? Abstrakt? Keineswegs: Scripting.Dictionary und Scripting.FileSystemObject teilen sich eine gemeinsame DLL - und hin und wieder kann das Sperren des FileSystemObjects für eine Site wichtig werden.
Die Problemstellung ist nun bekannt, was macht man? Eine Komponente kann via Server.CreateObject sowohl über ProgId (zB Scripting.FileSystemObject) oder ClassId (zb {A06F79A7-A329-11D2-880F-0020AFD81B6D}) instanziert werden. Beide sind in der Registry gespeichert, und sagen COM+, wie die Komponente geladen werden muß (vereinfacht dargestellt). Da die ClassId letzlich das für COM+ ausschlaggebende Stück Information ist, muß nur diese per ACL abgesichert werden.
Wie stellt man das an? Als erstes startet man regedit.exe und sucht nach der ProgId, in unserem Fall Scripting.FileSystemObject:
Ein Doppelklick auf (Default) und man kann aus der Edit String Dialogbox die zugehörige ClassId in die Zwischenablage herauskopieren. Nun startet man den "richtigen" Registry-Editor, nämlich regedt32.exe - denn nur dieser kann verwendet werden, um ACL's zu setzen - aber dessen Suchfunktionen sind höflich formuliert sehr eingeschränkt, deswegen der Umweg über regedit.exe.
Wir sind also im Registry Editor (regedt32.exe). Dort wählt man das Fenster mit dem HKEY_LOCAL_MACHINE Zweig der Registry, und startet im View Menü den Find Key Befehl. Dort fügt man die zuvor kopierte ClassId ein und klickt auf Find Next. Die richtige Fundstelle hat man dann, wenn das Element ein Plussymbol zeigt, aufgemacht werden kann, und einen ProgId Unterschlüssel hat:
Der schwierige Teil ist nun vorbei - unter Security / Permissions findet man nun die gewohnte ACL Dialogbox wieder. Damit ein User eine Komponente erstellen kann, muß er Leseberechtigung auf dem Schlüssel (und Unterschlüsseln) haben. Der folgende ACL zB zeigt, daß IWAM_machinename keinerlei Zugriff hat:
Und richtig, das FileSystemObject ist ab sofort off-limits:
Microsoft VBScript runtime error '800a01ad' ActiveX component can't create object /AspHeute/DllCage/dofso.asp, line 2
Es gilt hier genau das gleiche wie für NTFS Berechtigungen - nur die User zulassen, die auf die entsprechenden COM+ Applikationen (Web Applikationsroots) zugewiesen sind.
Durch Änderungen an NTFS und Registry Permissions kann man auch die Büchse der Pandora öffnen - man sollte sich unbedingt den Artikel Schritt-für-Schritt Debuggen von Sicherheitsproblemen durchlesen!
This printed page brought to you by AlphaSierraPapa
Der Microsoft Baseline Security Analyzer (MBSA) 1.0
http:/www.aspheute.com/artikel/20020412.htm
Schritt-für-Schritt Debuggen von Sicherheitsproblemen
http:/www.aspheute.com/artikel/20011119.htm
Verzeichnissicherheit mit NTFS und IIS Authentifizierung
http:/www.aspheute.com/artikel/20001109.htm
Vorsicht Falle: Dateien, die keine sind
http:/www.aspheute.com/artikel/20020131.htm
AspTear
http://www.alphasierrapapa.com/componentcenter/asptear/
©2000-2006 AspHeute.com
Alle Rechte vorbehalten. Der Inhalt dieser Seiten ist urheberrechtlich geschützt.
Eine Übernahme von Texten (auch nur auszugsweise) oder Graphiken bedarf unserer schriftlichen Zustimmung.