2.

Introduction to Web Applications

Introduction

Web applications are interactive applications that run on web browsers. Web applications
usually adopt a client-server architecture to run and handle interactions. They typically have
front end components (i.e., the website interface, or "what the user sees") that run on the
client-side (browser) and other back end components (web application source code) that run
on the server-side (back end server/databases).

This allows organizations to host powerful applications with near-complete real-time control
over their design and functionality while being accessible worldwide. Some examples of
typical web applications include online email services like Gmail , online retailers like
Amazon , and online word processors like Google Docs .

Web applications are not exclusive to giant providers like Google or Microsoft but can be
developed by any web developer and hosted online in any of the common hosting services,
to be used by anyone on the internet. This is why today we have millions of web applications
all over the internet, with billions of users interacting with them every day.

Web Applications vs. Websites

In the past, we interacted with websites that are static and cannot be changed in real-time.
This means that traditional websites were statically created to represent specific information,
and this information would not change with our interaction. To change the website's content,
the corresponding page has to be edited by the developers manually. These types of static
pages do not contain functions and, therefore, do not produce real-time changes. That type
of website is also known as Web 1.0.

https://t.me/offenciveSec
On the other hand, most websites run web applications, or Web 2.0 presenting dynamic
content based on user interaction. Another significant difference is that web applications are
fully functional and can perform various functionalities for the end-user, while web sites lack
this type of functionality. Other key differences between traditional websites and web
applications include:

Being modular
Running on any display size
Running on any platform without being optimized

Web Applications vs. Native Operating System

Applications
Unlike native operating system (native OS) applications, web applications are platform-
independent and can run in a browser on any operating system. These web applications do
not have to be installed on a user's system because these web applications and their
functionality are executed remotely on the remote server and hence do not consume any
space on the end user's hard drive.

Another advantage of web applications over native OS applications is version unity. All users
accessing a web application use the same version and the same web application, which can
be continuously updated and modified without pushing updates to each user. Web
applications can be updated in a single location (webserver) without developing different
builds for each platform, which dramatically reduces maintenance and support costs
removing the need to communicate changes to all users individually.

On the other hand, native OS applications have certain advantages over web applications,
mainly their operation speed and the ability to utilize native operating system libraries and

https://t.me/offenciveSec
local hardware. As native applications are built to utilize native OS libraries, they are much
faster to load and interact with. Furthermore, native applications are usually more capable
than web applications, as they have a deeper integration to the operating system and are not
limited to the browser's capabilities only.

More recently, however, hybrid and progressive web applications are becoming more
common. They utilize modern frameworks to run web applications using native OS
capabilities and resources, making them faster than regular web applications and more
capable.

Web Application Distribution

There are many open-source web applications used by organizations worldwide that can be
customized to meet each organization's needs. Some common open source web
applications include:

WordPress
OpenCart
Joomla

There are also proprietary 'closed source' web applications, which are usually developed by
a certain organization and then sold to another organization or used by organizations
through a subscription plan model. Some common closed source web applications include:

Wix
Shopify
DotNetNuke

Security Risks of Web Applications

Web application attacks are prevalent and present a challenge for most organizations with a
web presence, regardless of their size. After all, they are usually accessible from any country
by everyone with an internet connection and a web browser and usually offer a vast attack
surface. There are many automated tools for scanning and attacking web applications that,
in the wrong hands, can cause significant damage. As web applications become more
complicated and advanced, so does the possibility of critical vulnerabilities being
incorporated into their design.

A successful web application attack can lead to significant losses and massive business
interruptions. Since web applications are run on servers that may host other sensitive
information and are often also linked to databases containing sensitive user or corporate

https://t.me/offenciveSec
data, all of this data could be compromised if a web site is successfully attacked. This is why
it is critical for any business that utilizes web applications to properly test these applications
for vulnerabilities and patch them promptly while testing that the patch fixes the flaw and
does not inadvertently introduce any new flaws.

