Mirrors/h4cker
2
0
Fork 0
mirror of https://github.com/The-Art-of-Hacking/h4cker synced 2024-11-13 23:07:07 +00:00
Code Issues Projects Releases Packages Wiki Activity

Update webapp_recon.md

Browse source
This commit is contained in:
Omar Santos 2024-07-01 11:59:54 -04:00 committed by GitHub
parent 68288740f7
commit c97ca408f0
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 14 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
recon/webapp_recon.md
View file

@ -1,49 +1,28 @@
# Web Application Security Testing Methodology # Web Application Security Testing Methodology
## 1. Mapping the Application ### 1. Mapping the Application
This step is about creating a comprehensive map of the entire application from a security standpoint. This involves several specific activities:
Mapping the application is a critical initial phase in security testing. It involves understanding the visible and underlying structure of the application to effectively tailor the testing strategy. - **Explore Visible Content**: This involves manually reviewing the application and using automated tools to discover all the visible resources, such as public-facing URLs, documents, and media files. Tools like web crawlers are often used here to automate the discovery process.
### Explore Visible Content - **Consult Public Resources**: Here, the tester looks at documentation, code repositories, forums, and other publicly available sources to gather additional information about the application's structure and potential vulnerabilities. This might include finding developer comments in public code repositories or configuration snippets in technical forums.
- **Objective**: Identify all publicly accessible endpoints and files.
- **Methods**: Use tools like web crawlers and directory brute forcing tools.
### Consult Public Resources - **Discover Hidden Content**: Tools and techniques are used to uncover hidden or unlinked sections of the application, such as admin interfaces or staging versions. This could involve using tools that perform forced browsing or directory brute-forcing.
- **Objective**: Gather information from publicly available sources.
- **Methods**: Check documentation, forums, and other related publications.
### Discover Hidden Content - **Discover Default Content**: Identifying default installations and configurations that are often overlooked and not removed by developers. For example, default admin panels or configuration files that come with software packages.
- **Objective**: Uncover potentially hidden or non-indexed directories and files.
- **Methods**: Employ tools that perform forced browsing and directory listing.
### Discover Default Content - **Enumerate Identifier-Specified Functions**: Analyzing how the application responds to various manipulations of URL parameters or path names, which might reveal additional functionality or hidden debugging parameters.
- **Objective**: Identify common or default files and directories.
- **Methods**: Use lists of known default installation paths and filenames.
### Enumerate Identifier-Specified Functions - **Test for Debug Parameters**: Searching for parameters that developers might have left in the application which could expose sensitive information if triggered, such as `?debug=true`.
- **Objective**: Determine the functionality exposed through URL parameters or function-specific paths.
- **Methods**: Analyze URL patterns and parameter names for hints of underlying functionality.
### Test for Debug Parameters ### 2. Analyze the Application
- **Objective**: Discover any leftover or undocumented debug parameters that could expose sensitive information. After mapping, the application undergoes a thorough analysis:
- **Methods**: Attempt common debug parameter names and observe responses for changes in behavior or information disclosure.
## 2. Analyze the Application - **Identify Functionality**: Understanding exactly what the application does, its key features, and functionality. This includes cataloging all operations the application can perform, from user data processing to internal API communications.
This step involves a deeper analysis of the application's build and behavior to identify potential security vulnerabilities. - **Identify Data Entry Points**: Recognizing all the points where the application receives input from the users, which could be through forms, API endpoints, or even through the URL. Each entry point represents a potential vector for attacks like SQL injection or cross-site scripting.
### Identify Functionality - **Identify the Technologies Used**: Determining the software stack upon which the application is built, including the web server, frameworks, libraries, and third-party plugins. This information is crucial as it allows testers to focus on known vulnerabilities specific to these technologies.
- **Objective**: Catalog all functions the application performs.
- **Methods**: Systematic usage and testing of all features.
### Identify Data Entry Points - **Map the Attack Surface**: Integrating all the gathered information to outline the complete attack surface of the application. This includes all possible points where an attacker could try to exploit vulnerabilities.
- **Objective**: List all points where user input is accepted.
- **Methods**: Review forms, API endpoints, and any other interfaces.
### Identify the Technologies Used
- **Objective**: Determine all underlying technologies (frameworks, libraries, servers).
- **Methods**: HTTP headers, file extensions, and error messages can reveal software versions and types.
### Map the Attack Surface
- **Objective**: Understand all areas of the application that can potentially be attacked.
- **Methods**: Combine the information from functionality, data entry points, and technology identification to visualize the complete attack surface.