Just getting started with web hacking? This TryHackMe lab is the perfect intro! Learn how web apps communicate through HTTP, how URLs are structured, what request methods like GET and POST do, and how to decode response codes and headers. This is foundational knowledge every cybersecurity learner needs.
TryHackMe Web Application Basics Description
Learn the basics of web applications: HTTP, URLs, request methods, response codes, and headers.
Web Application Overview
Front End: The Face of the Web
Think of the Front End of a web application like the surface of a planet—the part an astronaut can actually see and interact with, shaped by the natural laws around it. For users, this interaction happens through technologies like HTML, CSS, and JavaScript.
HTML – The Basic Structure
Visual: A lifeless gray planet, bare and unmoving.
HTML (Hypertext Markup Language) acts as the building blocks of a webpage. It tells your browser what to display, headings, text, images, links, but nothing fancy. It’s like the DNA of simple life forms: it holds the basic instructions, but not much personality or flair.
CSS – Adding Style and Beauty
Visual: The same planet now vibrant and colorful with textures, patterns, and lush landscapes.
CSS (Cascading Style Sheets) is what brings the webpage to life visually. It defines colors, fonts, spacing, and layouts, basically, how everything looks. If HTML is the DNA, CSS is the part that describes appearance, like eye color, shape, and size in an organism.
JavaScript – Bringing It to Life
Visual: A planet that now moves, responds, and adapts, animated with intelligent behavior.
JavaScript (JS) introduces interactivity and logic. It makes the page dynamic, handling clicks, form submissions, animations, and more. In our planet metaphor, JavaScript is the brain of the organism, making decisions and responding to the environment in real time.
Back End: The Hidden Machinery
Now let’s look beneath the surface, the Back End, where all the behind-the-scenes magic happens. You can’t see it in the browser, but it’s what makes everything work, like the gravity holding everything in place or the air you breathe.
Databases – Storing the Knowledge
Visual: A thriving ecosystem, forests, rivers, libraries, and data-rich landscapes.
Databases store, update, and retrieve information. Whether it’s your login credentials or a user’s preferences, it all lives here. Imagine a planet where intelligent life keeps maps, diaries, books, and files neatly stored for reference and use, just like a database does for a website.
Infrastructure – The Foundations and Highways
Visual: Interconnected roads, tunnels, power lines, and flowing traffic systems.
A web application runs on a mix of servers, storage, and network systems, the infrastructure. Think of it like a planet’s transportation and energy systems: the roads (network), cars (data), and the fuel (processing power) that keep everything running smoothly.
WAF – The Planet’s Protective Shield
Visual: A glowing ozone layer surrounding the planet, shielding it from harmful rays.
The Web Application Firewall (WAF) acts like the atmosphere of your digital planet. It filters out harmful traffic and blocks potential threats before they can reach your server. Just as a planet’s atmosphere protects life from radiation, the WAF defends your app from cyber attacks.
Uniform Resource Locator
A URL isn’t just a web address, it’s a collection of parts that work together to get you to the right place on the internet. Whether you’re browsing, building websites, or troubleshooting issues, understanding these parts can really help.
1. Scheme (Protocol)
The scheme tells your browser how to connect to a website. You’ll most often see:
http:// – HyperText Transfer Protocol
https:// – Secure version with encryption
Why it matters: HTTPS is the safer option. It encrypts your connection, keeping your data private. That’s why modern websites, and cybersecurity professionals, prefer and enforce HTTPS.
2. User Info (Optional)
Some URLs may include login details (usually a username, sometimes a password). For example: https://username@website.com
Why it matters: This method is outdated and risky. Exposing credentials in URLs can lead to serious security issues. Most sites now avoid this.
3. Host / Domain
This is the core of the URL—it tells your browser which site to visit. Example: example.com
Why it matters: Domains are unique and registered officially. Watch out for: Slightly misspelled domains used in phishing (called typosquatting), like g00gle.com.
4. Port
A port tells the browser which service on the server to talk to. You might not see it unless it’s non-standard, like:
:80 – Default for HTTP
:443 – Default for HTTPS
Why it matters: Different ports serve different purposes, and knowing which port is being used can help diagnose or secure connections.
5. Path
This points to a specific file or page on the website. For example: /about/contact.html
Why it matters: It tells the server exactly what you’re trying to reach. For secure websites, paths must be protected to avoid exposing sensitive resources.
6. Query String
This part starts with a question mark (?) and carries data like search terms or form inputs: ?search=cybersecurity
Why it matters: Since users can modify query strings, websites must validate and sanitize them to prevent injection attacks or data leaks.
7. Fragment
This begins with a hash (#) and jumps to a specific section of a page, like: #section2
Why it matters: It enhances navigation but can also be misused. Just like query strings, any data here should be handled carefully to avoid vulnerabilities.
HTTP Messages: Requests and Responses
Whenever you interact with a website or web app, a conversation happens behind the scenes, and it’s all based on HTTP messages. These messages come in two main types:
HTTP Request ; Sent from the user (client) to the server to ask for something (like loading a page or submitting a form).
HTTP Response ; Sent from the server back to the user with the requested information or result.
Both types follow a specific structure that keeps communication clear and reliable.
1. Start Line
Think of the start line as the “subject line” of a message. It introduces what kind of message it is (a request or a response) and includes key details about how it should be processed.
In a request, it includes the HTTP method (GET, POST, etc.), the path, and the protocol version.
In a response, it includes the protocol version and a status code (like 200 OK or 404 Not Found).
2. Headers
Headers are like helpful notes included with the message. They come in key-value pairs and provide important context for how the message should be handled.
Examples:
Content-Type: application/json
Authorization: Bearer token_here
Cache-Control: no-cache
They manage everything from security and data type to browser behavior.
3. Empty Line
This might seem minor, but the empty line is crucial. It marks the end of the headers and the beginning of the body. Without this clear divider, the client or server wouldn’t know where one part ends and the other begins, leading to potential errors in communication.
4. Body
The body contains the actual content:
In a request, it might include form inputs, file uploads, or JSON data sent by the user.
In a response, it holds the content sent back from the server, like HTML for a web page or data from an API.
Why This Matters
Understanding how HTTP messages work isn’t just for developers—it’s useful for anyone working with web applications. Here’s why:
Better Debugging: If something breaks, you can read the messages to see where things went wrong.
Improved Performance: Clean, properly structured messages make apps faster and more reliable.
Stronger Security: Knowing how data is transmitted helps you secure it with techniques like input validation, HTTPS, and proper headers.
HTTP Requests
An HTTP request is the message your browser (or any client) sends to a web server to do something, like loading a page, submitting a form, or logging in. Since it’s often the very first point of contact between a user and a web application, understanding how it works is crucial, especially if you’re working in cybersecurity.
Anatomy of an HTTP Request
Let’s break it down. A typical HTTP request includes:
Method: What action you’re trying to perform (e.g., GET, POST)
Path: Where you’re trying to go (e.g., /login)
Version: Which HTTP protocol is being used (e.g., HTTP/1.1)
Example:
POST /login HTTP/1.1
Request Line
The request line is the first part of every HTTP request. It has three components:
HTTP Method
URL Path
HTTP Version
Let’s take a closer look at these.
Common HTTP Methods (and Their Security Concerns)
Method
Purpose
Security Reminder
GET
Retrieves data
Never include sensitive data (like tokens or passwords) in the URL, it can be exposed in logs, browser history, or referrers.
POST
Sends data (e.g., form submission)
Always sanitize and validate input to protect against XSS and SQL injection.
PUT
Replaces a resource
Ensure users are authorized before allowing changes.
DELETE
Removes a resource
Just like PUT, enforce strict authorization checks.
Other HTTP Methods You Might See
Method
What It Does
Notes
PATCH
Partially updates a resource
Great for small edits, but data still needs validation.
HEAD
Retrieves only headers (no body)
Useful for checking metadata without downloading the content.
OPTIONS
Lists allowed methods for a resource
Informational, but can reveal too much if not handled securely.
TRACE
Echoes back the request
Can be abused for attacks like Cross-Site Tracing (XST); best to disable.
CONNECT
Establishes secure tunnels
Often used in HTTPS; essential for encrypted sessions.
URL Path
The path in a request tells the server what resource is being requested. For example:
https://tryhackme.com/api/users/123
The path is /api/users/123, which could refer to a specific user in the system.
Security Tips:
Validate the path to ensure it only accesses allowed resources.
Sanitize the path to prevent injection attacks.
Protect sensitive routes with proper access control and audits.
HTTP Version
The HTTP version defines the protocol used between the client and the server. Here’s a quick overview:
Version
Highlights
HTTP/0.9 (1991)
Only supported simple GET requests.
HTTP/1.0 (1996)
Introduced headers and MIME support.
HTTP/1.1 (1997)
Added persistent connections and caching. Still widely used today.
HTTP/2 (2015)
Brought multiplexing and compression for better speed and efficiency.
HTTP/3 (2022)
Uses QUIC instead of TCP for faster, more secure connections.
Why it matters: Upgrading to HTTP/2 or HTTP/3 can dramatically boost both performance and security—but many systems still use HTTP/1.1 for compatibility.
Understanding HTTP Request Headers and Body
When a client (like your browser) sends a request to a web server, it doesn’t just say “give me this page”, it often includes extra details. These are sent through HTTP Request Headers and, in some cases, a Request Body.
Common HTTP Request Headers
Request headers give the server useful context about the request, like who’s making it, what browser they’re using, or where they came from.
Header
Example
What It Does
Host
Host: tryhackme.com
Tells the server which website is being requested.
User-Agent
User-Agent: Mozilla/5.0
Identifies the browser or tool making the request.
Sends data stored in cookies, often used for session tracking or personalization.
Content-Type
Content-Type: application/json
Specifies the format of the data being sent in the request body (e.g., JSON, form data).
HTTP Request Body: Sending Data to the Server
Not all requests have a body, but when you’re sending data (like in a POST or PUT request), the body contains that content. Depending on how the data is structured, it can be formatted in several ways:
1. URL Encoded Data
Content-Type: application/x-www-form-urlencoded
This format is commonly used in basic web forms. Data is sent as key-value pairs joined by &, with special characters encoded.
Example:
POST /profile HTTP/1.1 Host: tryhackme.com Content-Type: application/x-www-form-urlencoded Content-Length: 33
name=Aleksandra&age=27&country=US
2. Form Data (File Uploads)
Content-Type: multipart/form-data
Used for forms that send files or other binary content. Each part of the form is separated by a boundary string.
Example:
POST /upload HTTP/1.1 Host: tryhackme.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Understanding headers and body formats is essential for:
Security ; Certain headers and body formats can be exploited if not validated properly.
Debugging ; Knowing how data is structured helps in identifying problems.
Web Development ; Choosing the right data format ensures smooth client-server communication.
Whether you’re building a web app or securing one, this knowledge is foundational to working with HTTP.
HTTP Responses
The Status Line in HTTP Responses
The very first line in an HTTP response is called the Status Line, and it delivers three important details:
HTTP Version ; The version of the HTTP protocol being used.
Status Code ; A 3-digit number that shows the outcome of the request.
Reason Phrase ; A short message that describes the status code in plain language.
Since we’ve already talked about HTTP versions, let’s focus here on the status codes and what they mean.
Status Codes & Their Meanings
Status codes help us understand how the server responded to a request. They’re grouped into five main categories:
1. Informational (100–199)
These codes mean the server received part of the request and is waiting for more. Think of it as a “hold on, I’m listening” response.
2. Success (200–299)
Everything worked! The request was processed successfully, and the server is sending back what was asked for.
3. Redirection (300–399)
The resource has moved to another location. The server usually provides a new URL where the content can be found.
4. Client Errors (400–499)
There’s a problem with the request—maybe something’s missing, the URL is wrong, or you’re not allowed to access it.
5. Server Errors (500–599)
The issue is on the server’s side. The request might have been valid, but the server failed to complete it due to internal problems.
Common Status Codes You’ll Encounter
Code
Message
What It Means
100
Continue
The server got the first part of your request and is ready for the rest.
200
OK
Everything went smoothly—the request was successful.
301
Moved Permanently
The resource has a new permanent URL. Update your links.
404
Not Found
The requested page or resource doesn’t exist at that URL.
500
Internal Server Error
Something broke on the server. It’s not your fault.
Why It Matters
Understanding these status codes helps you:
Troubleshoot issues more easily
Secure your app by handling errors properly
Optimize how clients and servers communicate
HTTP Response Headers & Body: What They Do and Why They Matter
When a server replies to a request, it sends back an HTTP response. This response includes headers and a body, each playing a key role in how the client (usually a browser) handles the response.
Essential Response Headers
These headers are critical for the browser and server to understand the response properly and act accordingly.
Header
Example
Purpose
Date
Date: Fri, 23 Aug 2024 10:43:21 GMT
Shows when the response was created. Helps with caching and debugging.
Content-Type
Content-Type: text/html; charset=utf-8
Tells the browser what type of content it’s receiving (HTML, JSON, etc.) and how to properly interpret it using the specified character set.
Server
Server: nginx
Reveals what web server software handled the request. Useful for diagnostics, but can leak info to attackers, often masked or removed in production.
Other Useful Response Headers
These headers aren’t strictly required but are commonly used to guide client behavior or improve performance and security.
Header
Example
Purpose & Notes
Set-Cookie
Set-Cookie: sessionId=38af1337es7a8
Sends a cookie to be stored in the browser. Make sure to use HttpOnly (prevents JavaScript access) and Secure (ensures it’s only sent over HTTPS) flags for security.
Cache-Control
Cache-Control: max-age=600
Tells the browser how long to cache the response. Use no-cache or no-store for sensitive data to prevent it from being saved locally.
Location
Location: /index.html
Used in redirects (3xx responses). Directs the client to a new URL. Make sure this value is validated to prevent open redirect vulnerabilities.
HTTP Response Body
The response body is where the actual content lives—whether it’s:
A full HTML page
A JSON object from an API
An image or file
Or any other data returned by the server
Security Tip: If your application includes user-generated content in the response, sanitize and escape it properly. This helps prevent injection attacks like Cross-Site Scripting (XSS).
HTTP Security Headers: Strengthening Your Web App’s Defenses
Security headers are HTTP response headers that provide an extra layer of protection for your web applications. They help mitigate common web-based attacks such as Cross-Site Scripting (XSS), clickjacking, and data leaks.
1. Content-Security-Policy (CSP)
The Content-Security-Policy header is designed to limit which content (like scripts, styles, or images) can be loaded by your web page. It’s especially useful for preventing XSS attacks, where malicious scripts are injected from external or unauthorized sources.
default-src 'self' ; Only allow content to load from the same domain.
script-src ; Scripts can be loaded from the site itself and also from https://cdn.tryhackme.com.
style-src ; CSS stylesheets can only come from the current domain.
Tip: You’ll often see directives like script-src, img-src, style-src, and more. Using 'self' restricts the content to your own domain, which tightens security.
2. Strict-Transport-Security (HSTS)
The HSTS header forces browsers to always use HTTPS instead of HTTP. This prevents downgrade attacks and keeps communication encrypted.
max-age=63072000 ; Tells the browser to enforce HTTPS for 2 years (in seconds).
includeSubDomains ; Applies the rule to all subdomains as well.
preload ; Requests inclusion in browser preload lists so HTTPS is enforced even before a user visits the site for the first time.
3. X-Content-Type-Options
This header prevents browsers from “sniffing” or guessing the MIME type of a file. Instead, the browser must strictly follow the declared Content-Type.
Example:
X-Content-Type-Options: nosniff
What it does:
nosniff ; Instructs the browser not to try and guess the file type, reducing the risk of content being misinterpreted or malicious files being executed improperly.
4. Referrer-Policy
This header controls how much referrer information (the URL of the previous page) is sent to another site when a user clicks a link.
same-origin – Sends referrer info only for links within the same domain.
strict-origin – Sends just the origin (e.g., https://example.com) if the protocol stays the same (e.g., HTTPS → HTTPS).
strict-origin-when-cross-origin – Sends the full referrer for same-origin requests, but only the origin for cross-origin requests.
Extra Tip: Analyze Your Headers
Want to check how well a site uses security headers? Use https://securityheaders.io/ ; just enter a domain, and it will scan and report on the headers being used.
Room Answers | Web Application Basics TryHackMe
Which component on a computer is responsible for hosting and delivering content for web applications?
web server
Which tool is used to access and interact with web applications?
web browser
Which component acts as a protective layer, filtering incoming traffic to block malicious attacks, and ensuring the security of the the web application?
web application firewall
Which HTTP message is returned by the web server after processing a client’s request?
HTTP response
What follows the headers in an HTTP message?
Empty Line
Which HTTP protocol version became widely adopted and remains the most commonly used version for web communication, known for introducing features like persistent connections and chunked transfer encoding?
HTTP/1.1
Which HTTP request method describes the communication options for the target resource, allowing clients to determine which HTTP methods are supported by the web server?
OPTIONS
In an HTTP request, which component specifies the specific resource or endpoint on the web server that the client is requesting, typically appearing after the domain name in the URL?
URL Path
Which HTTP request header specifies the domain name of the web server to which the request is being sent?
Host
What is the default content type for form submissions in an HTTP request where the data is encoded as key=value pairs in a query string format?
application/x-www-form-urlencoded
Which part of an HTTP request contains additional information like host, user agent, and content type, guiding how the web server should process the request?
Request Headers
What part of an HTTP response provides the HTTP version, status code, and a brief explanation of the response’s outcome?
Status Line
Which category of HTTP response codes indicates that the web server encountered an internal issue or is unable to fulfil the client’s request?
Server Error Responses
Which HTTP status code indicates that the requested resource could not be found on the web server?
404
Which HTTP response header can reveal information about the web server’s software and version, potentially exposing it to security risks if not removed?
Server
Which flag should be added to cookies in the Set-Cookie HTTP response header to ensure they are only transmitted over HTTPS, protecting them from being exposed during unencrypted transmissions?
Secure
Which flag should be added to cookies in the Set-Cookie HTTP response header to prevent them from being accessed via JavaScript, thereby enhancing security against XSS attacks?
HttpOnly
In a Content Security Policy (CSP) configuration, which property can be set to define where scripts can be loaded from?
script-src
When configuring the Strict-Transport-Security (HSTS) header to ensure that all subdomains of a site also use HTTPS, which directive should be included to apply the security policy to both the main domain and its subdomains?
includeSubDomains
Which HTTP header directive is used to prevent browsers from interpreting files as a different MIME type than what is specified by the server, thereby mitigating content type sniffing attacks?
nosniff
Make a GET request to /api/users. What is the flag?
THM{YOU_HAVE_JUST_FOUND_THE_USER_LIST}
Make a POST request to /api/user/2 and update the country of Bob from UK to US. What is the flag?
THM{YOU_HAVE_MODIFIED_THE_USER_DATA}
Make a DELETE request to /api/user/1 to delete the user. What is the flag?
Mastermind Study Notes is a group of talented authors and writers who are experienced and well-versed across different fields. The group is led by, Motasem Hamdan, who is a Cybersecurity content creator and YouTuber.
