Effektives Java-Objekt 76: Serialisierung und Sicherheit - Wie genau erhält der Hacker Verweise auf die internen Datumsfelder des unveränderlichen Periodenobjekts?

Question

Während ich den Gesamtpunkt verstehe, den dieser Gegenstand macht, bin ich daran interessiert zu verstehen, wie genau der Hacker die internen Referenzen des veränderbaren Period-Objekts bekommt. Er verdirbt die internen Datumsfelder durch diese Referenzen, so dass es wichtig ist zu verstehen, wie genau er diese Referenzen erhält. Ich habe das Beispiel und den Code gelesen und gelesen, konnte aber diesen subtilen Punkt nicht verstehen.

Bloch sagt:

Es ist möglich, eine veränderliche Periode Beispiel durch Herstellen eines Byte-Stream zu erstellen, die mit einem gültigen Zeitraum Instanz beginnt und dann anfügt zusätzliche Hinweise auf die privaten Datumsfelder im Inneren der Periode Instanz. Der Angreifer liest die Periode-Instanz aus dem ObjectInput- Stream und liest dann die "Rogue Objektreferenzen", die an den Stream angehängt wurden. Diese Referenzen geben dem Angreifer Zugriff auf die Objekte, auf die von den privaten Datumsfeldern innerhalb des Objekts Periode verwiesen wird. Durch die Änderung dieser Datumsinstanzen kann der Angreifer die Periodeninstanz ändern. Die folgende Klasse zeigt diesen Angriff:

public class MutablePeriod { 
    // A period instance 
    public final Period period; 

    // period's start field, to which we shouldn't have access 
    public final Date start; 

    // period's end field, to which we shouldn't have access 
    public final Date end; 

    public MutablePeriod() { 
    try { 
     ByteArrayOutputStream bos = 
     new ByteArrayOutputStream(); 
     ObjectOutputStream out = 
     new ObjectOutputStream(bos); 
     // Serialize a valid Period instance 
     out.writeObject(new Period(new Date(), new Date())); 

     /* 
     * Append rogue "previous object refs" for internal 
     * Date fields in Period. For details, see "Java 
     * Object Serialization Specification," Section 6.4. 
     */ 
     byte[] ref = { 0x71, 0, 0x7e, 0, 5 }; // Ref #5     
     bos.write(ref); // The start field 
     ref[4]=4; //Ref#4 
     bos.write(ref); // The end field 
     // Deserialize Period and "stolen" Date references 
     ObjectInputStream in = new ObjectInputStream(
     new ByteArrayInputStream(bos.toByteArray())); 
     period = (Period) in.readObject(); 
     start = (Date) in.readObject(); 
     end = (Date) in.readObject(); 
    } catch (Exception e) { 
     throw new AssertionError(e); 
    } 
    } 
} 

Was hier in diesem Teil ist hier los?

/* 
* Append rogue "previous object refs" for internal 
* Date fields in Period. For details, see "Java 
* Object Serialization Specification," Section 6.4. 
*/ 
byte[] ref = { 0x71, 0, 0x7e, 0, 5 }; // Ref #5     
bos.write(ref); // The start field 
ref[4]=4; //Ref#4 
bos.write(ref); // The end field 

Und wie hilft es dem Hacker, die Referenzen zu bekommen?

Und später im Code wie gibt start = (Date) in.readObject(); ihm interne Referenzen des Period-Objekts, das erstellt wird?

Answer 1

Der Hacker nutzt die Tatsache aus, dass er den Stream erstellt hat, also kennt er das Layout.

Insbesondere weiß der Hacker, dass das fünfte Objekt, das in den Stream geschrieben wird, das Date-Objekt ist, auf das mit Period.start verwiesen wird, und das vierte Objekt das DateDevice -Objekt ist, das von Period.end referenziert wird.

Java-Serialisierung, für eigene Zwecke, ermöglicht "Verweise" in einen Stream zu platzieren. Andernfalls wäre es unmöglich, zwei Objekte zu serialisieren, die auf dasselbe Objekt zeigen.

Durch Einfügen dieser "Referenzen" in den Stream (Verweise auf das 4. und 5. Objekt) erhält der Hacker Zugriff auf die Instanzen des Datums, die von der Periode gehalten werden.

Ich bin mir nicht sicher, wie Hacker diese Instanzen mutieren würden.