È sufficiente confrontare l'input dell'utente non pubblicizzato per essere vulnerabile a XSS?

Question

È sufficiente confrontare l'input dell'utente non pubblicizzato per essere vulnerabile a XSS?

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

1

Dire che ricevo l'input dell'utente da window.location.hash . È sufficiente confrontare questo input non pubblicizzato con i valori consentiti per accedere alle vulnerabilità XSS?

Prendi il seguente codice di esempio:

jQuery(function ($) { 
  var hashVal = window.location.hash; 
  $('.some-container').children().each(function(){ 
    var link = $('a', $(this));
    if(hashVal === link.attr('href')){
      //do something with link
    }
  }); 
});

L'ho provato contro alcune stringhe potenzialmente fastidiose senza successo (o successo totale a seconda di come la si guarda).

Sono curioso di sapere che if(hashVal === link.attr('href') potrebbe essere sfruttato con qualcosa come #1 || true){}; //some malicious code...; // .

javascript xss

posta Ben.12 01.03.2017 - 18:28

fonte

2 risposte

1

Il tuo codice sembra buono e non è sfruttabile.

Una stringa JavaScript contiene solo, beh, una stringa di lettere. A volte quelle lettere formano un pezzo di codice. Ciò non è pericoloso di per sé, poiché JavaScript lo tratta come una raccolta di lettere per la maggior parte del tempo, ad es. quando fai il paragone delle stringhe.

Perché apra una vulnerabilità XSS, qualcosa deve eseguire il codice. Ci sono due modi in cui può accadere:

Se si assegna la variabile come input a una funzione che esegue la stringa come codice. Quello principale qui è eval , ma c'è anche new Function , setTimeout e setInterval .
Se inserisci la stringa nel DOM, ad es. utilizzando innerHTML .

Se rimani lontano da questi due, il codice non verrà eseguito.

risposta data 01.03.2017 - 18:57

fonte

Leggi altre domande sui tag javascript xss

Chrome non vede il certificato SSL per il dominio principale mentre vede www Quale metodo di crittografia a chiave pubblica dovrei scegliere di firmare?

score 0 · Accepted Answer

La risposta di Anders spiega già perché il tuo codice va bene. Mi piacerebbe concentrarmi sulla seguente affermazione:

the if(hashVal === link.attr('href') could be exploited with something like #1 || true){}; //some malicious code...; //.

Sembra che tu stia partendo dal presupposto che #1 || true){}; // some malicous code ; // possa portare a quanto segue:

if(#1 || true){}; //some malicious code...; // === link.attr('href') {
   // do something with link
}

(che non avrebbe molto senso comunque perché il # 1 non è javascript legale, per quanto ne so). Tuttavia, non è così che Javascript (o qualsiasi linguaggio di programmazione che conosco) valuta le espressioni.

Per me, il tuo esempio sembra che tu stia cercando di utilizzare un attacco SQL injection su Javascript. L'iniezione SQL ha esito positivo perché le persone incollano le richieste in questo modo (invece di utilizzare le query parametrizzate):

query = 'SELECT * FROM users WHERE loginname = "' + name + '"'

Questo è un errore orribile perché il nome potrebbe contenere qualcosa come 1"; drop table users; # .

Incollare insieme una stringa di query come quella consente a un utente malintenzionato di sfuggire dalla protezione della stringa citata in SQL raw.

Ma non siamo nella stessa posizione quando scriviamo il codice Javascript. Per rendere il tipo di exploit che temevi fosse possibile in Javascript, dovresti incollare il codice insieme come le persone incollano le query sql insieme, forse in questo modo:

var jscode = 'if (' + hash + ' === link.attr("href") { ... }'

Quindi se hash contiene qualcosa come true) { malicious_code() } , e se come ha detto Anders, metti il contenuto di jscode nel DOM o fai eval(jscode) , il codice dannoso verrebbe eseguito.

Altrimenti, è ben isolato in una stringa innocua.