Home » Sicurezza Wordpress » Deserializzazione e metodi JSON

Deserializzazione e metodi JSON

WordPress offre agli sviluppatori le funzioni maybe_serialize() e maybe_unserialize(), che sono semplicemente wrapper delle funzioni PHP serialize()unserialize() con un controllo aggiuntivo per i dati serializzati prima che avvenga il processo di serializzazione o deserializzazione.

Poiché WordPress non fornisce alcuna guida sulla sicurezza relativa all’utilizzo di queste funzioni, è comune vedere sviluppatori che devono lavorare con dati serializzati utilizzare queste o le rispettive funzioni PHP invece di funzioni PHP alternative e sicure come json_encode()json_decode().

La deserializzazione di input utente non attendibili potrebbe causare l’iniezione di oggetti PHP.

Se esiste una POP chain, lo sfruttamento di questa vulnerabilità potrebbe avere gravi conseguenze.

Opzione allowed_classes non serializzata

PHP unserialize() ha un’opzione per le classi consentite.

Gli sviluppatori a conoscenza delle vulnerabilità di PHP Object Injection spesso impostano questa opzione allowed_classes a false per impedire l’istanziazione di oggetti.

Tuttavia, questa opzione non sempre mitiga il problema di PHP Object Injection.

Se un payload serializzato viene passato a unserialize() con l’opzione array(‘allowed_classes' => false), l’oggetto risultante sarà un’istanza di __PHP_Incomplete_Class, che è un oggetto segnaposto.

Questo oggetto contiene i valori delle proprietà dannose originali, ma non è deserializzato.

Se questa istanza di __PHP_Incomplete_Class viene passata a una funzione che serializza i dati (come la funzione di WordPress update_option(), che usa maybe_serialize()), __PHP_Incomplete_Class verrà nuovamente serializzata, generando di fatto il payload originale e, in nel caso di update_option(), il payload serializzato verrà memorizzato nel database.

Se tale valore viene successivamente deserializzato, si verifica un’iniezione di oggetti PHP.

Flusso di deserializzazione

User Input (malicious serialized payload)
    │
    ▼
Stored in database (options, post meta, user meta, etc.)
    │
    ▼
Retrieved from database
    │
    ▼
maybe_unserialize()
    │
    ▼
unserialize()
    │
    ├── With allowed_classes => false
    │       │
    │       ▼
    │   __PHP_Incomplete_Class object created
    │       │
    │       ▼
    │   Stored again (e.g., via update_option())
    │       │
    │       ▼
    │   Retrieved and unserialized (without allowed_classes)
    │       │
    │       ▼
    │   🚨 POP Chain executes → Remote Code Execution (or other impact)
    │
    └── Without allowed_classes
            │
            ▼
        POP Chain executes:
        ├── __destruct()
        ├── __wakeup()
        ├── __call()
        ▼
        🚨 Remote Code Execution (or other impact)

Trovare vulnerabilità di iniezione di oggetti PHP

Le funzioni unserialize()maybe_unserialize() sono dei sink.

Cercare queste funzioni e seguire il flusso di dati a ritroso fino a una potenziale fonte è il modo migliore per trovare queste vulnerabilità nel codice di plugin e temi.


Traduzione in italiano della WordPress Security Research di Wordfence

WordPress Security Architecture

Lascia un commento