Recentemente lavorando a un'applicazione Web basata su Rails per un'azienda, ho dovuto esaminare la vulnerabilità XSS. Risulta che l'applicazione, in alcuni punti, potrebbe prendere un tag HTML (ad es., <script>jscodehere</script> direttamente come parametro nelle richieste GET o POST.
Questo parametro è quindi accessibile tramite l'hash dei parametri dell'applicazione (l'hash in cui tutti i dati chiave / valore entrante sono resi disponibili dalla richiesta).
Ora, la vulnerabilità XSS derivava dal fatto che il sito rende disponibili anche i dati di molte delle sue pagine in una versione JSON (ad esempio /cart/1.json ).
Attraverso alcuni meccanismi che non capisco appieno (suppongo che questo sia tecnicamente "Reflected XSS"?), il codice <script> non salvato che è poi entrato nel JSON può essere usato per compromettere le macchine personali e altri siti , attraverso l'esecuzione involontaria.
La mia domanda è: perché questo non è un sistema opt-in? Rails è ora nella versione 4, quindi sono sorpreso che una soluzione debba ancora essere costruita manualmente, ma ciò si applicherebbe a qualsiasi framework di applicazione web. Una cosa è permettere ai param di entrare in unsanitized di default (forse i tag HTML saranno usati nella pagina del profilo di un utente e la formattazione è richiesta) - e penso che Rails faccia anche un po 'di scrubbing sull'effettiva azione di rendering, limitando l'output , per impostazione predefinita, solo i tag html "sicuri".
Tuttavia, durante il rendering di JSON, non esegue tale sanitizzazione / pulizia, forse perché quando la risposta JSON viene creata e analizzata è troppo personalizzata per farlo, ma non capisco perché
1) Alcuni meccanismi incorporati non sono in posizione
2) Di questo non si parla più - non ho trovato alcuna discussione sul passaggio non sicuro dei tag HTML / Script nel rendering JSON dalle app Rails o Sinatra sul web (ho potuto trovare solo una piccola quantità di informazioni su Sanitizing l'hash params, quindi i valori di sanificazione sul modo IN, che è probabilmente migliore, ma potrebbe non funzionare per tutto, in quanto è una soluzione valida per tutti, si consiglia di conservare alcuni tag HTML ma solo strip out <script> tag, ad esempio).
3) Perché, nel mondo Ruby, almeno, esiste attualmente una sola libreria che esiste per sanitizzare (la Sanitize Gem, e funziona davvero solo con i tipi di dati String - devi scrivere il tuo codice ricorsivo per disinfettare un hash, come l'hash params, e sembra che non ci sia nulla di scritto su questo!). Rails ha un disinfettante incorporato, ma è considerato inferiore a questo Sanitize Gem di terze parti, e non è così flessibile quando si tratta di avere alcuni livelli di rigidità in quanto profondamente sanificare (una stringa).
Sto fraintendendo la validità dell'iniezione in JSON come vulnerabilità, o questa vulnerabilità è stata in gran parte trascurata perché JSON non è una caratteristica principale di tutte le applicazioni web?
Risultato finale: ho usato un filtro precedente nel controller principale dell'applicazione sul back-end per disinfettare l'hash params ogni volta che arriva da una richiesta, usando la libreria Sanitize.
Tuttavia, ritengo che questo abbia rallentato in modo significativo l'applicazione perché deve verificarsi su ogni richiesta e il Sanitizer esegue essenzialmente una serie di chiamate regex in modo ricorsivo sull'hash. In questo modo nessun tag entra mai nel database, e non può mai realizzarlo tramite JSON, ma è un risultato costoso dal punto di vista delle prestazioni. C'è un modo migliore?