Web application penetration testing is an increasingly critical skill to learn. Any organization
looking to secure their internet-facing (and internal) web applications should undergo
frequent web application tests and implement secure coding practices at every development
life cycle stage. To properly pentest web applications, we need to understand how they work,
how they are developed, and what kind of risk lies at each layer and component of the
application depending on the technologies in use.

We will always come across various web applications that are designed and configured
differently. One of the most current and widely used methods for testing web applications is
the OWASP Web Security Testing Guide.

One of the most common procedures is to start by reviewing a web application's front end
components, such as HTML , CSS and JavaScript (also known as the front end trinity), and
attempt to find vulnerabilities such as Sensitive Data Exposure and Cross-Site Scripting
(XSS). Once all front end components are thoroughly tested, we would typically review the
web application's core functionality and the interaction between the browser and the
webserver to enumerate the technologies the webserver uses and look for exploitable flaws.
We typically assess web applications from both an unauthenticated and authenticated
perspective (if the application has login functionality) to maximize coverage and review every
possible attack scenario.

Attacking Web Applications

In this day and age most every company, no matter the size has one or more web
applications within their external perimeter. These applications can be everything from
simple static websites to blogs powered by Content Management Systems (CMS) such as
WordPress to complicated applications with sign-up/login functionality supporting various
user roles from basic users to super admins. Nowadays, it is not very common to find an
externally facing host directly exploitable via a known public exploit (such as a vulnerable
service or Windows remote code execution (RCE) vulnerability), though it does happen. Web
applications provide a vast attack surface, and their dynamic nature means that they are
constantly changing (and overlooked!). A relatively simple code change may introduce a
catastrophic vulnerability or a series of vulnerabilities that can be chained together to gain
access to sensitive data or remote code execution on the webserver or other hosts in the
environment, such as database servers.

It is not uncommon to find flaws that can lead directly to code execution, such as a file
upload form that allows for the upload of malicious code or a file inclusion vulnerability that

https://t.me/offenciveSec
can be leveraged to obtain remote code execution. A well-known vulnerability that is still
quite prevalent in various types of web applications is SQL injection. This type of vulnerability
arises from the unsafe handling of user-supplied input. It can result in access to sensitive
data, reading/writing files on the database server, and even remote code execution.

We often find SQL injection vulnerabilities on web applications that use Active Directory for
authentication. While we can usually not leverage this to extract passwords (since Active
Directory administers them), we can often pull most or all Active Directory user email
addresses, which are often the same as their usernames. This data can then be used to
perform a password spraying attack against web portals that use Active Directory for
authentication such as VPN or Microsoft Outlook Web Access/Microsoft O365. A successful
password spray can often result in access to sensitive data such as email or even a foothold
directly into the corporate network environment.

This example shows the damage that can arise from a single web application vulnerability,
especially when "chained" to extract data from one application that can be used to attack
other portions of a company's external infrastructure. A well-rounded infosec professional
should have a deep understanding of web applications and be as comfortable attacking web
applications as performing network penetration testing and Active Directory attacks. A
penetration tester with a strong foundation in web applications can often set themselves
apart from their peers and find flaws that others may overlook. A few more real-world
examples of web application attacks and the impact are as follows:

Flaw Real-world Scenario

SQL injection Obtaining Active Directory usernames and performing a password
spraying attack against a VPN or email portal.
File Inclusion Reading source code to find a hidden page or directory which exposes
additional functionality that can be used to gain remote code execution.
Unrestricted A web application that allows a user to upload a profile picture that
File Upload allows any file type to be uploaded (not just images). This can be
leveraged to gain full control of the web application server by uploading
malicious code.
Insecure When combined with a flaw such as broken access control, this can
Direct Object often be used to access another user's files or functionality. An example
Referencing would be editing your user profile browsing to a page such as
(IDOR) /user/701/edit-profile. If we can change the 701 to 702 , we may edit
another user's profile!

