> For the complete documentation index, see [llms.txt](https://dev-angelist.gitbook.io/ecpptv3-ptp-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev-angelist.gitbook.io/ecpptv3-ptp-notes/readme/ecpptv3/web-app-security/5.2-information-gathering/5.2.4-fingerprinting-custom-applications.md).

# 2.2.4 Fingerprinting Custom Applications

## Fingerprinting Custom Applications

When dealing with custom applications, particularly those tailored for a specific organization, a thorough approach is required to understand their intricacies. Below is a detailed breakdown of the fingerprinting process, with specific examples related to your message.

### **Initial Overview**

* **Understand the Scope:**
  * **Questions to Address:**
    * What is the primary purpose of the application?
    * Does it facilitate user registration?
    * Is there an administration panel?
    * What types of user input are accepted?
    * Does it allow file uploads?
    * Does it utilize JavaScript, AJAX, or Flash?
  * **Example:**
    * Suppose you're auditing a custom application for a financial institution. Understanding whether it enables online banking, user registrations, and financial transactions is crucial.
* **Visit the Website:**
  * **Questions to Answer:**
    * What is the application's core functionality?
    * Does it involve online sales, corporate presence, or blogging?
    * Are there specific areas that require user authentication?
  * **Example:**
    * While navigating the website, you may discover that the application is primarily focused on corporate financial management and includes a secure login area for clients.
* **Consider Common Software:**
  * **Example:**
    * Even in a custom application, you might find integrated functionalities such as forums or blogs. Recognizing these can be essential, as they may introduce vulnerabilities commonly associated with off-the-shelf software.

### **Burp Target Crawler**

* **Proxy Setup:**
  * **Tool:**
    * Utilize Burp Proxy for browsing, enabling the configuration of a scope through regular expressions.
  * **Example:**
    * Configure Burp Proxy to intercept requests related to user authentication or financial transactions within the application.
* **Crawling with Burp:**
  * **Tool:**
    * Enable the Burp crawler (Spider tab) to automatically generate and record requests and response headers.
  * **Example:**
    * The crawler will traverse through different sections of the financial application, capturing relevant information about the structure and behavior.

### **Creating a Functional Graph**

* **Study the Target:**
  * **Questions to Answer:**
    * What is the primary purpose of each section?
    * Are there specific functionalities tied to user authentication?
    * What are the critical areas, such as eCommerce or client dashboards?
  * **Example:**
    * Identify that the eCommerce section is a core element, and there are login-protected areas containing sensitive financial data.
* **Study the Blocks:**
  * **Example:**
    * Recognize that certain blocks may use third-party components, like a financial analytics tool or a secure payment gateway. Note any login-protected areas with a rhombus symbol.
* **Functional Graph:**
  * **Example:**
    * Visualize the eCommerce block as a green hexagon, indicating its significance. The graph helps illustrate the application's structure and critical components.

## **Mapping the Attack Surface**

* **Client-Side Validation:**
  * **Identification:**
    * Locate client-side validation points by inspecting JavaScript functions triggered upon form submission.
  * **Example:**
    * Use tools like Firebug to identify JavaScript functions that validate user inputs in financial transaction forms.
* **Database Interaction:**
  * **Detection:**
    * Identify changes in page appearance indicating active database interaction, as this may hint at SQL injection vulnerabilities.
  * **Example:**
    * Notice that certain pages dynamically update based on user queries, potentially indicating database interactions for financial data retrieval.
* **File Uploading and Downloading:**
  * **Example:**
    * Identify pages that allow dynamic downloads or file uploads. These areas might pose risks related to Remote or Local File Inclusion vulnerabilities.
* **Display of User Supplied Data:**
  * **Example:**
    * Locate sections displaying user-supplied data, which could be vulnerable to Cross-Site Scripting (XSS) attacks.
* **Redirections:**
  * **Example:**
    * Investigate server-side directives and meta refresh tags. Improper handling could lead to HTTP response splitting and other attacks.
* **Access Controls and Login Protected Pages:**
  * **Example:**
    * Identify login pages and areas protected by authentication. Test the security of these authentication routines.
* **Error Messages:**
  * **Example:**
    * Collect error messages encountered during browsing. While intentional error generation may come later, noting spontaneous errors is crucial.

### **Charting**

* **Organize Information:**
  * **Example:**
    * Use a table-based chart to categorize information for each block, including client-side validation, redirections, database interaction, errors, display of user data, and login details.