Welches Risiko birgt Reflection? (Mittleres Vertrauen)

8

Die fehlende Reflexion in Hosting-Umgebungen mit Medium Trust scheint eine Menge Probleme zu verursachen viele beliebte Web-Anwendungen.

  • Warum ist ReflectionPermission standardmäßig mit Medium Trust deaktiviert?
  • Welches Risiko birgt Reflektion in einer Shared Hosting-Umgebung?

Für eine zufällige Referenz finden Sie unter MSDN: Verwendung der Medienvertrauensstellung in ASP.NET 2.0

    
Gabe Sumner 21.07.2009, 18:34
quelle

3 Antworten

6

Reflection ermöglicht es bösartigem Code, alle Arten von Geheimnissen zu untersuchen: nicht so sehr geistiges Eigentum (obwohl sicher, das auch), sondern Daten, die privat und sicher sein sollten, wie Verbindungszeichenfolgen, Passwörter, Bankkontodaten usw ..

Natürlich stellen viele Programme diese Daten selbstverständlich durch noch kompromisslosere Vektoren zur Verfügung, aber es gibt keinen Grund, die Angriffsfläche einer Anwendung zu erhöhen.

Bearbeitet, um einen Teil der Konversation aus den Kommentaren zu holen:

Es ist wahrscheinlich richtig, dass das eigentliche Risiko der uneingeschränkte Zugriff auf das Dateisystem ist, was die Reflektion in eine echte Gefahr verwandelt. Wenn ein schlechter Akteur eine Assembly (oder etwas, das in eine Assembly kompiliert wird) in Ihr virtuelles Verzeichnis bringen kann, haben Sie Probleme, wenn sie eine Reflektionsberechtigung haben. (Natürlich, wenn das passiert, gibt es andere mögliche Probleme, aber das sollte diese besondere Schwachstelle nicht ausschließen.)

In einer Shared-Hosting-Umgebung ist das nur schwieriger zu verhindern, obwohl es sicherlich nicht unmöglich ist. Vielleicht lohnt es sich, diese Frage an ServerFault zu verschicken, um zu sehen, was die guten Leute dort zu sagen haben.

    
Jeff Sternal 21.07.2009, 18:48
quelle
4

Ich habe noch nie etwas "Schlechtes" gefunden, dass ein Benutzer mit Reflektion umgehen kann. Die Leute werden verängstigt, weil Sie Methoden aufrufen können, die als privat oder geschützt gekennzeichnet sind, aber von dem, was ich gesehen habe, stellt keines von ihnen ein echtes Risiko dar.

Wahrscheinlich ist es zumindest teilweise eine Verkaufstechnik, die Sie dazu bringt, sich für (halb-) dediziertes Hosting zu entscheiden:)

    
Thorarin 21.07.2009 18:39
quelle
3

Ich habe den folgenden MSDN-Artikel zu diesem Thema gefunden:

Sicherheitsaspekte für die Reflektion

Dieser Artikel enthält Jeffs Antwort:

  

Reflection bietet die Möglichkeit zu   Informationen über Typen und   Mitglieder und Zugriff auf Mitglieder.   Zugriff auf nicht öffentliche Mitglieder könnte   ein Sicherheitsrisiko schaffen. Deshalb,   Code, der auf nicht öffentliche Mitglieder zugreift   erfordert ReflectionPermission mit der   entsprechende Flags.

Ich glaube jedoch nicht, dass dieses Risiko zwischen den Hosting-Accounts der Kunden ausgenutzt werden kann. Es scheint, dass dies nur ein persönliches Risiko darstellen würde. Zum Beispiel könnte ich mithilfe von Reflektion meine eigenen Assemblies in meiner Hosting-Umgebung erkunden. Andere Kunden konnten die Reflektion jedoch nicht dazu verwenden, meine Assemblies zu untersuchen. Sie konnten nur ihre Assemblies erforschen

Dies kann ein Problem für eine einzelne Webanwendung darstellen, an der mehrere Entwicklungsteams beteiligt sind. Ein Entwicklungsteam könnte mithilfe von Reflektion die Baugruppen eines anderen Entwicklungsteams untersuchen.

Dies ist jedoch ein seltenes Szenario für eine Shared Hosting-Umgebung. Bei den meisten Shared Hosting-Websites handelt es sich um ein sehr kleines Team, das vollen Zugriff auf all den Code hat. Mit anderen Worten, es gibt keine Geheimnisse. Solange die Assembly von anderen Shared-Hosting-Kunden sicher ist, ist das kein Problem.

Die Aktivierung der Reflektion sollte für die meisten Shared-Hosting-Webanwendungen kein Risiko darstellen:

%Vor%

Bitte korrigieren Sie mich, wenn ich falsch liege.

    
Gabe Sumner 21.07.2009 20:07
quelle