Dateizugriff auf Netzlaufwerken

Geschrieben von: Christoph Wille
Kategorie: Sicherheit

Ein beliebtes Sorgenkind unter ASP Programmierern ist der Zugriff auf Dateien, die sich auf Netzlaufwerken (Shares) befinden. Der Grund der Probleme ist die NT Sicherheit, und heute werde ich Ansätze vorstellen, um den Zugriff auf Netzlaufwerke (a) zu ermöglichen, und (b) möglichst sicher zu bewerkstelligen.

Beginnen wir mit einem Sourcecode, wie ihn sich klein Hansi vorstellen würde (fileshare.asp):

<% @Language="VBSCRIPT" %>
<% Option Explicit %>
<%
Dim fs, fldr, subfldrs, strFolder, strResult

strFolder = "\\Server\Share" ' WICHTIG: Serverpfad hier anpassen!

Set fs = Server.CreateObject("Scripting.FileSystemObject")
Set fldr = fs.GetFolder(strFolder)
Set subfldrs = fldr.SubFolders

For Each fldr In subfldrs
  strResult = strResult & fldr.Name
  strResult = strResult & vbCrLf
Next

Response.Write "<pre>" & strResult & "</pre>" 
%>

Läßt man diesen Sourcecode jetzt laufen - der für ein lokales Verzeichnis perfekt funktioniert - so erlebt man folgende Fehlermeldung:

Microsoft VBScript runtime error '800a004c' 
Path not found 
/aspheute/filemgmt/fileshare.asp, line 9 

Nun, das kann's ja wohl nicht sein, vor allem dann, wenn man im Explorer dieses Share gerade offen hat. Woran krankt die Sache also?

Die Sache ist die - standardmäßig wird der IIS mit einem Anonymzugriffskonto namens IUSR_machinename ausgestattet. Jeder anonyme Zugriff auf die Website wird über diesen Account tatsächlich ausgeführt - weil unter NT ohne Account nichts geht, und zwar absolut nichts - und irgendwie muß ja auf die ASP Dateien auf der Festplatte zugegriffen werden. Der Hasenfuß an der Sache ist, daß das IUSR Konto nur lokal auf der Webservermaschine angelegt wird, und am Server, auf dem das Share liegt, nicht bekannt ist - und da man ohne Account niemand ist, ist man angeschmiert.

Um das Problem mit dem Konto zu umgehen gibt es zwei Lösungen:

• Man legt ein neues Konto für den anonymen Zugriff an, und zwar auf dem Webserver und dem Fileserver, und stattet beide mit dem gleichen Passwort aus. Dann ändert man das anonyme Konto für den Webserver in der ISM, und voila - es funktioniert (vorausgesetzt, das neue Konto erhält am Share die entsprechenden Rechte).
• Variante zwei funktioniert dann, wenn Webserver und Fileserver in einer gemeinsamen Domain zu Hause sind - dann legt man einen Domain Account an, und gibt diesem am Fileserver Zugriff, und verwendet ihn ebenso als anonymes Konto für den IIS.

Das sind doch zwei hervorragende Lösungen, warum also zeigt der Scrollbar, daß der Artikel noch um einiges länger ist? Nun, ich bin mit dieser Lösung nicht sehr glücklich. Warum?

Das Problem liegt darin, daß ich durch Änderung des Anonymkontos die Rechte der gesamten Website verändere, und nicht nur dort, wo ich die zusätzlichen Rechte brauche (also pro Verzeichnis würde ich das nicht empfehlen...). Dadurch eröffne ich potentielle Sicherheitslücken auf meinem Server, weil der anonyme Account plötzlich Rechte im gesamten Netzwerk hat. Wird dieser kompromitiert kann man in teuflische Probleme kommen.

Nun gut - ich fordere also, daß man die Rechte für Netzwerklaufwerke nur so lange hält, wie man sie braucht. Nur - wie bewerkstellige ich das? Wer einen Background in C++ Programmierung für WIN32 hat, weiß worauf ich hinaus will: es gibt API's, mit denen ich Benutzer impersonieren kann - also für eine gewisse Zeit als jemand anderer gegenüber dem Betriebssystem auftreten kann.

Zwar könnte ich eine solche Komponente selbst schreiben, nur bin ich dafür zu bequem, vor allem dann, wenn es eine leistungsfähige Komponente bereits gibt, die netterweise vollständig gratis ist: SA-FileManager. Diese ist - salopp formuliert - eine deutlich leistungsfähigere Variante als das FileSystemObject - und noch dazu funktioniert sie über weite Strecken vollständig gleich (safileshare.asp):

