Ein wichtiger Punkt bei SharePoint-Installationen, die von außen (also über das Internet) zugreifbar sind, ist das Thema Sicherheit. Kaum etwas ist für Firmen ärgerlicher, als wenn der schöne neue Internetauftritt, der mit SharePoint erstellt wurde, Sicherheitslücken ausweist, die von Hackern ausgenutzt werden. Deswegen ist es gerade bei solchen Installationen sehr wichtig, alle Sicherheitslücken abzudichten.
Über eine dieser Lücken, die gern übersehen wird, möchte ich hier berichten.
Gehen wir einmal davon aus, unser neuer SharePoint-Internet Auftritt ist über die fiktive URL www.meinneuesportal.de aufrufbar. Wenn ein Besucher nun diese fiktive URL in die Adresszeile seines Browsers eingibt, wird sich diese URL im Browser in www.meinneuesportal.de/Pages/default.aspx verändern. Da wir nur die URL der Site eingegeben haben, greift SharePoint in die Liste Pages des Rootwebs und zeigt von dort die Seite default.aspx an. Zugegeben: das ist jetzt nicht wirklich neu.
Nun ändern wir diese URL manuell ein wenig ab: www.meinneuesportal.de/_layouts/settings.aspx. Wir ersetzen also Pages/default.aspx in _layouts/settings.aspx. Über diese URL kommt man normalerweise in die Site-Settings. Macht man dies bei unserem fiktiven Internet Auftritt, erscheint (hoffentlich) ein Login-Dialog. Dies ist zwar völlig richtig und auch verständlich, denn bevor SharePoint die Site-Settings anzeigt, wird (hoffentlich) eine Authentifizierung verlangt. Für Hacker aber ist so ein Login-Dialog eine sehr willkommene Möglichkeit, in ein System einzudringen. Aber selbst, wenn das Eindringen nicht sofort klappt, kann man mit Attacken auf einen Login-Prompt einen Server schnell in die Knie zwingen.
Abhilfe ist zwar möglich, aber nicht ganz einfach. Eine Lösungsmöglichkeit ist, einen HTTP-Handler zu schreiben, der diese Zugriffe z.B. auf die Homepage umleitet. Vereinfacht ausgedrückt fängt dieser HTTP-Handler Fehlermeldungen ab. In unserem Fall also z.B. die Fehlermeldung “Not Authorized”. Wenn man jetzt noch ein wenig zusätzliche Logik implementiert, kann unser HTTP-Handler erkennen, wenn die Site-Settings über …/_layouts/settings.aspx aufgerufen werden sollen und einen Redirect auf die Homepage ausführen oder eine eigene Fehlerseite anzeigen.
Beachten sollte man dabei aber: mit dieser Lösung sperrt man nicht nur böswillige Hacker aus, sondern auch die eignen Administratoren! Klar – auch autorisierte Zugriffe auf die Site-Settings werden vom HTTP-Handler umgeleitet. Im Normalfall ist das aber kein wirkliches Problem. In der datei web.config kann man den HTTP-Handler wieder (temporär) deaktivieren und dann kann ein Administrator auch wieder auf die Site-Settings zugreifen. Bei einer produktiven SharePoint-Installation sollte dies aber nicht häufig vorkommen – insofern ist diese Einschränkung verglichen mit dem Sicherheitsgewinn zu vertreten.
Da ein HTTP-Handler nicht so ganz einfach zu programmieren ist (man sollte –gerade in einer produktiven Umgebung- schon genau wissen, was man tut), habe ich hier noch ein paar Links mit Hinweisen zusammengetragen:
http://msdn.microsoft.com/en-us/library/bb457204.aspx
/helloitsliam/archive/2007/05/09/moss2007-quot-httphandler-quot-investigation.aspx
oliver wirkus