https://t.me/offenciveSec
 Flaw Real-world Scenario
Broken Another example is an application that allows a user to register a new
Access account. If the account registration functionality is designed poorly, a
Control user may perform privilege escalation when registering. Consider the
POST request when registering a new user, which submits the data
username=bjones&password=Welcome1&
[email protected]&roleid=3 . What if we can manipulate the roleid
parameter and change it to 0 or 1 . We have seen real-world
applications where this was the case, and it was possible to quickly
register an admin user and access many unintended features of the web
application.

Start becoming familiar with common web application attacks and their implications. Don't
worry if any of these terms sound foreign at this point; they will become clearer as you
progress and apply an iterative approach to learning.

It is imperative to study web applications in-depth and become familiar with how they work
and many different application stacks. We will see web application attacks repeatedly during
our Academy journey, on the main HTB platform, and in real-life assessments. Let's dive in
and learn the structure/function of web applications to become better-informed attackers, set
us apart from our peers, and find flaws that others may overlook.

Web Application Layout

No two web applications are identical. Businesses create web applications for a multitude of
uses and audiences. Web applications are designed and programmed differently, and back
end infrastructure can be set up in many different ways. It is important to understand the
various ways web applications can run behind the scenes, the structure of a web application,
its components, and how they can be set up within a company's infrastructure.

Web application layouts consist of many different layers that can be summarized with the
following three main categories:

Category Description
Web Application Describes the structure of required components, such as the
Infrastructure database, needed for the web application to function as intended.
Since the web application can be set up to run on a separate
server, it is essential to know which database server it needs to
access.

https://t.me/offenciveSec
 Category Description
Web Application The components that make up a web application represent all the
Components components that the web application interacts with. These are
divided into the following three areas: UI/UX , Client , and
Server components.

Web Application Architecture comprises all the relationships between the various
Architecture web application components.

Web Application Infrastructure

Web applications can use many different infrastructure setups. These are also called
models . The most common ones can be grouped into the following four types:

Client-Server
One Server
Many Servers - One Database
Many Servers - Many Databases

Client-Server
Web applications often adopt the client-server model. A server hosts the web application
in a client-server model and distributes it to any clients trying to access it.

In this model, web applications have two types of components, those in the front end, which
are usually interpreted and executed on the client-side (browser), and components in the
back end, usually compiled, interpreted, and executed by the hosting server.

https://t.me/offenciveSec
When a client visits the web application's URL (web address, i.e., https://www.acme.local),
the server uses the main web application interface ( UI ). Once the user clicks on a button or
requests a specific function, the browser sends an HTTP web request to the server, which
interprets this request and performs the necessary task(s) to complete the request (i.e.,
logging the user in, adding an item to the shopping cart, browsing to another page, etc.).
Once the server has the required data, it sends the result back to the client's browser,
displaying the result in a human-readable way.

This website we are currently interacting with is also a web application,

developed and hosted by Hack The Box (webserver), and we access it and
interact with it using our web browser (client).

However, even though most web applications utilize a client-server front-back end
architecture, there are many design implementations.

One Server
In this architecture, the entire web application or even several web applications and their
components, including the database, are hosted on a single server. Though this design is
straightforward and easy to implement, it is also the riskiest design.

If any web application hosted on this server is compromised in this architecture, then all web
applications' data will be compromised. This design represents an " all eggs in one
basket " approach since if any of the hosted web applications are vulnerable, the entire
webserver becomes vulnerable.

https://t.me/offenciveSec
Furthermore, if the webserver goes down for any reason, all hosted web applications
become entirely inaccessible until the issue is resolved.

Many Servers - One Database

This model separates the database onto its own database server and allows the web
applications' hosting server to access the database server to store and retrieve data. It can
be seen as many-servers to one-database and one-server to one-database, as long as the
database is separated on its own database server.

