# Map Application Architecture

|ID          |
|------------|
|WSTG-INFO-10|

## Summary

In order to effectively test an application, and to be able to provide meaningful recommendations on how to address any of the issues identified, it is important to understand what one is actually testing. Additionally, it could be helpful to determine whether specific components should be considered out-of-scope for testing.

Modern web applications can vary significantly in complexity, from a simple script running on a single server to a highly complex application spread across dozens of different systems, languages and components. There may also be additional network-level components such as firewalls or intrusion protection systems that can have a significant impact on testing.

## Test Objectives

- Understand the architecture of the application and the technologies in use.

## How to Test

When testing from a black box perspective, it is important to try and build a clear picture of how the application works, and which technologies and components are in place. In some cases, it is possible to test for specific components such as a web application firewall, while other components can be identified by inspecting the behavior of the application.

The sections below provide a high-level overview of common architectural components, along with details on how they can be identified.

### Application Components

#### Web Server

Simple applications may run on a single server, which can be identified using the steps discussed in the [Fingerprint Web Server](02-Fingerprint_Web_Server.md) section of the guide.

#### Platform-as-a-Service (PaaS)

In a Platform-as-a-Service (PaaS) model, the web server and underlying infrastructure are managed by the service provider, and the customer is only responsible for the application that is deployed on them. From a testing perspective, there are two main differences:

- The application owner has no access to the underlying infrastructure, which means they will be unable to directly remediate any issues
- Infrastructure testing is likely to be out-of-scope for any engagements

In some cases, it is possible to identify the use of PaaS, as the application may use a specific domain name (for example, applications deployed on Azure App Services will have a `*.azurewebsites.net` domain - although they may also use custom domains). In other cases, it is difficult to determine whether PaaS is in use.

#### Serverless

In a Serverless model, the developers provide code which is directly run on a hosting platform as individual functions, rather than running a traditional larger web application deployed in a webroot. This makes it well suited for microservice-based architecture. As with a PaaS environment, infrastructure testing is likely to be out-of-scope.

In some cases, the use of Serverless code may be indicated by the presence of specific HTTP headers. For example, AWS Lambda functions will typically return the following headers:

```http
X-Amz-Invocation-Type
X-Amz-Log-Type
X-Amz-Client-Context
```

Azure Functions are less obvious. They typically return the `Server: Kestrel` header - but this on its own is not enough to determine that it is an Azure App function, as it could be some other code running on Kestrel.

#### Microservices

In a microservice-based architecture, the application API is made up of multiple discrete services, instead of being run as a monolithic application. The services themselves often run inside containers (usually with Kubernetes), and can use a variety of different operating systems and languages. Although they are typically behind a single API gateway and domain, the use of multiple languages (often indicated in detailed error messages) can suggest that microservices are in use.

#### Static Storage

Many applications store static content on dedicated storage platforms, rather than hosting it directly on the main web server. The two most common platforms are Amazon's S3 Buckets, and Azure's Storage Accounts, and can be easily identified by the domain names:

- `BUCKET.s3.amazonaws.com` or `s3.REGION.amazonaws.com/BUCKET` for Amazon S3 Buckets
- `ACCOUNT.blob.core.windows.net` for Azure Storage Accounts

These storage accounts can often expose sensitive files, as discussed in the [Testing Cloud Storage Guide](../02-Configuration_and_Deployment_Management_Testing/11-Test_Cloud_Storage.md) section.

#### Database

Most non-trivial web applications use some kind of database to store dynamic content. In some cases, it's possible to determine the database. This can often be done by:

- Port scanning the server and looking for any open ports associated with specific databases
- Triggering SQL (or NoSQL) related error messages (or finding existing errors from a [search engine](../01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md)

When it's not possible to conclusively determine the database, the tester can often make an educated guess based on other aspects of the application:

- Windows, IIS and ASP.NET often use Microsoft SQL server
- Embedded systems often use SQLite
- PHP often uses MySQL or PostgreSQL
- APEX often uses Oracle

These are not hard rules, but can certainly give you a reasonable starting point if no better information is available.

#### Authentication

Most applications have user authentication. There are multiple authentication backends that can be used, such as:

- Web server configuration (including `.htaccess` files) or hard-coding passwords in scripts
    - Usually shows up as HTTP Basic authentication, indicated by a pop-up in the browser and a `WWW-Authenticate: Basic` HTTP header
- Local user accounts in a database
    - Usually integrated into a form or API endpoint on the application
- An existing central authentication source such as Active Directory or an LDAP server
    - May use NTLM authentication, indicated by a `WWW-Authenticate: NTLM` HTTP header
    - May be integrated into the web application in a form
    - May require the username to be entered in the "DOMAIN\username" format, or may give a dropdown of available domains
- Single Sign-On (SSO) with either an internal or external provider
    - Typically uses OAuth, OpenID Connect, or SAML

Applications may provide multiple options for the user to authenticate (such as registering a local account, or using their existing Facebook account), and may use different mechanisms for normal users and administrators.

#### Third Party Services and APIs

Almost all web applications include third party resources that are loaded or that the client interacts with. These can include:

- [Active content](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#mixed_active_content) (such as scripts, style sheets, fonts, and iframes)
- [Passive content](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#mixed_passivedisplay_content) (such as images and videos)
- External APIs