JavaScript Essentials: Client-Side Scripting, Dialogue Abuse, and Obfuscation

Introduction

Welcome to my walkthrough of the TryHackMe room JavaScript Essentials! This is the second room in the Web Hacking module of the Cyber Security 101 path.

In my previous article, Web Application Basics, we covered how a web application is put together, the anatomy of a URL, and how HTTP requests and responses actually communicate under the hood. This room narrows that focus considerably, moving from the protocol layer down into the client side itself: JavaScript, the scripting language responsible for nearly everything interactive you see in a browser. We'll look at the language from a security perspective, exploring how the same legitimate functionality developers rely on every day can be abused to annoy, deceive, or exploit an unsuspecting user.

If you missed the previous entry in this series, you can catch up on my walkthrough for Web Application Basics below.

What we will cover

• The essential building blocks of JavaScript: variables, data types, functions, and loops
• Writing and running JavaScript directly in the Google Chrome console
• Internal versus external JavaScript, and how to spot the difference in a page's source
• How dialogue functions like alert, prompt, and confirm can be abused by an attacker
• Bypassing control flow statements, including a simple client-side login form
• Reading, creating, and reversing minified and obfuscated JavaScript
• Best practices for writing safer, more defensible JavaScript
• Answers to every question in the room

Room Information

Before we dive into the tasks, here is a quick overview of the room details.

• Room Name: JavaScript Essentials
• Path: Cyber Security 101
• Module: Web Hacking
• Topic: JavaScript Fundamentals, Client-Side Scripting, and Attacker Abuse Cases
• Difficulty: Easy
• Room Link: TryHackMe — JavaScript Essentials

Task 1: Introduction

JavaScript (JS) is a scripting language that gives web developers a way to add interactivity to pages otherwise built from HTML and CSS. Once the structure and styling of a page exist, JS is what handles form validation, click events, animations, and dynamic content updates. Because it sits directly alongside HTML and CSS in nearly every modern web application, it's just as important to understand from a security standpoint as either of those two.

This room is aimed squarely at beginners with little to no prior JS experience. Rather than trying to cover the language exhaustively, it focuses on the fundamentals and, more importantly, on how attackers take legitimate JS functionality and turn it toward malicious ends. The attached VM includes an exercise folder on the Desktop containing every script built throughout the room, in case following along by hand isn't practical.

Task 2: Essential Concepts

A handful of core concepts underpin everything else in this room. Variables act as labeled containers for storing data, declared in JS using var (function scoped), let, or const (both block scoped, offering tighter control over where a variable is visible). Data types describe what kind of value a variable holds: strings, numbers, booleans, null, undefined, and objects (which cover more complex structures like arrays).

Functions group a block of code meant to perform a specific, repeatable task, letting you avoid writing the same logic over and over**. Loo**ps, most commonly for, while, and do…while, repeat a block of code as long as a condition holds true, which is exactly how you'd call a function against every item in a list without writing it out by hand a hundred times. Finally, the request-response cycle describes the fundamental exchange between a browser and a web server: the client sends a request, and the server replies with a response, whether that's a full page, JSON data, or something else entirely.

Questions and Answers

What term allows you to run a code block multiple times as long as it is a condition?

Answer:

loop

loop

Task 3: JavaScript Overview

JS is an interpreted language, meaning the browser executes the code directly rather than compiling it ahead of time. Because so much of it runs client side, the easiest way to experiment with it is directly inside the browser itself, using the built-in developer console.

Google Chrome's Console (opened with Ctrl+Shift+I or via right-click, Inspect, then the Console tab) lets you write and run JS on the spot without any additional tooling. A short script combining a couple of variables with a simple expression is enough to demonstrate the whole loop: define two numbers, add them together, and print the result with console.log.

let x = 5;
let y = 10;
let result = x + y;
console.log("The result is: " + result);

let x = 5;
let y = 10;
let result = x + y;
console.log("The result is: " + result);

Guided Walkthrough: Running JavaScript in the Chrome Console

After opening Google Chrome from the Desktop and launching the Console via Ctrl+Shift+I, we pasted the addition script above directly into the console prompt and pressed Enter.

With the script executed once as written, the room then asks what changes if the value assigned to x is updated from 5 to 10. Since console.log simply concatenates the string with whatever result evaluates to, re-running the modified script in the same console session is enough to see the new output directly.

