Vulnerabilità dei parametri del tipo di classe Java

Question

Vulnerabilità dei parametri del tipo di classe Java

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

1

In un libro di programmazione Java c'è una sezione che descrive la JVM e gli indirizzi di memoria e la posizione in cui si riferiscono ai parametri di un tipo di classe. Come puoi vedere dall'output della console, l'oggetto iniziale viene sovrascritto in memoria (potenzialmente involontariamente all'autore dell'API). Mi è stato spiegato che questa può essere una vulnerabilità di sicurezza del software non prevista e che sarebbe stata rilevata durante una revisione manuale del codice.

Qualcuno può spiegare in che modo questa vulnerabilità sarebbe sfruttata? Sarebbe nell'utilizzo dell'API di qualcun altro che contiene questa vulnerabilità o sarebbe nello sfruttamento di un'applicazione reale che contiene questo? Ci sono degli esempi (forse nelle notizie) di questo fatto?

Ecco come funziona, secondo il testo:

MainActivity.class:

public class MainActivity {

public static void main(String[] args) {
        ToyClass anObject = new ToyClass("Mr. Cellophane", 0);
        System.out.println(anObject);
        System.out.println("Now we call changer with anObject as an argument");
        ToyClass.changer(anObject);
        System.out.println(anObject);
    }
}

ToyClass

public class ToyClass {
    private String name;
    private int number;

    public ToyClass(String initialName, int initialNumber) {
        name = initialName;
        number = initialNumber;
    }

    public ToyClass() {
        name = "No name yet.";
        number = 0;
    }
    public void set(String newName, int newNumber) {
        name = newName;
        number = newNumber;
    }
    public String toString() {
        return (name +" " + number);
    }
    public static void changer(ToyClass aParameter) {
        aParameter.name = "Hot Shot";
        aParameter.number = 42;
    }
    public boolean equals(ToyClass otherObject) {
        return ((name.equals(otherObject.name)&& (number == otherObject.number) ));
    }
}

Output console:

Mr. Cellophane 0
Now we call changer with anObject as an argument
Hot Shot 42

Modifica: per spiegare un po 'di più lo sfondo. Questo esempio mostra come nel sistema di memoria JVM due oggetti si trovano su un indirizzo diverso mentre il parametro memorizzato si trova nella stessa posizione di memoria e viene sovrascritto dal secondo metodo. Questa è la base della "vulnerabilità".

java exploit

posta KDEx 21.09.2012 - 21:06

fonte

3 risposte

2

Non penso che il codice che hai postato possa essere sfruttato in modo specifico come vulnerabilità. Quello che hai postato è una pratica di programmazione ragionevole. Quel metodo "changer (ToyClass)" riassegna il valore del parametro. Puoi farlo praticamente da qualsiasi luogo, come il seguente:

public class WhateverClass {

public static void changer(ToyClass aParameter) {
      aParameter.name = "Anything";
      aParameter.number = 99;
}
}

E quindi chiama

WhateverClass.changer(anObject);

farà la stessa cosa del tuo codice, anche se è necessario cambiare l'ambito di nome e numero per il pacchetto e non privato. Ma essenzialmente, a quanto vedo, stai semplicemente cambiando la variabile da una classe specifica. Solo così accade che il metodo si trova all'interno dell'oggetto in questione ed è statico.

Non vedo come qualcuno lo sfrutti. Sarebbe bello avere qualcuno che conosca gli interni VM per commentare.

risposta data 22.09.2012 - 11:07

fonte

1

Questa non è una vulnerabilità in Java. Ecco come è progettato Java per funzionare.

In alcuni casi potrebbe essere una vulnerabilità in ToyClass, se l'autore di questo codice non si rendesse conto che stava fornendo la possibilità di cambiare istanze - ma in questo caso, il programmatore probabilmente non conosce Java e non dovrebbe scrivere codice di sicurezza in Java.

Naturalmente, se il programmatore non capisce il linguaggio di programmazione in cui sta programmando, si può sicuramente finire con le vulnerabilità orribili, ma questo è vero per ogni lingua. Se vuoi creare un codice sicuro, devi iniziare comprendendo i tuoi strumenti!

Bottom line: questo è un aspetto piuttosto basilare di Java. Qui non vedo nulla di sorprendente o particolarmente pericoloso per la sicurezza.

risposta data 23.09.2012 - 02:34

fonte

Leggi altre domande sui tag java exploit

Quanto è affidabile / sicuro QCaptcha? Applicazione della rete bayesiana per la sicurezza delle applicazioni Web

score 3 · Accepted Answer

Ciò che questo esempio mostra è che le istanze di classe in Java sono mutable : il contenuto di un'istanza può cambiare durante la vita dell'istanza. Questo può sorprendere per le persone che hanno fatto troppo Haskell , ma è altrimenti una caratteristica basilare di Java, che è condivisa da molti linguaggi di programmazione, inclusi C, C ++, Javascript, C #, Forth, Pascal ...

Le istanze immutabili sono convenienti per la programmazione, in particolare quando diversi sviluppatori devono collaborare. In Java, la classe String è l'esempio canonico di istanze immutabili: ogni istanza String rappresenta una determinata stringa che non può essere modificata (*). Quando vuoi modificare una stringa, chiami un metodo come substring() che non realmente modifica la stringa; al contrario, crea e restituisce una nuova istanza String , lasciando intatta la stringa originale. Quando hai istanze immutabili, puoi tenerle e condividerle con meno precauzioni.

Ad esempio, supponiamo di avere una classe che rappresenta un utente autenticato:

public class AuthenticatedUser {

    private String name;

    public String getName()
    {
        return name;
    }
}

Tale istanza mantiene il nome dell'utente autenticato in un campo interno. Il metodo getName() restituisce quel nome - può restituire la stessa istanza che mantiene internamente, perché% istanze diString sono immutabili: il chiamante non sarà in grado di modificarlo comunque. Quindi non c'è bisogno di creare una copia, il pubblico getName() può dare subito la stringa vera.

Le istanze mutevoli, al contrario, richiedono più attenzione e, spesso, molta copia. Non riuscendo a farlo possono insorgere bug sottili e le vulnerabilità della sicurezza non sono nient'altro che bug che sono giunti all'attenzione di un individuo malintenzionato.

Java è un linguaggio che ha alcune funzioni utili per creare oggetti immutabili: - I suoi tipi forti vietano operazioni che non seguono i sistemi di tipi (al contrario di, per esempio, C, dove tutto è solo un mucchio di byte e può essere consultato come tale). - Metodi e campi possono essere taggati con una visibilità come private sopra. - Java include un garbage collector che è il complemento necessario per la condivisione di istanze immutabili attraverso chiamate di metodi (senza memoria automatica gestione, tale condivisione deve includere regole per chi è responsabile del rilascio della memoria, e raramente funziona bene).

Quindi il punto che stai descrivendo è not una "vulnerabilità Java". Piuttosto, è una fonte comune di bug (alcuni dei quali sono vulnerabilità) che possono essere evitati grazie agli strumenti forniti da Java. Sarebbe più appropriato chiamarlo "vulnerabilità C, con cui non si ha bisogno di convivere se si sviluppa in Java".

^{(*) Non è del tutto vero: le istanze di stringa possono essere modificate attraverso la reflection, anche se non in modo affidabile e in un modo standard. L'accesso riflessivo ai campi privati è un permesso speciale che l'applet Java non firmata non ha, quindi non preoccuparti di questo.}