This model can allow several web applications to access a single database to have access
to the same data without syncing the data between them. The web applications can be
replications of one main application (i.e., primary/backup), or they can be separate web
applications that share common data.

This model's main advantage ( from a security point of view ) is segmentation, where
each of the main components of a web application is located and hosted separately. In case
one webserver is compromised, other webservers are not directly affected. Similarly, if the
database is compromised (i.e., through a SQL injection vulnerability), the web application
itself is not directly affected. There are still access control measures that need to be
implemented after asset segmentation, such as limiting web application access to only data
needed to function as intended.

https://t.me/offenciveSec
Many Servers - Many Databases
This model builds upon the Many Servers, One Database model. However, within the
database server, each web application's data is hosted in a separate database. The web
application can only access private data and only common data that is shared across web
applications. It is also possible to host each web application's database on its separate
database server.

This design is also widely used for redundancy purposes, so if any web server or database
goes offline, a backup will run in its place to reduce downtime as much as possible. Although
this may be more difficult to implement and may require tools like load balancers to function
appropriately, this architecture is one of the best choices in terms of security due to its proper
access control measures and proper asset segmentation.

Aside from these models, there are other web application models available such as
serverless web applications or web applications that utilize microservices.

Web Application Components

Each web application can have a different number of components. Nevertheless, all of the
components of the models mentioned previously can be broken down to:

1. Client

https://t.me/offenciveSec
 2. Server - Webserver
Web Application Logic
Database
3. Services (Microservices)
3rd Party Integrations
Web Application Integrations
4. Functions (Serverless)

Web Application Architecture

The components of a web application are divided into three different layers (AKA Three Tier
Architecture).

Layer Description
Presentation Consists of UI process components that enable communication with
Layer the application and the system. These can be accessed by the client
via the web browser and are returned in the form of HTML,
JavaScript, and CSS.
Application This layer ensures that all client requests (web requests) are
Layer correctly processed. Various criteria are checked, such as
authorization, privileges, and data passed on to the client.
Data Layer The data layer works closely with the application layer to determine
exactly where the required data is stored and can be accessed.

An example of a web application architecture could look something like this:

https://t.me/offenciveSec
Source: Microsoft Docs

Furthermore, some web servers can run operating system calls and programs, like IIS ISAPI
or PHP-CGI.

Microservices
We can think of microservices as independent components of the web application, which in
most cases are programmed for one task only. For example, for an online store, we can
decompose core tasks into the following components:

Registration
Search
Payments
Ratings
Reviews

These components communicate with the client and with each other. The communication
between these microservices is stateless , which means that the request and response are
independent. This is because the stored data is stored separately from the respective
microservices. The use of microservices is considered service-oriented architecture (SOA),
built as a collection of different automated functions focused on a single business goal.
Nevertheless, these microservices depend on each other.

Another essential and efficient microservice component is that they can be written in different
programming languages and still interact. Microservices benefit from easier scaling and

https://t.me/offenciveSec
faster development of applications, which encourages innovation and speeds upmarket
delivery of new features. Some benefits of microservices include:

Agility
Flexible scaling
Easy deployment
Reusable code
Resilience

This AWS whitepaper provides an excellent overview of microservice implementation.

Serverless
Cloud providers such as AWS, GCP, Azure, among others, offer serverless architectures.
These platforms provide application frameworks to build such web applications without
having to worry about the servers themselves. These web applications then run in stateless
computing containers (Docker, for example). This type of architecture gives a company the
flexibility to build and deploy applications and services without having to manage
infrastructure; all server management is done by the cloud provider, which gets rid of the
need to provision, scale, and maintain servers needed to run applications and databases.

You can read more about serverless computing and its various use cases here.

Architecture Security
Understanding the general architecture of web applications and each web application's
specific design is important when performing a penetration test on any web application. In
many cases, an individual web application's vulnerability may not necessarily be caused by a
programming error but by a design error in its architecture.

