Freigeben über

Richtlinien für sicheres Codieren

Die meisten Anwendungscode können einfach die Infrastruktur verwenden, die von .NET implementiert wird. In einigen Fällen ist zusätzliche anwendungsspezifische Sicherheit erforderlich, die entweder durch Erweitern des Sicherheitssystems oder mithilfe neuer Ad-hoc-Methoden erstellt wird.

Wenn Sie .NET erzwingende Berechtigungen und andere Durchsetzungsmaßnahmen in Ihrem Code verwenden, sollten Sie Barrieren errichten, um zu verhindern, dass bösartiger Code auf Informationen zugreift, die er nicht haben soll, oder andere unerwünschte Aktionen ausführt. Darüber hinaus müssen Sie ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit in allen erwarteten Szenarien mit vertrauenswürdigem Code treffen.

In dieser Übersicht werden die verschiedenen Möglichkeiten beschrieben, wie Code für die Arbeit mit dem Sicherheitssystem konzipiert werden kann.

Sichern des Ressourcenzugriffs

Beim Entwerfen und Schreiben von Code müssen Sie den Zugriff, den Der Code auf Ressourcen hat, schützen und einschränken, insbesondere beim Verwenden oder Aufrufen von Code unbekannter Herkunft. Denken Sie also an die folgenden Techniken, um sicherzustellen, dass Ihr Code sicher ist:

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

  • Verwenden Sie keinen teilweisen vertrauenswürdigen Code.

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

  • Verwenden Sie .NET Remoting nicht.

  • Verwenden Sie kein Verteiltes Komponentenobjektmodell (Distributed Component Object Model, DCOM).

  • Verwenden Sie keine Binärformatierer.

Codezugriffssicherheit und Security-Transparent Code werden nicht als Sicherheitsgrenze mit teilweise vertrauenswürdigem Code unterstützt. Wir raten davon ab, Code unbekannter Ursprünge zu laden und auszuführen, ohne alternative Sicherheitsmaßnahmen durchzuführen. Die alternativen Sicherheitsmaßnahmen sind:

  • Virtualisierung

  • AppContainers

  • Betriebssystembenutzer und -berechtigungen

  • Hyper-V-Container

Sicherheitsneutraler Code

Sicherheitsneutraler Code interagiert nicht direkt mit dem Sicherheitssystem. Er wird mit den jeweiligen Berechtigungen ausgeführt, die er erhält. Obwohl Anwendungen, die sicherheitsrelevante Ausnahmen nicht erfassen können, die mit geschützten Vorgängen (z. B. Dateien, Netzwerk usw.) verbunden sind, zu einer unbehandelten Ausnahme führen können, nutzt sicherheitsneutraler Code weiterhin die Sicherheitstechnologien in .NET.

Eine sicherheitsneutrale Bibliothek weist besondere Merkmale auf, die Sie verstehen 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. Selbst wenn der Code jedoch über die Berechtigung verfügt, muss jeder Anwendungscode, der ihn aufruft, über die gleiche 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 ist

Wenn Ihr Code Teil einer Anwendung ist, die nicht von einem anderen Code aufgerufen wird, ist sicherheit einfach und spezielle Codierung ist möglicherweise nicht erforderlich. Denken Sie jedoch daran, dass bösartiger Code Ihren Code aufrufen kann. Obwohl die Codezugriffssicherheit bösartigen Code möglicherweise daran hindern kann, auf Ressourcen zuzugreifen, könnte dieser Code dennoch Werte Ihrer Felder oder Eigenschaften lesen, die vertrauliche Informationen enthalten können.

Wenn Ihr Code außerdem Benutzereingaben aus dem Internet oder anderen unzuverlässigen Quellen akzeptiert, müssen Sie vorsichtig mit böswilligen Eingaben umgehen.

Implementierung von verwalteten Wrappern für nativen Code

In diesem Szenario werden einige nützliche Funktionen in systemeigenem Code implementiert, den Sie für verwalteten Code zur Verfügung stellen möchten. Verwaltete Wrapper können ganz einfach mithilfe von Platform Invoke oder COM-Interop geschrieben werden. 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. Unter der Standardrichtlinie bedeutet dies, dass code, der aus einem Intranet oder dem Internet heruntergeladen wurde, nicht mit den Wrappern funktioniert.

Anstatt allen Anwendungen, die diese Wrapper verwenden, nicht verwaltete Coderechte zu gewähren, empfiehlt es sich, diese Rechte nur dem Wrappercode zu erteilen. 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 beteiligt sind, sollte die Sicherheitscodierung mit dem im nächsten Abschnitt beschriebenen Bibliothekscodefall identisch sein. Da der Wrapper potenziell den Aufrufern Zugang zu diesen Ressourcen gewährt, ist eine sorgfältige Überprüfung der Sicherheit des nativen Codes erforderlich, und die Verantwortung dafür liegt beim Wrapper.

Bibliothekscode, der geschützte Ressourcen verfügbar macht

Der folgende Ansatz ist der leistungsstärkste und damit potenziell gefährlichste (falls falsch gemacht) für die Sicherheitscodierung: Ihre Bibliothek dient als Schnittstelle für anderen Code für den Zugriff auf bestimmte Ressourcen, die sonst nicht verfügbar sind, genauso wie die .NET-Klassen Berechtigungen für die verwendeten Ressourcen erzwingen. Unabhängig davon, wo Sie eine Ressource verfügbar machen, muss Ihr Code zuerst die entsprechende Berechtigung für die Ressource anfordern (d. h. sie muss eine Sicherheitsüberprüfung durchführen) und dann in der Regel seine Rechte zum Ausführen des tatsächlichen Vorgangs geltend machen.

Siehe auch