Web applications are interactive programs that run inside web browsers. Built on a client-server model, they combine a front end (what users see and interact with) with a back end (the server logic, databases, and APIs that power functionality). This architecture gives organizations the ability to deliver powerful, dynamic services that are globally accessible — from email and online shopping to real-time collaboration tools.
Client vs Server: The Two Sides of a Web App
Client (front end)
- Runs in the user’s browser (Chrome, Firefox, Safari).
- Responsible for the interface, layout, and user interaction.
- Typically built with HTML, CSS, and JavaScript or frameworks like React, Vue, or Angular.
- Example responsibilities: rendering pages, validating form input in the browser, showing notifications.
Server (back end)
- Runs on remote machines (web servers, application servers).
- Hosts application logic, business rules, and persistent data (databases).
- Built with languages and frameworks such as Python/Django, Node.js/Express, Ruby on Rails, Java/Spring, PHP/Laravel, etc.
- Example responsibilities: authenticating users, processing payments, storing/retrieving records, enforcing access control.
The client sends requests (usually HTTP/HTTPS) to the server; the server responds with data (HTML, JSON, images, files). This request–response loop is the heartbeat of web applications.
Why Web Apps Are Everywhere
A few reasons for their ubiquity:
- Accessibility: Users only need a browser — no special installation required.
- Centralized updates: Developers update servers and users get the latest version immediately.
- Platform independence: Web apps run across operating systems and device types (desktop, tablet, mobile).
- Scalability: With cloud hosting, services can scale to millions of users (examples: Gmail, Amazon, Google Docs).
Because of these advantages, anyone (from a solo developer to a tech giant) can build and host web applications. That’s why millions of web apps exist and billions of users interact with them daily.
Real-World Examples
- Email as a web app: Gmail — client UI in the browser, server processes mail storage, search, spam filtering.
- E-commerce: Amazon — product pages, cart/session management, payment processing, inventory databases.
- Real-time collaboration: Google Docs — low-latency collaboration, document sync, access control.
(Example dashboard snippet: a site dashboard may show activity metrics such as “932 online players, 1032 machine owns, 622 challenge owns,” and recent targets — typical of interactive platforms that report live stats to users and admins.)
Common Technologies & Protocols
- HTTP / HTTPS: The transport protocol for most web traffic; HTTPS adds TLS encryption for confidentiality and integrity.
- REST / GraphQL / WebSockets: API styles for exchanging data; WebSockets enable persistent two-way real-time communication.
- Databases: Relational (PostgreSQL, MySQL) or NoSQL (MongoDB, Redis) for storing data.
- CDNs & Caching: Content delivery networks and caches speed up static assets and reduce server load.
- Cloud/Hosting Platforms: AWS, GCP, Azure, DigitalOcean, and managed hosting make deployment and scaling easier.
Security & Operational Considerations
Because web apps are exposed to the public internet, they bring specific security and operational challenges:
- Confidentiality & Integrity: Always prefer HTTPS to prevent eavesdropping and tampering.
- Authentication & Authorization: Properly design login flows, session handling, and role controls.
- Input Validation & Injection Defenses: Protect against SQL injection, XSS, CSRF, and similar attacks.
- Rate Limiting & DDoS Protection: Prevent abuse and service outages.
- Monitoring & Observability: Logs, metrics, and alerting are critical to detect outages and incidents.
These considerations are why secure development practices, penetration testing, and ongoing monitoring are essential parts of the web app lifecycle.
When Anyone Can Build One — Pros and Cons
Pros:
- Fast innovation — new ideas can be deployed quickly.
- Wide reach — global users without client installs.
Cons:
- Attack surface grows — more apps online mean more potential vulnerabilities.
- Quality variance — not every developer follows best practices for security, privacy, or scalability.
Key Takeaways
- A web application is a client-server program where the browser (client) interacts with backend servers to deliver functionality.
- Web apps are popular because they’re accessible, updateable, and platform-independent.
- They rely on HTTP/HTTPS, APIs, databases, and hosting infrastructure to operate at scale.
- Security, monitoring, and correct architecture are essential — especially because anyone can publish a web app.
- Real-world examples (Gmail, Amazon, Google Docs) show the range: from simple pages to complex, real-time collaborative systems.
HTML
When you open a website, what you’re really looking at is a combination of different front-end technologies. At the very core of these is HTML (HyperText Markup Language). HTML is the backbone of web content — defining structure, layout, and the essential elements that a browser interprets to render a page.
Whether you’re filling out a form, reading an article, or clicking an image, you’re interacting with HTML in some way.
What is HTML?
HTML is a markup language used to describe the structure of web pages. Unlike programming languages, HTML doesn’t “compute” or perform logic. Instead, it organizes content into elements (titles, headings, paragraphs, images, links, forms, etc.) and tells the browser how to display them.
Think of it as the blueprint of a building:
- The structure (walls, doors, windows) = HTML
- The style (paint, colors, furniture) = CSS
- The functionality (electricity, interactivity, automation) = JavaScript
Without HTML, there would be no foundation for styles or scripts to act upon.
Anatomy of an HTML Document
Every HTML document follows a structure. Let’s walk through the simplest example:
<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>
<h1>A Heading</h1>
<p>A Paragraph</p>
</body>
</html>
Breaking it Down
<!DOCTYPE html>
Declares the document type and version (HTML5 in this case). It tells the browser, “this is an HTML page.”<html>...</html>
The root element — everything inside belongs to the HTML document.<head>...</head>
Contains metadata about the page (not visible to the user), such as the title, character set, linked CSS stylesheets, or JavaScript files.<title>sets the title shown in the browser tab.
<body>...</body>
Holds everything the user actually sees in the browser window.<h1>defines a heading.<p>defines a paragraph of text.
Why HTML Matters
- Universal Standard – Every browser understands it.
- Accessibility – Screen readers rely on HTML structure to help visually impaired users.
- SEO (Search Engine Optimization) – Search engines crawl and index HTML tags like headings, alt text, and metadata.
- Foundation for Front-End Development – CSS and JavaScript are layered on top of HTML, but HTML remains the skeleton.
Expanding on the Basics
The example above is the bare minimum, but HTML offers dozens of elements for richer pages:
- Links:
<a href="https://example.com">Click Me</a> - Images:
<img src="image.jpg" alt="Description"> - Lists:
<ul> <li>First item</li> <li>Second item</li> </ul> - Forms:
<form>,<input>,<button>for gathering user input.
These building blocks combine to create anything from a static blog post to a complex, interactive web application.
Key Takeaways
- HTML is the foundation of all web pages — it defines the structure, not the style or behavior.
- Every HTML document has the same skeleton:
<!DOCTYPE>,<html>,<head>, and<body>. - Elements like headings, paragraphs, links, and images form the content users interact with.
- Without HTML, there would be no framework for CSS and JavaScript to enhance.
What is the HTML tag used to show an image?
The HTML tag used to display an image is img. It references the image source using the src attribute and can include other attributes like alt, width, and height to control its display.
Cascading Style Sheets (CSS)
CSS (Cascading Style Sheets) is the styling language used together with HTML to control the appearance and layout of web pages. Just as HTML has evolved over time, CSS also exists in different versions, with each update introducing new styling options and features that browsers gradually adopt to ensure compatibility.
Example
At its core, CSS allows you to define how specific HTML elements or groups of elements should look. For instance, you can apply styles to tags like <body> or <h1> so that all elements of that type follow the same design rules. These styles can cover aspects such as font type, text size, background color, text alignment, and more.
body {
background-color: black;
}
h1 {
color: white;
text-align: center;
}
p {
font-family: helvetica;
font-size: 10px;
}
As noted earlier, developers often assign unique IDs or class names to HTML elements. This practice makes it possible to target those elements later in CSS or even within JavaScript, enabling more precise control over the page’s design and functionality.
What is the CSS “property: value” used to make an HTML element’s text aligned to the left?
The CSS property and value used to align text to the left is text-align: left. This ensures that the content within the element starts from the left edge of its containing box.
Sensitive Data Exposure
All front-end elements we discussed run in the user’s browser (client-side). Because they execute on the client, vulnerabilities in these components don’t usually directly compromise the application’s server-side core or cause permanent server damage. However, client-side flaws put end users at risk: an exploited front-end vulnerability can target administrative users and potentially lead to unauthorized access, disclosure of sensitive information, service interruptions, and other serious outcomes.
While most web-application pentests concentrate on back-end systems and their logic, it’s equally important to examine front-end components for weaknesses. In some cases, an attacker who exploits a front-end issue can pivot to sensitive functionality—such as an admin interface—and ultimately compromise the whole server environment.
Sensitive Data Exposure describes situations where confidential information appears in clear text on the client side. This typically shows up in a page’s HTML source or in front-end assets, not in the server-side code (which remains on the server). You can inspect a website’s source by right-clicking and selecting “View Page Source,” or by pressing Ctrl+U. Even if right-click is disabled, you can still view the source (for example, via browser shortcuts or by using a proxy tool like Burp Suite). For instance, opening view-source:https://www.google.com/ reveals the page’s HTML, embedded JavaScript, and references to external resources—take a moment to scan it if you haven’t before.
Occasionally you’ll discover login credentials, password hashes, or other sensitive items tucked into HTML comments or external JavaScript files. You might also find exposed links, directories, or user data. Any of these revelations can be used to escalate access within the application or against supporting infrastructure (web servers, databases, etc.).
Because of this, one of the first steps in a web-application assessment should be to review the page source for obvious weaknesses or “low-hanging fruit” (for example, exposed credentials or hidden links) that could accelerate further exploitation.
Check the above login form for exposed passwords. Submit the password as the answer.
Open the page
Press Ctrl + U to see the code of the page and get the password
}
button {
background-color: #2A86FF;
color: white;
padding: 14px 20px;
margin: 8px 0;
border: none;
cursor: pointer;
width: 100%;
border-radius: 10px;
}
button:hover {
opacity: 0.8;
}
.container {
padding: 16px;
}
</style>
</head>
<body>
<form action="#" method="post">
<div class="container">
<label for="uname"><b>Username</b></label>
<input type="text" required>
<label for="psw"><b>Password</b></label>
<input type="password" required>
<!-- TODO: remove test credentials [REDACTED] -->
<button type="submit">Login</button>
</div>
</form>
</body>
</html>
HTML Injection
An important part of front-end security is ensuring user input is both validated and sanitized. While input validation is often performed on the server side, many inputs are processed entirely in the browser and never reach the back end. For that reason, it’s essential to enforce validation and sanitization on both the client and the server.
HTML injection happens when untrusted input is rendered into a page without proper filtering. That can occur when previously stored content (for example, a user comment retrieved from the database) is output as-is, or when JavaScript directly inserts user-supplied data into the DOM.
If a user controls how their input is rendered, they can submit HTML that the browser will interpret. An attacker might inject a malicious form (for instance, a fake login prompt) that captures credentials and forwards them to an attacker-controlled server. This is a common phishing-style technique implemented directly on the compromised page.
HTML injection can also be used to deface web pages—altering layout and content, inserting malicious advertisements, or otherwise changing how the site appears to visitors. Such attacks can cause serious reputational harm to the organization that hosts the application.
What text would be displayed on the page if we use the following payload as our input: <a href=”http://www.hackthebox.com”>Click Me</a>
Open the page and click on the “Click to enter your name” button
In the popup copy the payload bellow
<a href="http://www.hackthebox.com">Click Me</a>
Click on OK button and get the text.
Cross-Site Scripting (XSS)
HTML injection flaws can often be escalated into Cross-Site Scripting (XSS) attacks by inserting JavaScript that runs in the victim’s browser. When an attacker is able to execute script on a user’s machine, they may be able to hijack that user’s session or even compromise the device. In practice XSS closely resembles HTML injection, but with a key difference: XSS injects and runs JavaScript to carry out more powerful client-side attacks rather than only inserting HTML.
There are three primary categories of XSS:
Type — Description
Reflected XSS — Happens when input from a user is immediately included in the page response (for example, in search results or error messages).
Stored XSS — Happens when malicious input is saved on the server (for example, in posts or comments) and later rendered to other users.
DOM XSS — Happens when user input is directly written into the browser’s DOM (for example, a vulnerable username or page title) so the script executes in the client.
In the HTML injection example we reviewed, the application didn’t sanitize input at all. That same lack of filtering could allow XSS on the same page. For instance, the following DOM XSS payload attempts to read the current user’s cookie and display it:
#"><img src=/ onerror=alert(document.cookie)>
After submitting this payload and confirming the action, an alert box appears showing the cookie:
(Dialog box displaying a cookie value and a ‘Close’ button.)
This payload navigates the page’s DOM to obtain document.cookie. When the browser incorporates the attacker’s input into the DOM, the injected JavaScript runs and shows the cookie value in a popup.
An attacker can use this technique to steal session cookies, exfiltrate them to a server they control, and then try to reuse those cookies to impersonate the victim. Similar XSS vectors can enable many other attacks against a web app’s users. XSS is a broad subject and will be explored in much greater detail in later modules.
Try to use XSS to get the cookie value in the above page
Open the page and click on the “Click to enter your name” button
Insert the payload bellow and click
#"><img src=/ onerror=alert(document.cookie)>
Click on OK button and get the flag.
Back End Servers
A back-end server is the core component of a web application’s infrastructure, consisting of both the hardware and the operating system that run behind the scenes. Unlike the front end, which users directly interact with in their browsers, the back-end server is responsible for powering the invisible processes that keep the application functional and responsive. It hosts and executes all of the essential applications, services, and background tasks required to deliver a seamless experience to the end user.
In practice, the back-end server manages the business logic, processes user requests, enforces security controls, and communicates with the database to fetch or store information. Every time a user fills out a form, makes a purchase, or logs into an account, the back-end server is the system executing the instructions and ensuring that the data flows correctly between the interface and the storage layers.
From an architectural perspective, the back-end server belongs to the Data Access Layer (DAL) of the software stack. This layer acts as the intermediary between the business logic and the database, handling queries, transactions, and ensuring data integrity. By fitting into this layer, the back-end server plays a crucial role in maintaining reliability, performance, and scalability of the entire web application.
In short, the back-end server can be thought of as the engine room of the application—it doesn’t face the user directly, but without it, none of the front-end functionality would operate.
What operating system is ‘WAMP’ used with?
WAMP is used with the Windows operating system. The acronym stands for Windows, Apache, MySQL, PHP, indicating its components and platform.
Web Servers
A web server is a specialized application that runs on the back-end server and serves as the gateway between users and the web application. Its primary role is to manage all incoming HTTP (and HTTPS) requests from client-side browsers, determine how those requests should be routed, and then deliver the appropriate response back to the client. In other words, whenever you type a URL into your browser or click on a link, the web server is the component that receives the request, processes it, and returns the correct page or resource.
Web servers typically operate over TCP port 80 for standard HTTP traffic and TCP port 443 for secure HTTPS traffic, which uses TLS/SSL encryption to protect data in transit. These two ports are the most common entry points for users on the internet, making the web server an essential piece of infrastructure in nearly every web application.
Beyond simply routing requests, modern web servers are responsible for a variety of additional tasks. They may manage session handling, load balancing, and security filtering, ensuring that requests are properly authenticated and that malicious traffic is blocked before it can reach the application. Many web servers can also serve static files—such as images, stylesheets, or JavaScript files—directly to the client, reducing the load on the rest of the system.
By acting as the intermediary, the web server ensures that end users are seamlessly connected to the correct parts of the application, whether that means displaying a simple homepage, processing a login request, or pulling dynamic content from a database. Without the web server coordinating these interactions, the communication between the client-side browser and the back-end services would not be possible.
If a web server returns an HTTP code 201, what does it stand for?
An HTTP status code 201 indicates Created. It means the server has successfully fulfilled a request, typically a POST, and a new resource has been created as a result.
Databases
Web applications rely heavily on back-end databases to store and manage the vast amount of content and information required to keep the application running. These databases act as the foundation for data persistence, ensuring that information remains available even after users log out or servers restart. The stored data can take many forms:
- Core assets such as images, documents, or downloadable files that support the application’s functionality.
- Application content like blog posts, comments, messages, and updates that provide value to users.
- User data including sensitive details such as usernames, hashed passwords, email addresses, and profile information, which enable authentication and personalization features.
This ability to store and retrieve data quickly allows web applications to deliver dynamic, personalized content—meaning that two users visiting the same page might see entirely different information depending on their accounts, preferences, or past activity. Without a database, web applications would be limited to static content, offering the same experience to everyone.
There are many types of databases, each designed with specific use cases in mind. For example, relational databases like MySQL and PostgreSQL organize data in tables with strict relationships, making them ideal for structured information such as financial transactions or customer records. On the other hand, NoSQL databases such as MongoDB or Redis offer more flexibility, handling unstructured or semi-structured data like logs, JSON documents, or real-time session information.
When selecting a database, developers consider several key characteristics:
- Speed in storing, indexing, and retrieving data efficiently.
- Capacity to handle large-scale datasets, sometimes reaching terabytes or petabytes.
- Scalability, ensuring the database can grow as the web application’s user base expands.
- Cost, both in terms of licensing fees and infrastructure resources needed to support it.
Ultimately, the database chosen shapes how well a web application performs under pressure, scales with growth, and safeguards user data.
What type of database is Google’s Firebase Database?
Google’s Firebase Database is a NoSQL database. It stores data in a flexible, JSON-like format, allowing real-time synchronization across clients and scalable cloud storage.
Development Frameworks & APIs
In addition to web servers that can host applications written in different programming languages, developers often rely on web development frameworks to simplify and accelerate the process of building modern web applications. Frameworks provide pre-built structures, libraries, and tools that make it much easier to develop the core application files and implement complex functionality without having to reinvent the wheel.
As web applications have become increasingly sophisticated—with features such as authentication, authorization, data validation, and API integration—it has become far more challenging to build them entirely from scratch. For this reason, many of today’s most popular applications are developed with the help of well-established frameworks.
One of the main benefits of frameworks is that they provide ready-made solutions for common functionality. For example, almost every application needs features like user registration, login systems, form handling, and session management. Rather than writing this code from the ground up, developers can leverage framework components that are already secure, tested, and optimized. This not only speeds up development but also reduces the risk of introducing vulnerabilities. By linking these framework-provided features with front-end components, developers can rapidly build fully functional, production-ready applications.
Some of the most widely used frameworks include:
- Laravel (PHP): Known for its elegant syntax and ease of use, Laravel is a popular choice among startups and small to mid-sized companies. It provides tools for routing, authentication, and database management, making PHP development faster and more manageable.
- Express (Node.js): Lightweight and flexible, Express is widely adopted in large-scale applications. Companies like PayPal, Yahoo, Uber, IBM, and MySpace use it for building fast, scalable server-side applications in JavaScript.
- Django (Python): Famous for its “batteries-included” philosophy, Django offers a wide set of built-in tools and emphasizes security and rapid development. It has powered some of the largest platforms in the world, such as Google, YouTube, Instagram, Mozilla, and Pinterest.
- Ruby on Rails (Ruby): Rails revolutionized web development with its convention-over-configuration approach, helping developers build applications quickly. It has been used by GitHub, Hulu, Twitch, Airbnb, and even Twitter in its early years.
It’s also important to note that most large-scale websites do not rely on a single framework or web server. Instead, they often combine multiple frameworks, languages, and servers to optimize different parts of their applications. For instance, a company might use Django for core backend functionality, Express for APIs, and Laravel for managing a specific service. This multi-framework approach allows organizations to balance performance, scalability, and maintainability.
Use GET request ‘/index.php?id=0’ to search for the name of the user with id number 1?
Open the address on your browser
http://94.237.61.157:35773/index.php?id=0
Change the id value from 0 to 1 and get the flag
Common Web Vulnerabilities
When conducting a penetration test on a web application—whether it is an internally developed system or a widely used public application—we may encounter vulnerabilities even if no publicly known exploits exist for that specific application. In such cases, the testing process becomes more manual and exploratory, requiring the pentester to carefully analyze the application’s code behavior, user input handling, and business logic.
One of the most common scenarios is identifying vulnerabilities introduced by misconfigurations. These types of issues can exist even in large, publicly available applications that otherwise appear secure. Unlike coding flaws, which are tied directly to the application itself, misconfigurations often stem from improper setup decisions made by developers or system administrators. Examples include leaving debug modes enabled, using default credentials, exposing unnecessary services, or failing to properly configure access control rules. Such oversights can unintentionally provide attackers with a foothold into the system.
During testing, it is not unusual to find a mix of both custom vulnerabilities (introduced through unique code logic) and configuration-based flaws. For instance, a pentester might uncover:
- An insecure API endpoint that was overlooked because it was considered “internal only.”
- Improper error handling that reveals sensitive information about the server environment.
- Misconfigured permissions that allow unauthorized users to access admin-level functionality.
To better understand and categorize these issues, security professionals often refer to the OWASP Top 10, a community-driven standard that highlights the most critical web application security risks. This framework provides a foundation for identifying the most common and impactful vulnerabilities across different types of web applications, regardless of whether they are custom-built or widely distributed.
Some of the most frequently encountered vulnerabilities from the OWASP Top 10 include:
- Injection flaws (e.g., SQL Injection, Command Injection).
- Broken Authentication and session management.
- Sensitive Data Exposure through weak encryption or improper handling.
- Security Misconfigurations such as open S3 buckets or default admin interfaces.
- Cross-Site Scripting (XSS), which allows attackers to inject malicious scripts into web pages viewed by other users.
By systematically testing for these and other OWASP Top 10 vulnerabilities, penetration testers can provide valuable insight into both coding issues and operational weaknesses, helping organizations strengthen their overall security posture.
To which of the above categories does public vulnerability ‘CVE-2014-6271’ belongs to?
The public vulnerability CVE-2014-6271 belongs to the Command Injection category. This vulnerability, also known as “Shellshock,” allows attackers to execute arbitrary commands on a vulnerable system via crafted environment variables.
Public Vulnerabilities
The most critical back-end component vulnerabilities are those that can be reached from outside the network and abused to gain control of the back-end server without any prior local access (i.e., during an external penetration test). These flaws typically stem from coding errors or insecure design decisions made while building the application’s server-side components. Because server-side code handles sensitive operations — database queries, file handling, authentication, and inter-service communication — mistakes here can lead to high-impact compromises.
There is a broad spectrum of vulnerability types in this area. On the simpler end are issues that are often straightforward to find and exploit, such as SQL injection, unsafe file uploads, or weak authentication and session management. On the more advanced end are complex problems that require deep understanding of the application’s internals and architecture, such as remote code execution (RCE) through insecure deserialization, server-side request forgery (SSRF) used to pivot to internal services, or chaining multiple logic flaws to elevate privileges.
Root causes commonly include inadequate input validation, improper error handling that leaks internal details, insecure default configurations, and reliance on unsafe third-party libraries. Because of the range in complexity, effective mitigation requires both basic secure-coding practices (input sanitization, least privilege, safe libraries) and advanced defenses (threat modeling, code review, automated and manual security testing, runtime protection).
What is the CVSS v2.0 score of the public vulnerability CVE-2017-0144?
The CVSS v2.0 score of the public vulnerability CVE-2017-0144 is 9.3. This high score reflects its critical severity, indicating the vulnerability can lead to significant impact if exploited.