I Turned a “What’s Your Name?” Field Into a Malicious Link — My First HTML Injection
TryHackMe — How Websites Work
I Turned a “What’s Your Name?” Field Into a Malicious Link — My First HTML Injection
TryHackMe — How Websites Work
Every website you’ve ever visited is built on the same three foundations: HTML, CSS, and JavaScript. Understanding how these work together isn’t just useful for developers — it’s essential for security researchers, because almost every web vulnerability exists at the intersection of these technologies and human error.
Today I completed TryHackMe’s “How Websites Work” room. I learned the actual mechanics of how a webpage gets built and rendered — and then I exploited a real vulnerability called HTML Injection, turning an innocent “What’s your name?” input field into a fully clickable malicious link.
Here’s exactly how it happened.
How Does a Website Actually Get to Your Screen?
When you type a URL and hit enter, here’s what happens:
- Your browser (Chrome, Firefox, Safari) sends a request
- A server — a dedicated computer somewhere — receives that request and processes it
- The server sends back a response, and your browser renders it as a webpage
Every website is built from two halves:
- Frontend — what you see and interact with in the browser
- Backend — the server-side logic that processes requests and generates responses
The Three Pillars: HTML, CSS, JavaScript
Language Job HTML Defines the structure — headings, paragraphs, buttons, images CSS Makes it look good — colors, fonts, layout JavaScript Makes it interactive — click events, dynamic updates
HTML — The Skeleton
HTML is built from elements (tags). A basic page looks like this:
<!DOCTYPE html>
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Welcome</h1>
<p>This is a paragraph.</p>
</body>
</html><!DOCTYPE html>tells the browser this is an HTML5 document<html>is the root — everything else lives inside it<head>holds metadata (like the page title)<body>holds everything actually visible in the browser
Elements can also have attributes — extra information attached to them:
<p id="example"> <!-- unique identifier -->
<img src="img/cat.jpg"> <!-- where the image file is -->
<p class="bold-text"> <!-- styling hook for CSS -->JavaScript — The Behavior
Without JavaScript, a webpage is completely static — no clicking, no dynamic updates, nothing reacts to you. JavaScript changes that.
It can be added two ways:
<!-- Directly inline -->
<script>
document.getElementById("demo").innerHTML = "Hack the Planet";
</script><!-- Or as an external file -->
<script src="/location/of/javascript_file.js"></script>HTML elements can also trigger JavaScript through events:
<button onclick='document.getElementById("demo").innerHTML = "Button Clicked";'>
Click Me!
</button>In the room’s practical task, I used this exact technique to dynamically change a page element’s text to “Hack the Planet” just by writing a single line of JavaScript. Small task, but it’s the same mechanism behind every dynamic feature on modern websites — and, as I was about to learn, the same mechanism behind a major class of vulnerabilities.
Sensitive Data Exposure — The First Thing Every Security Researcher Checks
Before even thinking about complex attacks, the room taught a simple but powerful lesson: always check the page source code.
Sensitive Data Exposure happens when a website fails to properly hide sensitive information in its frontend code. This could be:
- Login credentials accidentally left in comments
- Hidden API keys
- Unlinked admin pages referenced in the HTML
This is why viewing a page’s source (Ctrl+U in most browsers) is one of the very first steps in any web security assessment. Developers sometimes forget that "frontend" doesn't mean "hidden" — anyone can view it instantly.
HTML Injection — Where Theory Became an Actual Exploit
This is the part where things got genuinely interesting.
The Setup
The room presented a simple webpage with a “What’s your name?” input field. You’d type your name, and the page would greet you — something like “Hello, [your name]!”
Behind the scenes, the JavaScript was taking whatever you typed and inserting it directly into the page’s HTML content.
The Vulnerability
Here’s the critical flaw: the website never sanitised the input. It took whatever I typed, completely as-is, and inserted it into the page’s HTML.
This means the browser didn’t see my input as plain text — it interpreted it as actual HTML code.
The Exploit
Instead of typing a normal name, I entered:
<a href="http://hacker.com">click here</a>
Clickable link(malicious Link)
The result? Instead of the page displaying my “name” as literal text like <a href="http://hacker.com">click here</a>, the browser rendered it as a real, fully functional, clickable hyperlink — exactly as if the website's own developer had placed it there.
This is HTML Injection — a vulnerability where unfiltered user input gets rendered directly on the page, allowing an attacker to inject their own HTML.
Why This Is Dangerous
In a real-world scenario, this single flaw could be weaponized to:
- Insert a fake “Verify your account here” link that actually leads to a phishing site
- Deface the appearance of a legitimate page
- Combine with JavaScript injection to escalate into a full Cross-Site Scripting (XSS) attack — which can steal cookies, session tokens, or redirect users entirely
The scary part is how simple the attack was. No advanced tools, no complex payloads — just understanding that the input field trusted me completely.
The Golden Rule of Web Security
Never trust user input.
Every text field, URL parameter, comment box, or search bar is a potential entry point for injection — unless the application properly sanitises (filters dangerous characters) and encodes (converts special characters to safe equivalents) the data before displaying it back to anyone.
Why This Matters for My Offensive Security Journey
This room connected dots I’d only partially understood before. I already knew SQL Injection and XSS were dangerous — but I hadn’t seen, hands-on, how the exact same root cause — unsanitised user input — powers multiple different vulnerability classes:
- HTML Injection → inject fake content/links (what I did today)
- XSS → inject and execute JavaScript
- SQL Injection → inject malicious database queries
They’re all variations on the same theme: a website trusts input it should never have trusted.
Key Takeaways
- Websites = Frontend (HTML/CSS/JS) rendering + Backend (server logic)
- HTML defines structure, CSS handles style, JavaScript adds behavior
- Viewing page source is the first move in any security assessment
- HTML Injection occurs when user input is rendered without sanitisation
- I successfully injected a clickable malicious link through an unprotected input field
- This same flaw, taken further, leads directly into XSS attacks
- The fix is always the same: sanitise and encode user input — never trust it blindly
메타데이터
- post_id
- aada50600f95
- slug
- i-turned-a-whats-your-name-field-into-a-malicious-link-my-first-html-injection-aada50600f95
- url
- https://medium.com/@rajprashantwork/i-turned-a-whats-your-name-field-into-a-malicious-link-my-first-html-injection-aada50600f95
- canonical_url
- https://medium.com/@rajprashantwork/i-turned-a-whats-your-name-field-into-a-malicious-link-my-first-html-injection-aada50600f95
- author_url
- https://medium.com/@rajprashantwork
- status
- ok
- fetched_at
- 2026-06-27 10:07:59
