Quali caratteri devono essere sfuggiti o sostituiti per evitare gli attacchi callback xss jsonp?

Question

Quali caratteri devono essere sfuggiti o sostituiti per evitare gli attacchi callback xss jsonp?

#1 da (2 voti)

1

Dispongo di un servizio che consente all'utente di specificare un nome di funzione di callback che avvolge i dati restituiti per supportare callback jsonp. Voglio assicurarmi di coprire tutte le mie basi per quanto riguarda la prevenzione degli attacchi XSS.

Nota, ho letto la checklist di sicurezza OWASP ma nessuno dei consigli sembra indirizza direttamente questa domanda.

Questi sono i metodi attualmente supportati per specificare la funzione jsonp in cui il nome della funzione è cbFn e cbFn è dichiarato autonomo, un metodo su un oggetto o accessibile da un oggetto / array:

https://service.com/cbFn
https://service.com/?callback=cbFn
https://service.com/?callback=obj.cbFn
https://service.com/?callback=obj['cbFn']
https://service.com/?callback=obj[1]

Questi restituiscono:

cbFn({data: 'data being returned'})
obj.cbFn({data: 'data being returned'})
obj['cbFn']({data: 'data being returned'})
obj[1]({data: 'data being returned'})

Tuttavia, le seguenti richieste anche funzionano e sono i problemi XSS noti che voglio eludere:

// executes an anonymous function
https://service.com/?callback=(()=%3E{alert(1)})
// replaces the user's callback function with our own
https://service.com/?callback=cbFn=((data)=>{alert(data)})

È sufficiente sostituire / rimuovere i caratteri ()=> nel nome di callback per evitare le vulnerabilità XSS? Voglio consentire il set di caratteri javascript valido per i nomi delle funzioni, quindi limitare l'intervallo di caratteri valido a /[$_\w]+/ (alfanumerico più $ e _) non sembra essere una buona opzione.

javascript xss

posta Geuis 25.08.2018 - 22:07

fonte

1 risposta

Leggi altre domande sui tag javascript xss

Come determinare se il file eseguibile di Windows 10 può connettersi alla mia rete L'impostazione di una password del firmware su un Macbook è sufficiente per prevenire attacchi con avvio a freddo?

score 2 · Answer 1

Sembra che tu stia chiedendo dal contesto del fornitore di servizi che protegge un client remoto, nel qual caso la risposta è semplice:

In qualità di fornitore di servizi, non puoi affatto proteggere da XSS e potresti anche non preoccuparti

Tieni presente che normalmente sono molto impegnato in "difesa approfondita" e inserisco i muri di sicurezza in ogni fase del percorso. Tuttavia penso che questo sia letteralmente uno dei pochi posti in cui non vale la pena preoccuparsi per la tua preoccupazione. Ci sono due ragioni per cui:

1. In condizioni di utilizzo normale, il client in esecuzione ha il controllo completo sulla richiesta e quindi non c'è motivo di aspettarsi payload come questo

In realtà non c'è molto altro da dire su questo, perché non è quello che ti preoccupa. Ma solo per dire ad alta voce: il client stesso sta fornendo il callback JSONP, e quindi se scelgono di chiedervi di restituire il javascript effettivo, allora non c'è una gran ragione per fermarli (specialmente perché farlo sarebbe sciocco e dubito che qualcuno si scomoderà). L'unica altra volta che qualcuno potrebbe richiedere una richiamata "pericolosa" dal server è se il client remoto ha avuto una violazione XSS e il javascript dannoso ha preso il controllo del proprio sistema. Tuttavia, se ciò accade:

2. Il javascript malevolo ha il pieno controllo sul client remoto e non ha comunque bisogno di eseguire javascript arbitrario

Il che è altrettanto semplice: se un utente malintenzionato ha gestito un attacco XSS contro un client che utilizza il servizio, non è necessario immettere javascript dannoso nella richiamata. Possono semplicemente sostituire il metodo di callback nel client locale con il proprio. In effetti, è molto più facile. Di conseguenza, non vi è letteralmente alcun motivo per cui qualcuno possa tentare di utilizzare il proprio servizio come endpoint dell'iniezione XSS nel client remoto. Per dirla semplicemente:

Se un utente malintenzionato ha gestito un attacco XSS contro un client che utilizza il tuo servizio, ha già vinto e non ha motivo di trasferire i payload XSS al tuo servizio. Rifletterebbe solo sulla pagina che hanno già rilevato.

Suppongo che potrebbero esserci alcuni sviluppatori là fuori che escogitano un pazzo (pericoloso) schema in cui l'input dell'utente sul loro sito viene utilizzato per costruire il callback JSONP passato al tuo servizio, e diventa una vulnerabilità di vulnerabilità XSS di primo ordine . Tuttavia, non c'è alcun motivo pratico per cui qualcuno possa mai fare qualcosa del genere (avendo usato molti di questi tipi di servizi io stesso, dovresti fare di tutto per impostare qualcosa di così pericoloso), così tanto che non lo faccio pensa che valga la pena spendere del tempo a cercare di proteggere i tuoi utenti da quel livello di stupidità. È più probabile che tu introduca accidentalmente effetti collaterali negativi per i tuoi utenti normali piuttosto che proteggere qualcuno contro il livello di pianificazione scadente che sarebbe necessario per questa protezione da parte tua per fare qualsiasi cosa.