Evasione variabile JavaScript quando il preventivo è sfuggito, ma non newline

Question

Evasione variabile JavaScript quando il preventivo è sfuggito, ma non newline

#1 da (4 voti)
#2 da (0 voti)

2

Sto cercando un modo per eludere correttamente da una variabile JavaScript per eseguire XSS. Un normale input dell'utente darà var a='<b>user input</b>' .

a non è sempre disponibile e non è utilizzabile. Comunque, ho trovato qualcosa di interessante. Un input come %0a%0dalert(1);// verrà visualizzato come:

var a='<b>
alert(1);//</b>'

Il mio browser mi avvisa di un errore token illegale. Questo è normale e a causa di var a non viene chiuso.

C'è un modo per farlo funzionare? Esecuzione della funzione di avviso ignorando l'errore precedente. ' è sfuggito come \' e \ come \ . Altre nozioni di base I caratteri HTML sono anche codificati in modo normale ( " < > & )

javascript xss

posta Xavier59 27.05.2016 - 23:05

fonte

2 risposte

0

Dovrò concordare con la valutazione di SilverlightFox che lo sfruttamento di successo di questo "possibile" vettore di attacchi sarà gravemente ostacolato (come lo è l'intento di codificare in primo luogo).

Non sembra esserci alcun modo per "consumare" (cioè sovrascrivere) i caratteri sotto UTF-8, e i caratteri che è necessario interrompere sono già sottoposti a escape. La tua domanda è sostanzialmente parallela a ciò che è già stato chiesto qui: In che modo l'igienizzazione che sfugge alle virgolette singole può essere sconfitta dall'iniezione SQL in SQL Server?

La risposta breve è "Ci sono alcuni casi di pochi (enfasi) in cui la funzione di escape fallirà:"

Il contesto non impiega virgolette singole circostanti (che è il tuo, quindi questo non si applica)
Se una sottostringa viene filtrata; questo è abbastanza antipatico in quanto l'aggressore tenta di utilizzare le routine di codifica / filtraggio contro la tua applicazione. Se, ad esempio, le regole di filtro eseguono un singolo passaggio, rimuovendo tutte le occorrenze di "onclick" nell'input dell'utente, ma l'autore dell'attacco passa "ononclickclick", i risultati del filtraggio vengono "onclick" scritti nella pagina. Questo ovviamente ti obbliga a sfogliare manaully i tuoi filtri per assicurarti che non lasci dietro caratteri che potrebbero sfuggire alla tua routine di codifica.
Attacchi Unicode supportati (ad esempio, database accetta GBK , ecc.)

Fonte: link

risposta data 13.07.2016 - 01:25

fonte

Leggi altre domande sui tag javascript xss

Qual è la differenza tra una firma digitale e la crittografia dell'intero messaggio? I dati che arrivano nel mio server UDP possono essere annusati?

score 4 · Accepted Answer

Per causare l'iniezione in questo contesto è necessario:

Chiudi il tag dello script:

per es.

</script><script>alert('xss');

OPPURE chiudere il contesto della stringa di quotazione singola:

per es.

'; alert('xss');

Tuttavia, poiché la prima opzione risulterebbe in < , ecc, e la seconda opzione comporterebbe la visualizzazione di \' caratteri (e non è possibile sfuggire \ a causa di \ ), vorrei dire che XSS non è possibile in questo caso.

L'unica speranza è che se il set di caratteri è UTF-7 o potrebbe essere cambiato in UTF-7 XSS .

L'unico difetto di sicurezza qui altrimenti è che un utente malintenzionato potrebbe causare un Denial of Service impedendo l'esecuzione di altri codici JavaScript e impedendo il funzionamento dell'applicazione come previsto.