For example, an individual web application may have all of its core functionality secure
implemented. However, due to a lack of proper access control measures in its design, i.e.,
use of Role-Based Access Control(RBAC), users may be able to access some admin
features that are not intended to be directly accessible to them or even access other user's
private information without having the privileges to do so. To fix this type of issue, a
significant design change would need to be implemented, which would likely be both costly
and time-consuming.

Another example would be if we cannot find the database after exploiting a vulnerability and
gaining control over the back-end server, which may mean that the database is hosted on a
separate server. We may only find part of the database data, which may mean there are

https://t.me/offenciveSec
several databases in use. This is why security must be considered at each phase of web
application development, and penetration tests must be carried throughout the web
application development lifecycle.

Front End vs. Back End

We may have heard the terms front end and back end web development, or the term
Full Stack web development, which refers to both front and back end web development.
These terms are becoming synonymous with web application development, as they
comprise the majority of the web development cycle. However, these terms are very different
from each other, as each refers to one side of the web application, and each function and
communicate in different areas.

Front End
The front end of a web application contains the user's components directly through their web
browser (client-side). These components make up the source code of the web page we view
when visiting a web application and usually include HTML , CSS , and JavaScript , which is
then interpreted in real-time by our browsers.

This includes everything that the user sees and interacts with, like the page's main elements
such as the title and text HTML, the design and animation of all elements CSS, and what
function each part of a page performs JavaScript.

In modern web applications, front end components should adapt to any screen size and
work within any browser on any device. This contrasts with back end components, which are
usually written for a specific platform or operating system. If the front end of a web
application is not well optimized, it may make the entire web application slow and
unresponsive. In this case, some users may think that the hosting server, or their internet, is

https://t.me/offenciveSec
slow, while the issue lies entirely on the client-side at the user's browser. This is why the
front end of a web application must be optimized for most platforms, devices (including
mobile!), and screen sizes.

Aside from frontend code development, the following are some of the other tasks related to
front end web application development:

Visual Concept Web Design

User Interface (UI) design
User Experience (UX) design

There are many sites available to us to practice front end coding. One example is this one.
Here we can play around with the editor, typing and formatting text and seeing the resulting
HTML , CSS , and JavaScript being generated for us. Copy/paste this VERY simple
example into the right hand side of the editor:

<p><strong>Welcome to Hack The Box Academy</strong><strong></strong></p>

<p></p>
<p><em>This is some italic text.</em></p>
<p></p>
<p><span style="color: #0000ff;">This is some blue text.</span></p>
<p></p>
<p></p>

Watch the simple HTML code render on the left. Play around with the formatting, headers,
colors, etc., and watch the code change.

Back End
The back end of a web application drives all of the core web application functionalities, all of
which is executed at the back end server, which processes everything required for the web
application to run correctly. It is the part we may never see or directly interact with, but a
website is just a collection of static web pages without a back end.

There are four main back end components for web applications:

Component Description
Back end The hardware and operating system that hosts all other components
Servers and are usually run on operating systems like Linux , Windows , or
using Containers .
Web Servers Web servers handle HTTP requests and connections. Some
examples are Apache , NGINX , and IIS .
https://t.me/offenciveSec
 Component Description
Databases Databases ( DBs ) store and retrieve the web application data. Some
examples of relational databases are MySQL , MSSQL , Oracle ,
PostgreSQL , while examples of non-relational databases include
NoSQL and MongoDB .

Development Development Frameworks are used to develop the core Web