Questions and Answers

What is the code output if the value of x is changed to 10?

Answer:

The result is: 20

The result is: 20

Is JavaScript a compiled or interpreted language?

Answer:

Interpreted

Interpreted

Task 4: Integrating JavaScript in HTML

JS rarely exists in isolation. It's almost always paired with HTML and CSS, and there are two standard ways to wire it into a page. Internal JS embeds the script directly inside the HTML document between <script> tags, either in the <head> (for logic that needs to run before the page renders) or in the <body> (for logic tied to elements as they load). External JS instead stores the code in a separate .js file, referenced from the HTML using the src attribute on the <script> tag, which keeps the HTML document cleaner and makes the script reusable across multiple pages.

From a security testing perspective, telling the two apart matters. Viewing a page's source reveals script tags with inline code (internal) versus script tags carrying only a src attribute pointing elsewhere (external), and knowing which pattern a target application uses shapes how you'd go about auditing its client-side logic.

Guided Walkthrough: Internal and External JavaScript

To see internal JS in action, we created internal.html on the Desktop using Pluma and pasted in a small script that adds two numbers and injects the result directly into a paragraph element using document.getElementById("result").innerHTML. Saving the file and opening it in Chrome rendered the calculated sum immediately, since the script runs the moment the page loads.

Next, we split the same logic into an external file, saving the calculation script as script.js and linking it from a new external.html document using <script src="script.js"></script>. Opening the new file produced an identical result to the internal version, confirming that the browser fetches and runs the external file the same way it would inline code.

Finally, to practice distinguishing the two in the wild, we opened external_test.html from the exercise folder and used Chrome's View Page Source option to inspect its markup. Since the script here loads from a separate file rather than being written inline, the <script> tag in the source carries a src attribute naming the external file directly.

Questions and Answers

Which type of JavaScript integration places the code directly within the HTML document?

Answer:

Internal

Internal

Which method is better for reusing JS across multiple web pages?

Answer:

External

External

What is the name of the external JS file that is being called by external_test.html?

Answer:

thm_external.js

thm_external.js

What attribute links an external JS file in the

Answer:

src

src

Task 5: Abusing Dialogue Functions

JS ships with three built-in dialogue functions designed for straightforward user interaction. alert displays a message with a single "OK" button, useful for simple notifications. prompt asks the user for text input, returning whatever they type (or null if they cancel). confirm poses a yes/no style question, returning true or false depending on which button the user clicks.

None of these functions are dangerous on their own, but wrapping one inside a loop, or triggering it the moment an untrusted file opens, turns a normal feature into a nuisance or worse, an early building block toward Cross-Site Scripting (XSS), covered later in this module. A file that spams alert boxes on open is a simple but effective demonstration of exactly this kind of abuse.

Guided Walkthrough: Testing Dialogue Functions and a Malicious HTML File

To see the abuse case play out, we created invoice.html on the Desktop containing a for loop wrapped around an alert("Hacked") call. Opening the file in Chrome triggered the alert box repeatedly, forcing us to dismiss it manually each time before the page would finish loading. The exact number of repetitions is set by the loop's upper bound inside the file itself, worth confirming directly on the VM rather than assuming it matches any example snippet.

Questions and Answers

In the file invoice.html, how many times does the code show the alert Hacked?

Answer:

5

5

Which of the JS interactive elements should be used to display a dialogue box that asks the user for input?

Answer:

prompt

prompt

If the user enters Tesla, what value is stored in the carName variable from carName = prompt("What is your car name?")?

Answer:

Tesla

Tesla

Task 6: Bypassing Control Flow Statements

Control flow governs the order in which code executes based on conditions, and JS provides the usual set of tools for it: if-else and switch statements for decisions, alongside for, while, and do…while loops for repetition. Used correctly, these let a program react appropriately to whatever input or state it encounters.

A simple if-else block is enough to build an age check: prompt the user for their age, then branch the displayed message depending on whether that value clears a threshold like 18. The same pattern extends to something more security relevant: a client-side login form that compares entered credentials against a hardcoded value before granting access, a pattern that's trivially bypassed by anyone willing to read the page's source.

Guided Walkthrough: Age Verification and a Client-Side Login Bypass

