Informazioni su OWASP 2017 A8 Deserializzazione non sicura

0

Sto leggendo su Insecure Deserialization e ho ricordato una vulnerabilità di cui ho letto in alcune implementazioni JSON Web Token (JWT) su auth0.

link

link

Per farla breve, viene utilizzato l'algoritmo "nessuno", la firma viene rimossa e l'applicazione ritiene che tutto ciò che l'utente invia sia OK. Questo sarebbe sotto Insecure Deserialization o Using Components with Known Vulnerabilities ? L'esempio dato potrebbe ovviamente essere Broken Access Control , ma dato che l'utente controlla l'oggetto potrebbe manipolare il sistema anche in altri modi.

link

{"alg":"HS256","typ":"JWT"}.{ "admin": false, "name": "John Doe", "iat": 1516239022}.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhZG1pbiI6ZmFsc2UsIm5hbWUiOiJKb2huIERvZSIsImlhdCI6MTUxNjIzOTAyMn0.lN5mCX6BnfgtoRVHVaTt9hcj3VUcHWAwdnTT-PLca3c

{"alg":"none","typ":"JWT"}.{ "admin": true, "name": "John Doe", "iat": 1516239022}.signature

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJhZG1pbiI6dHJ1ZSwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

Gli esempi che trovo provengono da PHP, Python e Java e alcune descrizioni indicano che JSON o XML non fanno parte della classificazione.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

link

Sì, la vulnerabilità è più importante della classificazione, ma sono comunque interessato a classificazioni corrette.

    
posta Ogglas 11.07.2018 - 16:41
fonte

1 risposta

1

Tldr: la chiara distinzione tra classi vulnerabili non è sempre possibile.

Per prima cosa guardare "serializzazione non sicura" in un modo diverso:
Dalla descrizione, Owasps "serializzazione insicura" è un mix un po 'confuso di (imo) 3 problemi separati:

  • Una sottosezione specifica di semplici valori di input non attendibili per i primissimi - a chi importa dei formati di serializzazione. Nel tuo blocco di codice, l'admin: true (e il server che crede questo valore) è il problema, nient'altro. Se si trova da solo, al di fuori di qualsiasi Json ecc., È sempre lo stesso problema.
  • Input ancora non attendibile, ma un'altra sezione: scambio di codice (classi, metodi ...). Se è in corso un'iniezione di dipendenza per EncryptionAlgorithmInterface e le implementazioni disponibili sono None , DES , AES256 e così via - cosa posso fare con l'oggetto serializzato? Cambiando l'algoritmo su none, quindi trovo un punto in cui posso leggere i dati mentre invio su Internet.
  • Problemi per definizione nel serializzatore stesso. Che cosa succede se inviare un flusso infinito di [[[[[[[... in un servizio web in attesa di Json (cioè Array di array di array di ... e dei valori e chiusura ] non vengono mai inviati)? Una semplice implementazione raggiungerà rapidamente un overflow dello stack (errore, non il sito Web), causando il blocco del processo del server.

Il tuo link token web Json ...

  • è almeno un input non attendibile.
  • È anche la serializzazione insicura (Owasps), ma in realtà, a chi importa: il problema non è ancora il formato dei dati.
  • Dopo che la spiegazione è stata scritta, è diventata anche "componenti in esecuzione con vulnerabilità note".
  • Non in Owasps Top10, ma è anche un problema di definizione del protocollo.
  • ...

Infine, riguardo alla parte della serializzazione nativa che offre più di Json, ecc .: Beh, parzialmente - ma questo non fa es. Versione di PHP sicura.

In Java è possibile prendere un oggetto, scrivere lo stato completo su un array di byte (cioè, il contenuto della variabile membro corrente (sia i tipi semplici che altri oggetti), ma anche codice binario eseguibile in alcune situazioni, ecc.) e quindi ricreare tutto da questo array di byte. L'accesso a un metodo Java serializzato che verrà eseguito in seguito è ovviamente molto utile per fare cose cattive. E se non ce n'è nessuno, introdurre uno che sarà chiamato a causa del suo nome ad un certo punto (ad esempio equals) è anche facile.

In PHP, non esiste un modo così semplice per salvare e caricare parti di codice eseguibili come il runtime in memoria, quindi abusare di questo non è possibile. Tuttavia , i nomi degli altri metodi da chiamare potrebbero ancora essere lì. Non è così conveniente, ma comunque bello.

    
risposta data 11.07.2018 - 17:54
fonte

Leggi altre domande sui tag