Frameworks Application. Some well-known frameworks include Laravel ( PHP ),
ASP.NET ( C# ), Spring ( Java ), Django ( Python ), and Express
( NodeJS JavaScript ).

It is also possible to host each component of the back end on its own isolated server, or in
isolated containers, by utilizing services such as Docker. To maintain logical separation and
mitigate the impact of vulnerabilities, different components of the web application, such as
the database, can be installed in one Docker container, while the main web application is
installed in another, thereby isolating each part from potential vulnerabilities that may affect
the other container(s). It is also possible to separate each into its dedicated server, which
can be more resource-intensive and time-consuming to maintain. Still, it depends on the
business case and design/functionality of the web application in question.

Some of the main jobs performed by back end components include:

Develop the main logic and services of the back end of the web application
Develop the main code and functionalities of the web application
Develop and maintain the back end database
Develop and implement libraries to be used by the web application
Implement technical/business needs for the web application
Implement the main APIs for front end component communications
Integrate remote servers and cloud services into the web application

https://t.me/offenciveSec
Securing Front/Back End
Even though in most cases, we will not have access to the back end code to analyze the
individual functions and the structure of the code, it does not make the application
invulnerable. It could still be exploited by various injection attacks, for example.

Suppose we have a search function in a web application that mistakenly does not process
our search queries correctly. In that case, we could use specific techniques to manipulate the
queries in such a way that we gain unauthorized access to specific database data SQL
injections or even execute operating system commands via the web application, also known
as Command Injections.

We will later discuss how to secure each component used on the front and back ends. When
we have full access to the source code of front end components, we can perform a code
review to find vulnerabilities, which is part of what is referred to as Whitebox Pentesting.

On the other hand, back end components' source code is stored on the back end server, so
we do not have access to it by default, which forces us only to perform what is known as
Blackbox Pentesting. However, as we will see, some web applications are open source,
meaning we likely have access to their source code. Furthermore, some vulnerabilities such
as Local File Inclusion could allow us to obtain the source code from the back end server.
With this source code in hand, we can then perform a code review on back end components
to further understand how the application works, potentially find sensitive data in the source
code (such as passwords), and even find vulnerabilities that would be difficult or impossible
to find without access to the source code.

The top 20 most common mistakes web developers make that are essential for us as
penetration testers are:

No. Mistake
1. Permitting Invalid Data to Enter the Database
2. Focusing on the System as a Whole
3. Establishing Personally Developed Security Methods
4. Treating Security to be Your Last Step
5. Developing Plain Text Password Storage
6. Creating Weak Passwords
7. Storing Unencrypted Data in the Database
8. Depending Excessively on the Client Side
9. Being Too Optimistic
10. Permitting Variables via the URL Path Name

https://t.me/offenciveSec
 No. Mistake
11. Trusting third-party code
12. Hard-coding backdoor accounts
13. Unverified SQL injections
14. Remote file inclusions
15. Insecure data handling
16. Failing to encrypt data properly
17. Not using a secure cryptographic system
18. Ignoring layer 8
19. Review user actions
20. Web Application Firewall misconfigurations

These mistakes lead to the OWASP Top 10 vulnerabilities for web applications, which we will
discuss in other modules:

No. Vulnerability
1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)

It is important to begin to familiarize ourselves with these flaws and vulnerabilities as they
form the basis for many of the issues we cover in future web and even non-web related
modules. As pentesters, we must have the ability to competently identify, exploit, and explain
these vulnerabilities for our clients.

HTML

https://t.me/offenciveSec
The first and most dominant component of the front end of web applications is HTML
(HyperText Markup Language). HTML is at the very core of any web page we see on the
internet. It contains each page's basic elements, including titles, forms, images, and many
other elements. The web browser, in turn, interprets these elements and displays them to the
end-user.

The following is a very basic example of an HTML page:

Example

<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>
<h1>A Heading</h1>
<p>A Paragraph</p>
</body>
</html>

This would display the following:

As we can see, HTML elements are displayed in a tree form, similar to XML and other
languages:

HTML Structure

document
- html
-- head
--- title
-- body
--- h1
--- p

Each element can contain other HTML elements, while the main HTML tag should contain all
other elements within the page, which falls under document , distinguishing between HTML
https://t.me/offenciveSec
and documents written for other languages, such as XML documents.

The HTML elements of the above code can be viewed as follows: