Sicurezza e sanificazione degli input dell'utente con controllo limitato sugli obiettivi di "output"

1

Recentemente mi sono unito a un team che lavora su un'applicazione con un sistema di chat integrato. È un sistema di chat standard che consente ai client di comunicare, con i messaggi instradati attraverso un server centrale.

Di solito quando si ha a che fare con il testo di input dell'utente, si consiglia di "escape-on-output" invece di "escape-on-input". Esistono numerosi esempi ( 1 , 2 , 3 ) sul motivo per cui è meglio, ma in pratica si riduce a: è necessario disinfettare il testo in base al contesto in cui viene utilizzato. Se si inserisce un messaggio di chat utente in un database, è necessario eseguire l'escape per SQL e utilizzare istruzioni preparate. Se visualizzi il messaggio chat su un browser web, dovresti eseguire l'escape per HTML. Ecc.

Sfortunatamente, nessuno dei precedenti problemi di sicurezza è stato riconosciuto fino a poco tempo fa. (Sì, davvero).

La soluzione rapida per "hackerare" era filtrare i messaggi di chat degli utenti quando venivano ricevuti dal server, e escludere qualsiasi personaggio dall'aspetto nefasto (<, >, ", ', {, }, \, ecc.) Ciò ha portato a molti reclami da parte degli utenti, dal momento che la loro punteggiatura sarebbe scomparsa magicamente durante la visualizzazione nel canale di chat.

Voglio credere che possiamo fare meglio di questo "hacking" attuale e consentire agli utenti di digitare qualsiasi testo che desiderano in un ambiente sicuro.

Il problema è che sto lavorando con restrizioni apparentemente impossibili. Disponiamo di numerose versioni del client, distribuite su molti dispositivi, migliaia di utenti e lenti tassi di adozione delle nuove versioni. C'è molta frammentazione e non possiamo forzare l'aggiornamento dei client.

La gestione non si preoccupa troppo dell'esperienza utente e in pratica mi ha detto:

Implement a solution to protect against every possible type of malicious user-input without having to touch the clients. Oh, and also protect against any future 'careless' developer who doesn't know what they are doing and might accidentally try to eval() the user chat message.

(Sì, in realtà mi è stato detto che l'ultima parte).

C'è una soluzione migliore a questo problema che fornisca un'esperienza utente leggermente migliore?

Grazie per la lettura.

    
posta smg 07.07.2015 - 04:51
fonte

2 risposte

2

Sì, il tuo manager ha ragione - i difetti di sicurezza non si fanno da soli, sono stati tutti prodotti da uno sviluppatore che non ha preso in considerazione ogni caso. Poiché il software può essere complicato, tutti possiamo esserne colpevoli. Quindi progettate un sistema in modo difensivo per aiutarci a evitare di rovinare. Un giorno arriverà un requisito che richiede la valutazione e poi ...

Quindi, puoi eliminare lo stripping di qualsiasi carattere e invece rendere l'input sicuro per l'inserimento nel DB. Questo dovrebbe essere semplice e facile da verificare.

Quindi è necessario modificare le routine che estraggono i dati dal DB e li sanitizzano per il client. Se non riesci a rilevare l'applicazione client (ad es. Thick client o web), dovrai applicare un minimo comune denominatore a tutti gli output, sfuggendo a tutte le possibilità.

La parte importante qui è la verifica dei dati, l'eliminazione di qualsiasi carattere è, come hai trovato, inutile. Quindi determinare quali sono i requisiti per rendere i dati sicuri piuttosto che implementare una modifica troppo ampia. Questo dovrebbe essere vendibile al tuo capo - non puoi dire se è fatto bene se non sai cosa sia giusto.

    
risposta data 07.07.2015 - 10:36
fonte
2

È abbastanza facile rimanere frustrati con la gestione in queste situazioni, ma tieni presente che la tua azienda esiste solo per fare soldi. Avere un'applicazione super utile e sicura non è necessariamente un obiettivo utile dal punto di vista di un gestore.

Non hai menzionato in che formato i dati vengono inviati ai client ma se è in formato HTML hai considerato sostituire alcuni caratteri con il loro modulo di entità HTML? Invece di rimuoverli tutti insieme. Cioè > diventa &gt; ecc. Dal punto di vista del cliente, saranno ancora in grado di inviare e ricevere caratteri non di parole ma senza il rischio di XSS. Questa sarebbe la mia raccomandazione.

Purtroppo credo che potrebbe essere necessario filtrare sia i dati in entrata che quelli in uscita a causa di problemi come l'iniezione SQL del secondo ordine in cui i dati che non sono immediatamente dannosi diventano così quando vengono recuperati e utilizzati in un contesto diverso.

Sembra che potresti anche trarre vantaggio dall'educare un po 'il tuo manager. Non esiste una cosa sicura al 100%. Un approccio popolare al concetto di sicurezza che mi piace è che la sicurezza non consiste nel rendere il tuo sé invulnerabile nel sollevare l'asticella a un livello in cui non vale più la pena che qualcuno ti attacchi.

Ancora una volta, torna ai soldi. Se puoi parlare con il tuo manager al suo livello, su quanto impegno ingegneristico e tempo (quindi denaro) ci vorrà per ottenere ciò che sta chiedendo, allora potrebbe darti un po 'di fiato. Fallo iniziare a pensare a "abbastanza sicuro" non solo "sicuro".

    
risposta data 07.07.2015 - 15:42
fonte

Leggi altre domande sui tag