Web Security: Recon

Gerson Enriquez — Wed, 31 Aug 2022 13:16:37 +0000

What is Web Application Recon

Think about the Money Heist crime series; going inside the Bank of Spain is easier to say than done. The thief, first of all, has to have a specific target; why does he want to go inside? in this case, it is because he wants to steal all the money, so he has to know where the money is. Once he has a target, he must study the planimetry and the bank's floor plans to know which points he can access quickly and see all the exit routes.

Unfortunately, it is not enough. The thief needs to know how the business works inside, the available roles, and who works inside. It is probably also helpful to know a bit about each of them to apply successful Social engineering.
After having physical and intellectual knowledge about the bank, the thief can start thinking about the best strategy to go inside, the weak points, and all the alternatives. On the Web, the logic is the same, the thief, in our case, is the malicious user (the attacker), and the bank is the application.
The Recon phase focuses on acquiring all the possible knowledge about the application, not just technical expertise but also functional; this means knowing who application users are, how the application generates revenue, for what purpose users select the application over competitors, who are the competitors, what functionality is found in the application, etc.
In this phase, we will play the role of an attacker, and the goal will be to have our planimetry of the application, but first, let's take a brief look at the structure of modern web apps.

The Structure of a Modern Web Application

Before going deep into the Recon phase, we will see an overall overview of some fundamental technologies of a modern web application. A question comes to my mind: what happens when you type an URL into your browser?

After pressing enter, the first thing the Browser has to do is translate the website name into the respective IP address; thanks to the DNS (Domain name system) process. Once the Browser knows the exact address, it's possible to search where the resource is. When the resource is found, it starts the TCP connection with the server, and the server responds with an HTML page that the Browser has to render. As we can see, the Web is a digital universe composed mainly of a few protocols (DNS, HTTP, URL) built over other protocols that allow computers to communicate between them.

The following are some technologies and standards that modern applications often use to make the client-server communication easier:

HTTP

HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance, text, layout description, images, videos, scripts, and more.

HTTP means Hypertext Transfer Protocol and we can see it as a bridge between client and server.

The fundamental principle behind the Web was that once someone somewhere made available a document, database, graphic, sound, video, it should be accessible by anyone, with any type of computer, in any country. HTTP helps to establish a common language in order to make client-server communication possible, the feature is called format negotiation that allowed a client to say what sorts of data format it could handle, and allow the server to return a document in any one of them.
Since HTTP is a stateless protocol, each request is independent, and we have to pass all the information needed by the server in every request. Nevertheless, it's possible to have some session states thanks to HTTP Cookies. Cookies are set by the server and handled by the browser and allow users to have the authorization to access protected resources.

REST APIs

REST stands for Representational State Transfer, which is a fancy way of defining an API.
With REST APIs we will have as an outcome an interface of all apis that the application makes available.

The server response is usually in a JSON format.

JSON

JSONstands for Javascript Object Notation, which replaced XML as the most used format to represent information between client and server.

These are the most common technologies used on the Web, followed by Javascript, the Browser language, and SPA frameworks like React, Vue, and Angular.
Now we can go deep into the central part of the article, where we will look at how we can create our planimetry of the application and understand how it works.

Mapping the Application

As we said at the beginning, we have to study the target before going inside the bank or the application. We need to map the application; this means knowing all the possible paths, understanding what kind of payload the APIs accept, etc.
Here we see some common practical techniques to acquire that kind of knowledge.

- ENUMERATING CONTENT AND FUNCTIONALITY
In a typical application, most content and functionality can be identified via manual browsing, so starting the flow from the main initial page, then walking through the application following every link. This was the basic approach. There are also automatic tools that allow us to do Web Crawling. Unfortunately, these kinds of tools are great for discovering public paths of the application but not so well for discovering the kind of routes that are protected.

The most effective approach is a combination of both; it is called user-directed spidering, which means walking through the application in a usual way but intercepting all the network calls with the help of an automatic tool. Burp suite can help with this; it has a Proxy tab where we can put the intercept feature on.

With user-directed spidering, the user can simply log in to the application using his browser, and the proxy/spider tool picks up the resulting session and identifies all the additional content now available to the user.
It is also common for applications to contain content and functionality that is not directly linked to or reachable from the main visible content. A common example is functionality that has been implemented for testing or debugging purposes and has never been removed.
The application can also present different functionality to different categories of users (anonymous, authenticated, and administrators).

Often, rather than list and map all the possible pages, is more useful map the application through his functionalities. By identifying these, you can better understand the expectations and assumptions of the application's developers when implementing the functions.