<% @Language="VBSCRIPT" %>
<% Option Explicit %>
<%
Dim oFM, oFolder, oFiles, oFile, strFolder, strResult

strFolder = "\\Server\Share" ' WICHTIG: Serverpfad hier anpassen!

Set oFM = Server.CreateObject("SoftArtisans.FileManager")
Set oFolder = oFM.GetFolder(strFolder)

Set oFiles = oFolder.Files
For Each oFile In oFiles
  strResult = strResult & oFile.Name
  strResult = strResult & vbCrLf
Next

Response.Write "<pre>" & strResult & "</pre>" 
%>

Ein wichtiger Unterschied wird beim Ausführen des Skriptes sofort ersichtlich - die Fehlermeldung ist deutlich leichter einsichtig:

FileMgr.Folder.1 error '80020009' 
Access is denied. 
/aspheute/filemgmt/safileshare.asp, line 9 

Hier könnten wir nun wie oben beschrieben mit neuen Anonymkontos das Gleiche bewerkstelligen wie für das FileSystemObject. Nur das wollen wir ja nicht! Deshalb bedienen wir uns der Methoden LogonUser und RevertToSelf. Erstere impersoniert einen anderen Account für uns, letztere läßt uns wieder auf den Ursprungsaccount "zurückfallen" (safileshare-logon.asp):

<% @Language="VBSCRIPT" %>
<% Option Explicit %>
<!--#include file="vbFileManagerInclude.asp"-->
<%
Dim oFM, oFolder, oFolders, oSubFolder, strFolder, strResult
strFolder = "\\Server\Share" ' WICHTIG: Serverpfad hier anpassen!

Set oFM = Server.CreateObject("SoftArtisans.FileManager")

oFM.LogonUser "domain", "account", "password", saLogonBatch

Set oFolder = oFM.GetFolder(strFolder) 

Set oFolders = oFolder.SubFolders
For Each oSubFolder In oFolders
  strResult = strResult & oSubFolder.Name
  strResult = strResult & vbCrLf
Next

Set oFolders = Nothing
Set oFolder = Nothing

oFM.RevertToSelf

Response.Write "<pre>" & strResult & "</pre>" 
%>

Nur zwischen den Zeilen mit LogonUser und RevertToSelf läuft unser Script mit einem Account, der auf das Netzwerklaufwerk zugreifen kann - der Rest der Ausführung ist das bekannte anonyme Konto IUSR_machinename.

Damit haben wir den Zweck erreicht - nur dort, wo wir mehr Benutzerrechte brauchen, verwenden wir diese auch. Einen weiteren Vorteil hat es ebenso - irrtümliche Änderungen an den Einstellungen des IIS für Anonymzugriff oder NTFS Rechte berühren die Funktionsfähigkeit dieses Scripts kaum mehr - wir haben unseren eigenen Account. Und unsere Wünsche nach Zugriff auf Netzlaufwerke berühren die Sicherheitseinstellungen anderer Skripts auch nicht mehr - egal, auf wieviele Netzlaufwerke wir zugreifen wollen. Und: wir können den Benutzer unserer Scripts den gewünschten Benutzernamen und Passwort eintippen lassen.

Ein Sicherheitsproblem hat das vorgestellte Script, das ich nicht verschweigen möchte: der verwendete NT Account steht im Plaintext in der ASP Datei, inklusive Passwort. Es versteht sich daher, die ASP Dateien vor Sourcecodezugriff zu sichern, und als Account immer einen zu verwenden, der so wenig Rechte als nur irgend möglich besitzt. Dieses Problem ergibt sich nicht, wenn man den Benutzer zur Laufzeit nach diesen Informationen fragt.

Schlußbemerkung

Die Methoden LogonUser und ReverToSelf beziehen sich auf das gesamte Script, nicht nur auf die FileManager Komponente - das heißt, man kann mit dieser Funktionalität auch andere Tasks unter bestimmten Accounts ausführen lassen, ohne das Anonymkonto des IIS verändern zu müssen.

Download des Codes

Klicken Sie hier, um den Download zu starten.

Verwandte Artikel

Lesen von Textdateien
NT Account Management via ASP
Schreiben einer Textdatei auf den Server
Schritt-für-Schritt Debuggen von Sicherheitsproblemen
Verzeichnissicherheit mit NTFS und IIS Authentifizierung

Links zu anderen Sites

SA FileManager

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.