2015-01-04 6 views
6

So wie der Titel sagt: Was, wenn überhaupt, sind die Sicherheitsimplikationen, die berücksichtigt werden müssen, wenn anonyme Methoden (Action<>, Func<>) in C# verwendet und/oder weitergegeben werden?Was sind die Sicherheitsaspekte für die Annahme anonymer Methoden (Action <>, Func <>) als Parameter?

Eine Methode, die Action<>/Func<> akzeptiert, scheint ein möglicher Weg für die Einspeisung von Fremdcode in ein Programm zu sein. Für die Aufzeichnung verstehe ich, dass die injizierte Methode oder Funktion nicht in der Lage ist, von Natur aus unsichere Dinge im Sinne eines willkürlichen Speicherzugriffs zu tun, aber ich würde denken, dass es dem aufrufenden Code erlauben könnte, z. willkürliche .Net-Framework-Funktionen, korrupte Daten oder auf andere Weise verursachen die Anwendung Fehlverhalten.

Ist diese Annahme falsch?

Wenn nicht, was sollte getan werden, um diese zu sperren? Gibt es außerdem eine Möglichkeit, das /Func<> zu validieren, das in einer Methode oder Funktion übergeben wird, um sicherzustellen, dass es eine erwartete Form aufweist oder seinen Zugriff auf bestimmte Typen und Namespaces einschränkt?

Verzeih mir auch, wenn ich nicht die richtige Terminologie verwende, lerne ich immer noch.

+0

Beachten Sie auch, dass Sie bösartigen Code durch Vererbung (durch Überschreiben virtueller und abstrakter Methoden) und Schnittstellenimplementierung injizieren können. Aber die Antwort von SLaks gilt auch für diese Fälle. Die Klasse "System.String" zum Beispiel schützt sich davor, indem sie versiegelt wird. –

+0

Was ist das Szenario?Vertrauenswürdiger und nicht vertrauenswürdiger Code im selben Prozess, getrennt durch CAS? – usr

+0

@usr Ich frage wirklich, ob es * Szenarien gibt, in denen es irgendwelche Bedenken gibt. Ich habe hier einige Lösungen gesehen, die diese verwenden, um zum Beispiel einen Eigenschaften-Getter oder -Setter an eine benannte Methode zu übergeben, indem man sie in eine dieser Methoden einpackt. Aber das fühlt sich falsch an, denn meines Wissens gibt es keine Möglichkeit, dass die benannte Methode garantiert oder anderweitig dafür sorgt, dass sich die übergebene Aktion <> oder Func <> in erwarteter Weise verhält. Ist es dann eine schlechte Übung, diese als Parameter zu verwenden, es sei denn, die benannte Methode kümmert sich wirklich nicht darum, was sie tut? Z.B. Assert.ThrowsException (). –

Antwort

9

Verfahren, die Aktion <>/Func < akzeptiert> scheint für ausländischen Code ein potenzieller Weg, um in ein

Das ist völlig falsch Programm injiziert werden. Wer seine Funktion aufruft und einen Delegierten übergibt, führt per Definition bereits Code in Ihrem Programm aus.
Jeder Code, der einen Delegaten übergibt, kann bereits tun, was er will. Sie können Sicherheitsgrenzen innerhalb derselben Anwendungsdomäne nicht haben. (Ältere Versionen von .Net hatten Codezugriffssicherheit, die das versuchte, aber keine gute Idee war)

Es kann jedoch unerwartete Reentrancies erstellen, die Probleme mit Thread-sicherem Code verursachen können.

+0

Ich denke ich verstehe. Sie sagen, dass alles, was ausgeführt werden könnte, den Code selbst aufrufen könnte und dass der mutmaßliche bösartige Code nichts damit zu tun hat? Nehmen wir an, dass es einen absichtlich verursachten Wiedereintritt gibt. Wäre das mit Sicherheitsrisiken behaftet oder würde es das Programm einfach destabilisieren? Wenn ich eine Endlosschleife durchlaufe, könnte das ein Problem sein, das ich mir vorstellen kann. Wenn ja, gibt es Gestaltungsempfehlungen zur Risikominimierung? Wie werden diese sparsam, intern und wenn öffentlich, gründlich auf Wiedereintritt und Instabilität getestet? –

+0

@NickBauer: Auch wenn Sie eine tatsächliche Sicherheitsgrenze haben, gibt es keine Sicherheit zu sprechen. Siehe http://blogs.msdn.com/b/oldnewthing/archive/2014/05/05/29/10529251.aspx und http://blogs.msdn.com/b/oldnewthing/archive/2007/08/07/4268706 .aspx # 4282521 – SLaks

+0

Okay, ich bin bei dir. Aber ich bin immer noch neugierig darauf, was du mit dem Wiedereintritt meinst, da du es erwähnt hast. EDIT: Das ist nicht, dass Wiedereintritt ein Problem ist, aber wenn ein Fenster für den Wiedereintritt auf diese Weise erlaubt, könnte ein Problem sein. –

2

Ich bitte wirklich, wenn es sind Szenarien

zurück, wenn CAS-Richtlinie noch verwendet wurde (zB Medium Vertrauen ASP.NET) ein vertrauenswürdiges Stück Code nicht sicher nicht vertrauenswürdigen Code nennen könnte wenn der Stapel behauptet, sind vorhanden. Zum Beispiel wenn

war in der Tat die Sicherheitsprüfung Stack Walk würde an dieser Stelle stoppen. Dies kann dazu führen, dass nicht vertrauenswürdiger Code nicht erkannt wird. See the docs for Assert.

Ich bin ein wenig vage hier, weil das Szenario schwer zu durchziehen ist und es veraltet ist.

Falls innerhalb desselben Prozesses keine Vertrauensgrenze vorhanden ist, hat der Anrufer bereits die volle Leistung, auch ohne irgendwo Code einzugeben. Keinen Bedarf.

Verwandte Themen