codice JS vulnerabile?

Question

codice JS vulnerabile?

#1 da (3 voti)
#2 da (3 voti)

0

Puoi aiutarmi per capire cosa fa esattamente questo codice e se potrebbe essere vulnerabile?

<script type="text/javascript">

        function getUrlVars(){

            var vars = [], hash;
            var hashes = window.location.href.slice(window.location.href.indexOf('?') + 1).split('&');
            for(var i = 0; i < hashes.length; i++)
            {
                hash = hashes[i].split('=');
                vars.push(hash[0]);
                vars[hash[0]] = hash[1];
            }
            return vars;
        }

        var get_parameters = getUrlVars();
        if(get_parameters['rpath'] != undefined && get_parameters['rpath'] != 'default'){
            var redirectPath = get_parameters['rpath'];
            document.getElementById('redirectpg').href = redirectPath;
        }else{

            document.getElementById('redirectpg').href = "index.php";

        }

    </script>

javascript

posta purcel 06.03.2014 - 15:52

fonte

2 risposte

Leggi altre domande sui tag javascript

La crittografia ignorerebbe alcune regole del firewall? Come può essere compromessa una password di root debole?

score 3 · Answer 1

Sì, è vulnerabile a XSS. Un semplice exploit sarebbe simile a questo:

example.com/index.php?rpath=javascript:alert(document.cookie)

Il parametro rpath verrà afferrato dalla tua funzione getUrlVars() e assegnato a redirectPath . L'elemento redirectpg avrà l'attributo href modificato nel codice XSS. Quando l'utente fa clic sull'elemento redirectpg (presumibilmente un ancoraggio <a> ), verrà eseguito il codice JavaScript dannoso.

Ciò può portare al furto di cookie e all'imposizione di un utente legittimo e probabilmente rieseguire il rendering del modulo di accesso e rubare la password effettiva dell'utente. In sostanza, l'autore dell'attacco è in grado di mostrare all'utente ciò che desidera all'interno del tuo sito web.

score 3 · Answer 2

Sì, questo codice sembra vulnerabile a un'iniezione XSS.

Che cosa fa questo codice?

Controlla l'URL che l'utente ha digitato per gli argomenti GET. Gli argomenti GET sono tutto dietro un punto interrogativo e sono tipici di un gruppo di coppie chiave / valore con un segno di uguale tra loro separati da & .

In questo esempio di URL

 http://example.com/somesite.html?somevar=42&rpath=someothersite.html

l'argomento ci sono due di queste variabili. somevar = 42 e rpath = someothersite.html

Il tuo script cercherà quindi un link specifico sul tuo sito web, prenderà il valore di rpath e sostituirà il target del link con esso. In questo esempio, quel collegamento verrebbe quindi modificato in modo che punti a someothersite.html .

Come potrebbe essere abusato?

Un link su un sito web non può semplicemente puntare a un altro sito web. È anche possibile avere collegamenti che iniziano con javascript: seguito da codice javascript. Quando un utente fa clic su questo link, quel codice verrebbe eseguito nel contesto del sito Web attualmente caricato.

Ciò significa che un utente malintenzionato potrebbe inviare all'utente un collegamento come questo:

http://example.com/somesite.html?rpath=javascript:alert('hello world')

Quando l'utente farebbe clic su quel link e poi sul link di reindirizzamento sul tuo sito web, quel codice javascript verrebbe eseguito.

Perché questo è un problema?

Il sito web attuale potrebbe contenere informazioni riservate. Un javascript eseguito nel contesto di quel sito Web può catturare tali informazioni e inviarlo a un server controllato dai malintenzionati.

Lo script ha anche accesso a tutti i cookie e agli utenti localstorage. Quando si utilizzano i cookie per tenere traccia delle sessioni degli utenti, un utente malintenzionato potrebbe fare in modo che lo script invii i cookie degli utenti al proprio server. Ciò potrebbe consentire di dirottare la sessione dell'utente e assumere il controllo del proprio account.

A seconda di ciò che effettivamente fa il tuo sito web, potrebbero esserci anche molti altri modi in cui un utente malintenzionato potrebbe causare ogni tipo di danno ingannando gli utenti nell'esecuzione del codice javascript.

Come si può fare meglio?

Mettere i dati utente non filtrati in un documento HTML è sempre pericoloso. In questo caso potresti pensare che potrebbe essere sufficiente rifiutare qualsiasi argomento contenente javascript: , ma l'exploit mostrato sopra è solo il più ovvio. Ci sono probabilmente molto più sottili. Cercare di filtrare tutto ciò che potrebbe essere malvagio sembra essere al di là delle capacità di programmazione dell'autore del frammento di codice di cui sopra, quindi consiglierei di provarlo. Invece li consiglierei di adottare un approccio molto più sicuro. Invece di inserire qualsiasi stringa nel sito Web che l'utente fornisce, avere un insieme limitato di stringhe possibili da inserire e sceglierne una a seconda dell'argomento fornito:

switch(redirectPath) {
    case 'home':
        document.getElementById('redirectpg').href = 'home.php';
        break;
    case 'about':
        document.getElementById('redirectpg').href = 'about.php';
        break;
    case 'contact':
        document.getElementById('redirectpg').href = 'contact.php';
        break;
    default:
        document.getElementById('redirectpg').href =  'index.php';
        break;
}