To answer the first question, we opened age.html from the exercise folder directly in Chrome. The page immediately triggered a prompt dialogue box asking for an age input, so we entered 17 and clicked OK.

Submitting an age value under 18 causes the if-else control flow statement to branch, rendering the minor status message directly on the page body to answer the question.

To answer the second question, we opened login.html inside the Pluma text editor instead of interacting with the form in the browser. Since client-side authentication checks rely entirely on script logic visible to the browser, viewing the source code in an editor immediately reveals the hardcoded password string checked inside the if statement.

Questions and Answers

What is the message displayed if you enter the age less than 18?

Answer:

You are a minor.

You are a minor.

What is the password for the user admin?

Answer:

ComplexPassword

ComplexPassword

Task 7: Exploring Minified Files

Not every script in the wild is as readable as the examples built so far. Minification strips out whitespace, line breaks, comments, and shortens variable names to shrink file size and speed up page loads, a routine step in production deployments. Obfuscation goes further, deliberately restructuring code, renaming variables and functions to meaningless strings, and inserting dummy logic specifically to make the script harder for a human to follow, even though it behaves identically to the original.

Neither technique changes what the code actually does. A minified or obfuscated script still executes exactly the same way in the browser; the only thing that changes is how difficult it is for a person reading the source to understand it at a glance, which matters directly when auditing an unfamiliar web application's client-side logic.

Guided Walkthrough: Minifying, Obfuscating, and Reversing a Script

To answer the first question, we opened hello.html directly in Chrome. Executing the file triggers an embedded script that pops up a browser dialogue box displaying the alert message.

To answer the second question, we pasted the obfuscated arithmetic expression age=0x1*0x247e+0x35*-0x2e+-0x1ae3; into an online deobfuscation tool (Obfuscator.io Deobfuscator). The tool simplifies the hexadecimal math and resolves the expression directly to its calculated integer value.

Questions and Answers

What is the alert message shown after running the file hello.html?

Answer:

Welcome to THM

Welcome to THM

What is the value of the age variable in the obfuscated code snippet age=0x1*0x247e+0x35*-0x2e+-0x1ae3;?

Answer:

21

21

Task 8: Best Practices

A handful of practical habits go a long way toward reducing the attack surface JS introduces into a web application. Client-side validation should never stand alone, since any user can disable or manipulate JS running in their own browser; server-side validation is the only check that can actually be trusted. Untrusted libraries deserve scrutiny before inclusion via src, since malicious packages have been published under names deliberately similar to legitimate ones. Hardcoded secrets, like API keys or credentials embedded directly in client-side code, are trivially exposed the moment anyone views the page source. Finally, minifying and obfuscating production code raises the bar for casual reverse engineering, even though a sufficiently motivated attacker can still work through it given enough time.

Questions and Answers

Is it a good practice to blindly include JS in your code from any source (yea/nay)?

Answer:

nay

nay

Summary & Key Takeaways

That wraps up JavaScript Essentials! This room built a working foundation in client-side scripting from a security angle, exactly the kind of grounding the rest of the Web Hacking module will keep drawing on as it moves into more advanced client-side attacks.

Key lessons:

• Variables, data types, functions, and loops form the essential vocabulary of JS, and none of it looks unfamiliar if you've worked with another programming language before.
• JS can be integrated internally (embedded directly in HTML) or externally (linked via the src attribute), and viewing a page's source is the quickest way to tell which pattern a target application uses.
• Built-in dialogue functions like alert, prompt, and confirm are harmless individually, but looping or forcing them on page load turns legitimate functionality into a genuine nuisance, and a stepping stone toward more serious client-side attacks like XSS.
• Client-side control flow, including login checks written entirely in JS, offers no real security once the underlying script is readable, which it almost always is.
• Minification and obfuscation both leave a script's behavior unchanged while making it harder for a human to read, a technique attackers and legitimate developers both rely on for very different reasons.
• Solid JS hygiene, server-side validation, trusted libraries only, no hardcoded secrets, and minified production code, meaningfully reduces the attack surface a web application exposes on the client side.

If you found this walkthrough helpful, consider following me here on Medium to catch the next room analysis in this series.

You can also connect with me and follow my work across other platforms:

• 💼 LinkedIn:
• 🐦 X (Twitter):