At this step, we know, more or less, how the application is structured, what APIs are called and what are the possible paths. The next step focuses on the application's functionality and reveals possible vulnerabilities.

- ANALYZING THE APPLICATION
Enumerating as much of the application's content as possible is only one element of the mapping process. Equally important is the task of analyzing the application's functionality, behaviour, and technologies employed to identify the key attack surfaces exposes and to begin formulating an approach to probing the application for exploitable vulnerabilities. Here are some key areas to investigate:

The app core functionality: the actions that can be leveraged to perform when used as intended.
Error messages, admin functions and the use of redirects.
The core security mechanisms: session state, access controls, and authentication mechanisms with the supporting logic (user registration, password change, account recovery).

To understand what actions the application can take, it's important, first of all, to find all the possible APIs, then analyze them. When we analyze an API, since most APIs follow a REST format, as we saw before, we can understand the method of the API and its parameters. Once we know the kind of parameters it receives, we can brute force the API and try to pass a different type of params and see how the web server responds.
The API's discovery happens in the previous phase when we navigate the application intercepting all the network calls.

Now we have to analyze it: the two most common HTTP methods are GET and POST; the first one is used when we ask for a resource, and the second one is used when we send data to the server that needs to be persisted.

Since every application with a public web user interface should have a login page, it's also important to understand the core security mechanism. The way the session is handle may differ. It's important to know what type of authentication scheme you are working with because many modern applications send authentication token with every request. This means if we can reverse engineer the type of authentication used and understand how the token is being attached to requests, it will be easier to analyze other API endpoints that rely on an authenticated user token.

To recap, the recon phase focuses on acquiring expertise about the application, enumerating its content, and analyzing its functionalities and APIs. However, Recon techniques are constantly evolving, and it can be difficult to accurately determine which techniques outshine others. Because of this, you should always be on the lookout for new and interesting recon techniques.
In the next part of this series, we will see the offense part, where we will go deep into some common attacks. See you there!

Web Security: Introduction

Gerson Enriquez — Tue, 23 Aug 2022 13:50:00 +0000

As a frontend developer, I often focus too much on improving my skills in technologies like HTML, CSS, JS, and SPA frameworks, and it's right🙂, but it's also essential to enhance my understanding of how the browser works and, more importantly how I can enhance the security of the applications I develop.
I was the kind of developer that always do the new React course available to be more productive on the job. In the last period, we tackled the Authentication part of the application I currently working on, discussing how to handle it. it was disheartening not to know what the best solution suggest, where to persist the token on the client side, and how to explain the differences between local storage, session storage, and what are cookies. Fortunately, I am the person that tries to fill the gap as soon as possible when there is one, so I decided to immerse myself in the topic and go deep.
The purpose of this series about web security is to create my learning notes and fill the gap in myself and other developers as well: understand the mindset of a malicious user, discover the several kinds of attacks that can happen in a web application, and know a bit more about the browser built-in tools to mitigate attacks.

Why Web security matters

You often encounter headlines like "A big social network leaked login passwords" or "an attacker stole credit card information from a shopping site". Web security matters because we can avoid those kinds of things, in an insecure application, different people could be affected. It has an impact on users through stolen sensitive data, on the application through a lost of confidence from the users or worse a compromised business, and on other systems through hijacked attacks.

What's in this series

The series is divided in three parts:

Reconnaissance: when we talk about Web security, it's important to start understanding how a malicious user, an attacker, could think. The Recon phase is important because is the process to acquire knowledge about the application. Knowledge not only in a perspective way but also in a functional way: who are its users, how does the application generate revenue, what functionality is found in the application, etc.
At the end of this process, we will gain a deep understanding of how the application works and if there could exist a possible vulnerability.
Offense: once we recon the application and gained information about it, we can proceed with the offense phase, Where we will see some common techniques used by attackers to compromise the application.
Deffense: in this final part, we will consider significant security risks and concerns. Following our concerns, we will evaluate alternative implementations as well as mitigations that alleviate security risk. Throughout this process, we will see some useful techniques to reduce the number of vulnerabilities found in the production code.

Prerequisite Knowledge

The series is focusing on frontend developers that want to acquire more knowledge on how to enhance the security of web applications and understand better the properties exchanged by clients and servers.
Hence is just enough to have a basic knowledge of JS, HTML, and browser developer tools.

References:
Web Application Security: Exploitation and Countermeasures for Modern Web Applications

The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws: Discovering and Exploiting Security Flaws

Web Security Academy

Web Security, Stanford course

Safe and secure, Ensure your site and your users' data is secure.

Weaving the Web

DEV Community: Gerson Enriquez