Come proteggere dalla nuova tecnica Javascript Injection che non usa eval ()?

Question

Come proteggere dalla nuova tecnica Javascript Injection che non usa eval ()?

#1 da (11 voti)
#2 da (2 voti)

4

C'è una nuova tecnica di iniezione Javascript che sta generando chatter nei forum menzionati qui

Ecco il codice di esempio:

String.prototype.code = function(){ return (new Function('with(this) { return ' + this + '}' )).call({}); };
var s = 'alert("hello!");'
s.code();

Quali componenti dell'infrastruttura devono essere aggiornati (se esistono) per monitorare e proteggere da questa classe di exploit?

Ad esempio:

Ho l'impressione che alcuni DBA analizzino i loro database per la prova di un attacco di iniezione ... questo è quasi un approccio di ultima generazione per mitigare un'applicazione mal scritta in un'impresa distribuita.

Quando ho collaborato per la prima volta con Microsoft a un attacco JS Injection, lo sviluppatore in India non ha verificato correttamente l'input del modulo. Ciò ha causato l'ingombro del database dei nostri clienti con codice Javascript eseguito sul client. La risposta di Microsoft è stata la ricerca nel database di stringhe predefinite comunemente utilizzate negli attacchi.

Sto assumendo che ci sono prodotti o sensori che monitorano il traffico SQL o HTTP per ovvi js-malware. Se faccio un passo ulteriore, quei dispositivi devono avere la firma aggiornata per questo vettore.

javascript web-application appsec xss

posta random65537 17.05.2011 - 17:10

fonte

2 risposte

2

Non sono sicuro di capire cosa c'è di così diverso in questa tecnica rispetto al tipo generale di ~~injection~~ cross site scripting.

Se questo è andato così lontano e ti capita di permettere che il codice JavaScript arbitrario venga iniettato ed eseguito sul tuo sito, stai chiedendo guai in ogni caso, indipendentemente dalla tecnica. Prova a controllare il tuo sito per le più comuni vulnerabilità XSS .

Mi dispiace se mi manca qualcosa qui, per favore correggimi se non ho ottenuto la grande immagine qui (come mi sento in quel modo).

risposta data 17.05.2011 - 17:30

fonte

Leggi altre domande sui tag javascript web-application appsec xss

LDAP vs MySQL per nomi utente e password Ci sono dei buchi in questo disegno di sicurezza?

score 11 · Accepted Answer

È tutto XSS, non è corretto chiamarlo "JavaScript Injection". Il vettore XSS di cui stai parlando non è nuovo ed è interessante. XSS è un problema di output . Se si esegue la stessa convalida dell'input su tutti gli input, si avranno ancora problemi con XSS. Se codifichi o rimuovi tutti i < > caratteri per ogni variabile di input avrai ancora enormi problemi con xss. Questo perché XSS dipende molto da dove la variabile viene stampata sulla pagina.

Questa riga di codice è sicura:

var x='alert(123)'

Tuttavia, può essere sfruttabile se l'autore dell'attacco ha accesso a virgolette singole ' . Ad esempio, se l'autore dell'attacco ha ricevuto una richiesta come ?x=';alert(123); , allora sarebbe in grado di uscire dalle virgolette ed eseguire javascript. La soluzione è di codificare anche tutte le virgolette. In PHP puoi usare htmlspecialchars($var,ENT_QUTOES);

Ma ecco il vero kicker, anche questa funzione non può fermare tutto l'XSS. Si fermerà circa ~ 90% di xss. Ma anche dopo un htmlspecialchars($var,ENT_QUTOES); puoi ancora incontrare problemi con DOM basato su xss e XSS tramite gestori di eventi .

Quindi, qual'è la soluzione reale ? Metti alla prova il tuo codice! Utilizza un servizio di scansione vulnerabilità gratuito come Sitewatch o uno strumento open source come Wapiti . Questi strumenti conoscono tutte le strane regole per XSS e saranno in grado di trovare queste violazioni nella tua applicazione. Google utilizza Sitewatch .