I nomi delle chiavi JSON sono vulnerabili agli attacchi di codifica alternativa (CAPEC-267)?

1

A volte è possibile utilizzare una codifica alternativa per aggirare i controlli di sicurezza ( CAPEC-267 ). Mentre le specifiche JSON possono essere rigide su ciò che è valido, i parser popolari non necessariamente si conformano perfettamente [1] .

La mia domanda è quindi: quali sono le codifiche alternative consentite dallo standard e quali sono consentite dai parser popolari? Tra le codifiche alternative esistenti, quanto possiamo essere sicuri di non poter essere utilizzate in un attacco? L'attacco specifico di cui mi occupo è evitare una lista bianca o nera che controlla i nomi delle chiavi JSON in input non attendibili, ma sarei interessato a conoscere altri attacchi possibili attraverso la codifica alternativa delle chiavi JSON -  a mio vantaggio e a quello degli altri.

[1] Ad esempio, la specifica afferma che i nomi delle chiavi sono case sensitive. Il pacchetto di codifica / json di Golang preferisce le corrispondenze con distinzione tra maiuscole e minuscole, ma tornerà alla corrispondenza della chiave senza distinzione tra maiuscole e minuscole - vedere ( json.Unmarshal ( ) ).

(Modifica) Caso di utilizzo: sono coinvolto nello sviluppo di un'appliance collegata in rete. Normalmente è controllato dalla nuvola; tuttavia, se viene erroneamente configurato non è possibile - o se l'utente finale non configura la propria rete in un modo che possiamo capire. L'uptime è molto importante per i clienti, quindi sto lavorando a un meccanismo in base al quale un file di "salvataggio" viene scritto su una chiave USB dall'utente finale e quindi inserito nell'appliance. Alcune attività, come il riavvio di particolari processi, sono considerate sicure e quindi non è necessaria una firma.

Dal momento che non riesco a immaginare ogni possibile problema, c'è anche una disposizione per una chiave JSON il cui valore è i comandi della shell - ovviamente molto più pericoloso. Ho una blacklist che blocca chiavi di comando pericolose come questa a meno che una firma sia presente e valida. Attualmente, sto semplicemente facendo una ricerca di testo insensibile alle maiuscole per ogni "key_name" (comprese le virgolette, per ridurre la possibilità di falsi positivi), mentre i dati sono ancora codificati come json. Finché un hacker non può usare qualcos'altro al posto delle virgolette o usare una sorta di codifica, penso che la mia lista nera molto semplice funzionerà bene.

Originariamente pensavo di pubblicare su StackOverflow ma ho deciso che era una soluzione migliore. Mi scuso se non è così.

    
posta Mark 23.10.2017 - 18:25
fonte

0 risposte

Leggi altre domande sui tag