Richtlinien für das Schreiben von sicherem Code

  • Artikel

Der Großteil des Anwendungscodes kann einfach die von .NET implementierte Infrastruktur verwenden. In einigen Fällen ist eine zusätzliche anwendungsspezifische Sicherheit erforderlich, die entweder durch Erweitern des Sicherheitssystems oder mithilfe neuer Ad-hoc-Methoden erstellt wird.

Mithilfe der mit .NET erzwungenen Berechtigungen und den sonstigen Durchsetzungen im Code sollten Sie Barrieren errichten, um zu verhindern, dass schädlicher Code auf vertrauliche Informationen zugreift oder andere unerwünschte Aktionen ausführt. Darüber hinaus müssen Sie mithilfe von vertrauenswürdigem Code ein Gleichgewicht zwischen Sicherheit und Nutzbarkeit herstellen.

In dieser Übersicht werden die verschiedenen Methoden zum Entwerfen von Code beschrieben, damit dieser mit dem Sicherheitssystem funktioniert.

Schützen des Ressourcenzugriffs

Beim Entwerfen und Schreiben von Code müssen Sie den Zugriff, den Code auf Ressourcen hat, schützen und einschränken. Dies gilt insbesondere, wenn Code mit unbekannter Herkunft verwendet oder aufgerufen wird. Daher sollten Sie die folgenden Aspekte beachten, um sicherzustellen, dass Ihr Code sicher ist:

  • Verwenden Sie nicht die Codezugriffssicherheit (Code Access Security, CAS).

  • Verwenden Sie keinen teilweise vertrauenswürdigen Code.

  • Verwenden Sie nicht das AllowPartiallyTrustedCaller-Attribut (APTCA).

  • Verwenden Sie nicht .NET-Remoting.

  • Verwenden Sie nicht DCOM (Distributed Component Object Model).

  • Verwenden Sie keine binären Formatierungsprogramme.

Codezugriffssicherheit und sicherheitstransparenter Code werden bei teilweise vertrauenswürdigem Code nicht als Sicherheitsgrenze unterstützt. Wir raten davon ab, Code unbekannter Herkunft zu laden und auszuführen, ohne alternative Sicherheitsmaßnahmen zu treffen. Die alternativen Sicherheitsmaßnahmen sind:

  • Virtualisierung

  • AppContainer

  • Betriebssystembenutzer und -berechtigungen

  • Hyper-V-Container

Sicherheitsneutraler Code

Sicherheitsneutraler Code wirkt sich nicht explizit auf das Sicherheitssystem aus. Er wird mit den jeweiligen Berechtigungen ausgeführt, die er erhält. Anwendungen, die keine Sicherheitsausnahmen abfangen können, die geschützten Operationen zugeordnet sind (z. B. die Verwendung von Dateien oder Netzwerkfunktionen), können zu einem Ausnahmefehler führen. Dennoch nutzt der sicherheitsneutrale Code die Sicherheitstechnologien in .NET.

Eine sicherheitsneutrale Bibliothek weist besondere Merkmale auf, die Sie kennen sollten. Angenommen, Ihre Bibliothek stellt API-Elemente bereit, die Dateien verwenden oder nicht verwalteten Code aufrufen. Wenn Ihr Code nicht über die entsprechende Berechtigung verfügt, wird er nicht wie beschrieben ausgeführt. Auch wenn der Code über die Berechtigung verfügt, muss jeder ihn aufrufende Anwendungscode über dieselbe Berechtigung verfügen, damit er funktioniert. Wenn der aufrufende Code nicht über die richtige Berechtigung verfügt, wird als Ergebnis des Stackwalk der Codezugriffssicherheit eine SecurityException angezeigt.

Anwendungscode, der keine wiederverwendbare Komponente darstellt

Wenn Ihr Code Teil einer Anwendung ist, die nicht von anderem Code aufgerufen wird, ist die Sicherheit einfach zu erreichen, und möglicherweise ist keine spezielle Programmierung erforderlich. Beachten Sie jedoch, dass Ihr Code von schädlichem Code aufgerufen werden kann. Obwohl die Codezugriffssicherheit möglicherweise den Zugriff auf Ressourcen durch schädlichen Code beenden kann, könnte dieser Code weiterhin Werte Ihrer Felder oder Eigenschaften lesen, die möglicherweise vertrauliche Informationen enthalten.

Darüber hinaus müssen Sie hinsichtlich schädlicher Eingaben vorsichtig sein, wenn Ihr Code Benutzereingaben aus dem Internet oder anderen unzuverlässigen Quellen akzeptiert.

Implementierung von verwalteten Wrappern für nativen Code

In diesem Szenario werden in der Regel einige nützliche Funktionen in systemeigenem Code implementiert, die Sie für verwalteten Code verfügbar machen können. Verwaltete Wrapper sind mithilfe von Plattformaufrufen oder COM-Interops einfach zu schreiben. Wenn Sie auf diese Weise vorgehen, müssen die Aufrufer der Wrapper über Berechtigungen für nicht verwalteten Code verfügen, um erfolgreich agieren zu können. Entsprechend der Standardrichtlinie bedeutet dies, dass der aus einem Intranet oder dem Internet heruntergeladene Code mit den Wrappern nicht funktioniert.

Statt allen Anwendungen, die diese Wrapper verwenden, die Berechtigungen für nicht verwalteten Code zu gewähren, ist es besser, diese Berechtigungen nur dem Wrappercode zuzuordnen. Wenn die zugrunde liegenden Funktionen keine Ressourcen verfügbar machen und die Implementierung entsprechend sicher ist, muss der Wrapper nur seine Rechte bestätigen, wodurch Aufrufe von beliebigem Code über den Wrapper ermöglicht werden. Wenn Ressourcen einbezogen sind, sollte die Codierung der Sicherheit mit der im Bibliothekscodefall verwendeten Codierung identisch sein, der im nächsten Abschnitt beschrieben wird. Da der Wrapper Aufrufer dieser Ressourcen potenziell verfügbar macht, ist eine sorgfältige Überprüfung der Sicherheit des systemeigenen Codes erforderlich, für die der Wrapper zuständig ist.

Bibliothekscode zur Offenlegung geschützter Ressourcen

Der folgende Ansatz ist der leistungsstärkste und daher (bei falscher Durchführung) für die Sicherheitsprogrammierung möglicherweise gefährlich: Ihre Bibliothek fungiert hier für anderen Code als Schnittstelle für den Zugriff auf bestimmte Ressourcen, die anderweitig nicht verfügbar sind, ebenso wie die .NET-Klassen die Berechtigungen für die von ihnen verwendeten Ressourcen erzwingen. Überall dort, wo Sie eine Ressource verfügbar machen, muss der Code zunächst die für die Ressource geeignete Berechtigung anfordern (d. h. er muss eine Sicherheitsüberprüfung durchführen) und seine Rechte dann in der Regel bestätigen, um den eigentlichen Vorgang ausführen zu können.

Siehe auch