Schutz von Feldern vor Reflektion - Der seltsame Fall von System.security

8

Ich untersuche derzeit Java-Sicherheit und bin auf ein seltsames Phänomen gestoßen. Der SecurityManager in Java wird im Feld "Sicherheit" in java.lang.System gespeichert. Interessanterweise scheint das Feld vor reflektivem Zugriff geschützt zu sein, was zwar sinnvoll ist, aber meines Wissens ist dieses Feld das einzige, was es gibt. Also hier ist das Beispiel:

%Vor%

Ausgaben

%Vor%

Interessanterweise: Das Feld wurde als

deklariert %Vor%

ist nicht in der Liste und sicher genug ein Anruf nach

%Vor%

ergibt eine NoSuchFieldException. Da ich online nichts darüber finden konnte, bin ich mir ziemlich sicher, dass dieses Feld durch Reflektion zugänglich war (siehe auch zum Beispiel http://sightlyrandombroknenthoughts.blogspot.de/2010/02) /java-se-security-part-iii-keys.html">blog post von 2010, die den Zugriff auf dieses Feld beschreibt) Ich frage mich, a) wurde dies als eine schnelle Lösung implementiert, um zu verhindern, dass der Sicherheitsmanager leicht durch Reflektion deaktiviert wird und b) wie dies umgesetzt wird (oder gibt es eine Chance, andere private Bereiche vor Reflektion zu schützen).

    
Arno Mittelbach 22.07.2013, 20:30
quelle

2 Antworten

3

Ein Kollege hat darauf hingewiesen, dass die Antwort nicht im jvm, sondern im jdk, genauer in der Klasse sun.reflect.Reflection, liegt. Dort finden Sie einen statischen Initialisierer, der Folgendes ausführt:

%Vor%

Wenn wir uns nun die Methode getDeclaredFields in java.lang.Class etwas genauer ansehen, werden wir feststellen, dass die Felder durch einen Aufruf der Reflection-Klasse gefiltert werden:

%Vor%

wo FilterFields als

implementiert ist %Vor%

Also ... das löst das Problem, wie das Feld geschützt ist. Ich bin jedoch immer noch neugierig, warum dies umgesetzt wurde.

    
Arno Mittelbach 23.07.2013, 08:54
quelle
-1

Erstens war die Art, wie dies verhindert wurde, wahrscheinlich eine schmutzige if in der JVM unter dem Feld-Getting-Mechanismus:

%Vor%

(Ich meine NICHT, dass dies der tatsächliche Code in der JVM ist !!)

Dies ist offensichtlich für die meisten Benutzer von Java nicht zugänglich, so dass die einzige andere Option darin besteht, einen Sicherheitsmanager zu installieren, der den Zugriff auf private Felder und Methoden verbietet. Dies ist möglich, aber ich bin mir nicht sicher, wie.

    
tbodt 22.07.2013 20:35
quelle

Tags und Links