Problemi di sicurezza nel consentire l'inserimento di caratteri speciali nel campo di input

Question

Problemi di sicurezza nel consentire l'inserimento di caratteri speciali nel campo di input

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

2

Sto costruendo un'applicazione web, in cui sono obbligato a consentire all'utente di inserire qualsiasi carattere (anche caratteri speciali - ~!@#$%^&*()_-+=|\{}[];:'"<,.> ) in un campo di input. Per mitigare i problemi causati da loro, mi prendo cura di due cose -

Iniezione SQL - utilizzando query parametrizzate
Cross Site Scripting: HTML che richiede l'input dell'utente prima di aggiungerlo a DOM.

È sufficiente o mi manca qualcosa?

Modifica Per dare un contesto migliore, sto spiegando il flusso.

Nella mia applicazione web, l'input dell'utente passa direttamente a un database. Viene prelevato dal database per creare HTML (anche impostando attributi e stili di elementi html) e JSON. Sto evadendo i valori recuperati dal database durante la creazione di HTML.

Durante la creazione di JSON, non sto sfuggendo a quei valori recuperati. Questo JSON è utilizzato dalla nostra altra applicazione per creare HTML. E mi sto assicurando che i valori siano sfuggiti prima di essere inseriti in HTML.

validation sql-injection xss

posta Moazzam Khan 18.05.2015 - 12:29

fonte

2 risposte

-2

metti l'input dell'utente direttamente in un DB? ... Cattiva idea (in generale).

Dovresti disinfettare tutto l'input. (quindi input provenienti dal client e input provenienti dal database).

Stai facendo affidamento sul Cliente per rendere i valori sicuri nel tuo esempio. qualcosa di cui non dovresti mai fidarti del tutto al di fuori del tuo controllo.

per il resto mi rimetto a @SilverlightFox poiché i suoi punti sono tutti validi e applicabili con 1 aggiunta. L'input dell'utente dovrebbe essere disinfettato non solo sul display ma anche prima dello storage.

risposta data 18.05.2015 - 14:08

fonte

Leggi altre domande sui tag validation sql-injection xss

Utilizzo di RSA per l'autenticazione delle applicazioni Web In che modo ECIES è disponibile nelle librerie convalidate FIPS?

score 3 · Accepted Answer

Non esistono personaggi speciali.

Tutto dipende dal contesto in cui l'input viene utilizzato all'interno dell'applicazione. La protezione da SQLi e XSS è ottima, tuttavia se l'input deve essere utilizzato in una shell di sistema operativo, chiamarlo non va bene.

Codifica o sanifica sempre quando i dati sono usati - lascia questo il più tardi possibile. Ad esempio, quando si esegue l'output in HTML, codifica HTML a questo punto.

Quindi, senza conoscere tutti i punti di output o i sink nell'applicazione, è impossibile dire se manchi qualcosa. Se tutto ciò che stai facendo è inserire i dati in un database e inviarlo in HTML ( not JSON, JavaScript, CSS, ecc.) Se esegui la corretta parametrizzazione e la codifica dell'output HTML nelle giuste posizioni sono buoni per quanto riguarda le vulnerabilità XSS e SQLi. Fare qualcos'altro con i dati richiederebbe una corretta codifica, sanificazione o utilizzo dell'API corretta in base al formato.