mirror of
https://github.com/0x5t4l1n/hunting.git
synced 2026-05-26 11:35:51 +00:00
Restructure repository: Remove OWASP categorization, organize by vulnerability type
Co-authored-by: Stalin-143 <161853795+Stalin-143@users.noreply.github.com>
This commit is contained in:
@@ -0,0 +1,18 @@
|
||||
# Authentication Bypass
|
||||
|
||||
## Description
|
||||
Authentication bypass vulnerabilities allow an attacker to gain access to a system without providing valid credentials. These vulnerabilities can result from flawed authentication logic, improper session management, or weak authentication mechanisms.
|
||||
|
||||
## Common Attack Vectors
|
||||
- Login forms
|
||||
- Password reset functionality
|
||||
- Multi-factor authentication
|
||||
- Session tokens
|
||||
- JWT tokens
|
||||
- OAuth flows
|
||||
|
||||
## Testing Approach
|
||||
Test authentication mechanisms for logical flaws, parameter manipulation, and bypass techniques that allow unauthorized access.
|
||||
|
||||
## Payloads
|
||||
See `auth-bypass-payloads.txt` for a comprehensive list of authentication bypass payloads and techniques.
|
||||
@@ -0,0 +1,27 @@
|
||||
# Business Logic Vulnerabilities
|
||||
|
||||
## Description
|
||||
Business logic vulnerabilities are flaws in the design and implementation of an application that allow an attacker to elicit unintended behavior. These vulnerabilities occur when the application's legitimate processing flow can be used in a way that results in a negative consequence to the organization.
|
||||
|
||||
## Common Issues
|
||||
- Insufficient workflow validation
|
||||
- Price manipulation
|
||||
- Quantity manipulation
|
||||
- Race conditions
|
||||
- Bypassing business rules
|
||||
- Abuse of functionality
|
||||
- Lack of rate limiting
|
||||
|
||||
## Common Attack Vectors
|
||||
- Payment processing
|
||||
- Discount/coupon systems
|
||||
- Account creation/management
|
||||
- Transaction processing
|
||||
- File upload limits
|
||||
- Resource allocation
|
||||
|
||||
## Testing Approach
|
||||
Understand the application's business logic and test for ways to manipulate or bypass intended workflows and rules.
|
||||
|
||||
## Payloads
|
||||
See `business-logic-payloads.txt` for a comprehensive list of business logic testing scenarios and payloads.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Command Injection
|
||||
|
||||
## Description
|
||||
Command injection is a cyber attack that involves executing arbitrary commands on a host operating system. This vulnerability occurs when an application passes unsafe user-supplied data to a system shell.
|
||||
|
||||
## Common Attack Vectors
|
||||
- System administration interfaces
|
||||
- File upload functionality
|
||||
- Network diagnostic tools (ping, traceroute)
|
||||
- Backup/restore functions
|
||||
- Any feature that executes system commands
|
||||
|
||||
## Testing Approach
|
||||
Submit command separators and system commands in input fields to test if the application executes arbitrary commands.
|
||||
|
||||
## Payloads
|
||||
See `command-injection-payloads.txt` for a comprehensive list of command injection payloads.
|
||||
@@ -0,0 +1,18 @@
|
||||
# Deserialization
|
||||
|
||||
## Description
|
||||
Insecure deserialization vulnerabilities occur when untrusted data is used to abuse the logic of an application, inflict a denial of service attack, or execute arbitrary code upon deserialization. This is particularly dangerous in applications that serialize and deserialize objects.
|
||||
|
||||
## Common Attack Vectors
|
||||
- Cookie values
|
||||
- API requests (JSON, XML, YAML)
|
||||
- Session data
|
||||
- Cached data
|
||||
- Message queues
|
||||
- File uploads
|
||||
|
||||
## Testing Approach
|
||||
Submit serialized objects with malicious payloads to test if the application deserializes untrusted data without proper validation.
|
||||
|
||||
## Payloads
|
||||
See `deserialization-payloads.txt` for a comprehensive list of deserialization attack payloads.
|
||||
@@ -0,0 +1,17 @@
|
||||
# IDOR (Insecure Direct Object References)
|
||||
|
||||
## Description
|
||||
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result, attackers can bypass authorization and access resources directly by modifying the value of a parameter used to point to an object.
|
||||
|
||||
## Common Attack Vectors
|
||||
- URL parameters (IDs, usernames)
|
||||
- API endpoints
|
||||
- File references
|
||||
- Database keys
|
||||
- Session tokens
|
||||
|
||||
## Testing Approach
|
||||
Manipulate object references (IDs, filenames, keys) to access unauthorized resources belonging to other users.
|
||||
|
||||
## Payloads
|
||||
See `idor-payloads.txt` for a comprehensive list of IDOR testing techniques and payloads.
|
||||
@@ -0,0 +1,16 @@
|
||||
# LDAP Injection
|
||||
|
||||
## Description
|
||||
LDAP Injection is an attack used to exploit web applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it's possible to modify LDAP statements through techniques similar to SQL injection.
|
||||
|
||||
## Common Attack Vectors
|
||||
- Login forms
|
||||
- Search fields
|
||||
- User directory lookups
|
||||
- Authentication systems
|
||||
|
||||
## Testing Approach
|
||||
Submit LDAP metacharacters and operators in input fields to test if the application is vulnerable to LDAP injection.
|
||||
|
||||
## Payloads
|
||||
See `ldap-injection-payloads.txt` for a comprehensive list of LDAP injection payloads.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Log Injection
|
||||
|
||||
## Description
|
||||
Log injection vulnerabilities occur when an application includes untrusted data in log files without proper validation or encoding. Attackers can exploit this to forge log entries, inject malicious content into logs, or hide their activities by manipulating log data.
|
||||
|
||||
## Common Attack Vectors
|
||||
- User input fields that get logged
|
||||
- HTTP headers
|
||||
- Error messages
|
||||
- Authentication attempts
|
||||
- Application events
|
||||
|
||||
## Common Techniques
|
||||
- CRLF injection to create fake log entries
|
||||
- Log forging
|
||||
- Log poisoning
|
||||
- Log file pollution
|
||||
|
||||
## Testing Approach
|
||||
Submit special characters and control sequences in input fields that are logged to test for log injection vulnerabilities.
|
||||
|
||||
## Payloads
|
||||
See `log-injection-payloads.txt` for a comprehensive list of log injection payloads.
|
||||
@@ -1,14 +0,0 @@
|
||||
# A01 - Broken Access Control
|
||||
|
||||
## Description
|
||||
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Path Traversal
|
||||
- IDOR (Insecure Direct Object References)
|
||||
- Missing Function Level Access Control
|
||||
- Forced Browsing
|
||||
- Privilege Escalation
|
||||
|
||||
## Testing Approach
|
||||
Test for access control by manipulating URLs, parameters, and attempting to access resources without proper authorization.
|
||||
@@ -1,34 +0,0 @@
|
||||
# Open Redirect Vulnerability
|
||||
|
||||
## Description
|
||||
Open redirect vulnerabilities occur when a web application accepts user-controllable input that specifies a link to an external site and uses that link in a redirect. This vulnerability can be exploited by attackers to redirect users to malicious websites while making the URL appear legitimate.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Unvalidated redirect parameters (e.g., `?url=`, `?redirect=`, `?next=`)
|
||||
- Return URL manipulation in authentication flows
|
||||
- Post-login redirects
|
||||
- Logout redirects
|
||||
- URL parameter injection
|
||||
- Header-based redirects (e.g., Location, Refresh headers)
|
||||
|
||||
## Impact
|
||||
- Phishing attacks
|
||||
- Credential theft
|
||||
- Malware distribution
|
||||
- Bypassing security controls (e.g., URL whitelisting)
|
||||
- Social engineering attacks
|
||||
|
||||
## Testing Approach
|
||||
1. Identify redirect parameters in URLs (e.g., `url`, `redirect`, `next`, `return`, `continue`)
|
||||
2. Test with external URLs (e.g., `http://evil.com`)
|
||||
3. Try various encoding techniques to bypass filters
|
||||
4. Test protocol handlers (e.g., `javascript:`, `data:`)
|
||||
5. Test absolute and relative paths
|
||||
6. Check POST-based redirects in addition to GET parameters
|
||||
|
||||
## Prevention
|
||||
- Avoid using user-supplied input for redirects
|
||||
- Use a mapping of allowed redirect destinations
|
||||
- Validate redirect URLs against a whitelist
|
||||
- Use relative URLs where possible
|
||||
- Implement proper input validation and sanitization
|
||||
@@ -1,14 +0,0 @@
|
||||
# A02 - Cryptographic Failures
|
||||
|
||||
## Description
|
||||
Previously known as Sensitive Data Exposure, this category focuses on failures related to cryptography which often lead to exposure of sensitive data. Common issues include weak cryptographic algorithms, improper key management, and data transmitted in clear text.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Weak encryption algorithms
|
||||
- Hardcoded credentials
|
||||
- Insecure key storage
|
||||
- Data transmitted in clear text
|
||||
- Missing encryption
|
||||
|
||||
## Testing Approach
|
||||
Look for sensitive data exposure through weak or missing encryption, analyze SSL/TLS configurations, and check for hardcoded secrets.
|
||||
@@ -1,15 +0,0 @@
|
||||
# A03 - Injection
|
||||
|
||||
## Description
|
||||
Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
|
||||
|
||||
## Common Injection Types
|
||||
- SQL Injection
|
||||
- Cross-Site Scripting (XSS)
|
||||
- Command Injection
|
||||
- LDAP Injection
|
||||
- XML Injection
|
||||
- Template Injection
|
||||
|
||||
## Testing Approach
|
||||
Submit malicious input containing special characters and observe application behavior, error messages, and response times.
|
||||
@@ -1,14 +0,0 @@
|
||||
# A04 - Insecure Design
|
||||
|
||||
## Description
|
||||
Insecure design is a broad category representing different weaknesses expressed as "missing or ineffective control design." The difference between insecure design and insecure implementation is that design flaws are inherent to the application's architecture.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Missing security controls
|
||||
- Insufficient threat modeling
|
||||
- Insecure design patterns
|
||||
- Business logic flaws
|
||||
- Missing rate limiting
|
||||
|
||||
## Testing Approach
|
||||
Test business logic flows, analyze application architecture, and look for missing security controls or flawed design patterns.
|
||||
@@ -1,15 +0,0 @@
|
||||
# A05 - Security Misconfiguration
|
||||
|
||||
## Description
|
||||
Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Default credentials
|
||||
- Unnecessary features enabled
|
||||
- Missing security headers
|
||||
- Verbose error messages
|
||||
- Outdated software
|
||||
- Directory listing enabled
|
||||
|
||||
## Testing Approach
|
||||
Check for default configurations, analyze HTTP headers, test for information disclosure, and verify security settings.
|
||||
@@ -1,14 +0,0 @@
|
||||
# A06 - Vulnerable and Outdated Components
|
||||
|
||||
## Description
|
||||
Components run with the same privileges as the application itself, so flaws in any component can result in serious impact. Applications using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Outdated libraries
|
||||
- Unpatched systems
|
||||
- Vulnerable dependencies
|
||||
- End-of-life software
|
||||
- Unknown component inventory
|
||||
|
||||
## Testing Approach
|
||||
Identify component versions, check for known CVEs, analyze dependency trees, and use vulnerability scanners.
|
||||
@@ -1,15 +0,0 @@
|
||||
# A07 - Identification and Authentication Failures
|
||||
|
||||
## Description
|
||||
Previously known as Broken Authentication, this category includes failures related to user identity, authentication, and session management. This can allow attackers to compromise passwords, keys, or session tokens, or exploit implementation flaws to assume other users' identities.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Weak password requirements
|
||||
- Credential stuffing
|
||||
- Broken session management
|
||||
- Missing multi-factor authentication
|
||||
- Insecure password recovery
|
||||
- Session fixation
|
||||
|
||||
## Testing Approach
|
||||
Test authentication mechanisms, session handling, password policies, and account recovery processes.
|
||||
@@ -1,14 +0,0 @@
|
||||
# A08 - Software and Data Integrity Failures
|
||||
|
||||
## Description
|
||||
This relates to code and infrastructure that does not protect against integrity violations. This includes insecure deserialization, insecure CI/CD pipelines, and applications that rely on updates, plugins, or libraries from untrusted sources without integrity verification.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Insecure deserialization
|
||||
- Unverified software updates
|
||||
- Insecure CI/CD pipelines
|
||||
- Unsigned code execution
|
||||
- Missing integrity checks
|
||||
|
||||
## Testing Approach
|
||||
Test for deserialization vulnerabilities, analyze update mechanisms, check code signing, and verify integrity checks.
|
||||
@@ -1,15 +0,0 @@
|
||||
# A09 - Security Logging and Monitoring Failures
|
||||
|
||||
## Description
|
||||
This category helps detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs at any time.
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Missing security logs
|
||||
- Inadequate log protection
|
||||
- No alerting mechanism
|
||||
- Logs not monitored
|
||||
- Insufficient log detail
|
||||
- No incident response
|
||||
|
||||
## Testing Approach
|
||||
Verify that security-relevant events are logged, logs are protected, alerting mechanisms exist, and incident response procedures are in place.
|
||||
@@ -1,15 +0,0 @@
|
||||
# A10 - Server-Side Request Forgery (SSRF)
|
||||
|
||||
## Description
|
||||
SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Unvalidated URL parameters
|
||||
- Internal network scanning
|
||||
- Cloud metadata access
|
||||
- Local file access via URL schemes
|
||||
- Port scanning
|
||||
- Service enumeration
|
||||
|
||||
## Testing Approach
|
||||
Test URL parameters, file upload functionalities, and any feature that fetches external resources. Attempt to access internal resources, cloud metadata endpoints, and local services.
|
||||
@@ -1,130 +0,0 @@
|
||||
# OWASP Top 10 Security Testing Payloads
|
||||
|
||||
This directory contains comprehensive payload collections for testing applications against the OWASP Top 10 security risks (2021 edition). These payloads are intended for authorized security testing, penetration testing, and bug bounty hunting only.
|
||||
|
||||
## ⚠️ Legal Disclaimer
|
||||
|
||||
**IMPORTANT:** These payloads are for educational and authorized testing purposes only. Using these payloads against systems without explicit permission is illegal and unethical. Always obtain proper authorization before conducting security testing.
|
||||
|
||||
## Directory Structure
|
||||
|
||||
Each OWASP Top 10 category has its own directory containing:
|
||||
- **README.md** - Description of the vulnerability category
|
||||
- **Payload files** - Collections of test payloads specific to that category
|
||||
|
||||
## OWASP Top 10 (2021) Categories
|
||||
|
||||
### [A01 - Broken Access Control](./A01-Broken-Access-Control/)
|
||||
Testing payloads for access control vulnerabilities including:
|
||||
- Path Traversal
|
||||
- IDOR (Insecure Direct Object References)
|
||||
- Missing function level access control
|
||||
|
||||
### [A02 - Cryptographic Failures](./A02-Cryptographic-Failures/)
|
||||
Testing payloads for cryptographic weaknesses including:
|
||||
- Weak hashing algorithms
|
||||
- Hardcoded credentials
|
||||
- Insecure key storage
|
||||
|
||||
### [A03 - Injection](./A03-Injection/)
|
||||
Comprehensive injection payloads including:
|
||||
- **SQL Injection** - Database query manipulation
|
||||
- **XSS (Cross-Site Scripting)** - Client-side code injection
|
||||
- **Command Injection** - OS command execution
|
||||
- **LDAP Injection** - Directory service manipulation
|
||||
|
||||
### [A04 - Insecure Design](./A04-Insecure-Design/)
|
||||
Testing payloads for design flaws including:
|
||||
- Business logic vulnerabilities
|
||||
- Missing security controls
|
||||
- Rate limiting bypass
|
||||
|
||||
### [A05 - Security Misconfiguration](./A05-Security-Misconfiguration/)
|
||||
Testing payloads for configuration issues including:
|
||||
- Default credentials
|
||||
- Common misconfiguration paths
|
||||
- Directory listing
|
||||
|
||||
### [A06 - Vulnerable and Outdated Components](./A06-Vulnerable-Outdated-Components/)
|
||||
Reference lists of:
|
||||
- Known vulnerable libraries
|
||||
- Outdated components
|
||||
- Version detection strings
|
||||
|
||||
### [A07 - Identification and Authentication Failures](./A07-Identification-Authentication-Failures/)
|
||||
Testing payloads for authentication issues including:
|
||||
- Authentication bypass techniques
|
||||
- Weak password lists
|
||||
- Session manipulation
|
||||
|
||||
### [A08 - Software and Data Integrity Failures](./A08-Software-Data-Integrity-Failures/)
|
||||
Testing payloads for integrity issues including:
|
||||
- Deserialization attacks
|
||||
- Unsafe deserialization patterns
|
||||
|
||||
### [A09 - Security Logging and Monitoring Failures](./A09-Security-Logging-Monitoring-Failures/)
|
||||
Testing payloads for logging issues including:
|
||||
- Log injection attacks
|
||||
- CRLF injection in logs
|
||||
|
||||
### [A10 - Server-Side Request Forgery (SSRF)](./A10-Server-Side-Request-Forgery/)
|
||||
Testing payloads for SSRF vulnerabilities including:
|
||||
- Internal network access
|
||||
- Cloud metadata endpoints
|
||||
- Protocol handler abuse
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
1. **Authorization First**: Always obtain written permission before testing
|
||||
2. **Scope Definition**: Only test systems within the authorized scope
|
||||
3. **Responsible Disclosure**: Report vulnerabilities responsibly
|
||||
4. **Legal Compliance**: Follow all applicable laws and regulations
|
||||
5. **Ethical Testing**: Never cause damage or access sensitive data without permission
|
||||
|
||||
## Testing Methodology
|
||||
|
||||
1. **Reconnaissance**: Understand the target application
|
||||
2. **Vulnerability Identification**: Use payloads to identify potential issues
|
||||
3. **Exploitation**: Validate vulnerabilities safely
|
||||
4. **Documentation**: Record findings with evidence
|
||||
5. **Reporting**: Submit detailed vulnerability reports
|
||||
|
||||
## Payload Usage
|
||||
|
||||
Payloads can be used in various contexts:
|
||||
- **URL Parameters**: `?param=<payload>`
|
||||
- **POST Data**: Form fields and JSON/XML bodies
|
||||
- **Headers**: Custom HTTP headers
|
||||
- **Cookies**: Cookie values
|
||||
- **File Uploads**: File content and metadata
|
||||
|
||||
## Tools Integration
|
||||
|
||||
These payloads can be integrated with:
|
||||
- Burp Suite
|
||||
- OWASP ZAP
|
||||
- ffuf/wfuzz
|
||||
- SQLMap
|
||||
- Custom scripts
|
||||
|
||||
## Contributing
|
||||
|
||||
This is a living resource. Contributions of new payloads, techniques, or improvements are welcome. Please ensure all contributions:
|
||||
- Follow the existing structure
|
||||
- Include clear documentation
|
||||
- Focus on educational/testing value
|
||||
- Maintain ethical standards
|
||||
|
||||
## Resources
|
||||
|
||||
- [OWASP Top 10 Official Site](https://owasp.org/www-project-top-ten/)
|
||||
- [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
|
||||
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
|
||||
|
||||
## Version
|
||||
|
||||
Based on OWASP Top 10 - 2021
|
||||
|
||||
---
|
||||
|
||||
**Remember**: With great power comes great responsibility. Use these resources ethically and legally.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Open Redirect
|
||||
|
||||
## Description
|
||||
Open redirect vulnerabilities occur when a web application accepts user-controlled input that specifies a link to an external site and uses that link in a redirect. This can be used for phishing attacks or to bypass security controls.
|
||||
|
||||
## Common Attack Vectors
|
||||
- URL parameters (redirect, url, return, next)
|
||||
- Login/logout redirect parameters
|
||||
- OAuth callback URLs
|
||||
- Error page redirects
|
||||
|
||||
## Testing Approach
|
||||
Submit external URLs in redirect parameters to test if the application redirects to arbitrary external sites.
|
||||
|
||||
## Payloads
|
||||
See `open-redirect-payloads.txt` for a comprehensive list of open redirect payloads.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Path Traversal
|
||||
|
||||
## Description
|
||||
Path traversal (also known as directory traversal) is a web security vulnerability that allows an attacker to read arbitrary files on the server that is running an application. This might include application code and data, credentials for back-end systems, and sensitive operating system files.
|
||||
|
||||
## Common Attack Vectors
|
||||
- File download functionality
|
||||
- File upload functionality
|
||||
- Template inclusion
|
||||
- Image/document display features
|
||||
- Static resource serving
|
||||
|
||||
## Testing Approach
|
||||
Submit path traversal sequences (../, ..\.., etc.) in file parameters to attempt to access files outside the intended directory.
|
||||
|
||||
## Payloads
|
||||
See `path-traversal-payloads.txt` for a comprehensive list of path traversal payloads.
|
||||
@@ -4,19 +4,34 @@ A comprehensive collection of security testing resources and payloads for bug bo
|
||||
|
||||
## 📁 Repository Structure
|
||||
|
||||
### OWASP Top 10 Payloads
|
||||
This repository contains a complete collection of testing payloads organized by the OWASP Top 10 (2021) security risk categories.
|
||||
### Vulnerability Payloads by Type
|
||||
This repository contains a complete collection of testing payloads organized by vulnerability type.
|
||||
|
||||
- **[A01 - Broken Access Control](./OWASP-Top-10/A01-Broken-Access-Control/)** - Path traversal, IDOR, privilege escalation
|
||||
- **[A02 - Cryptographic Failures](./OWASP-Top-10/A02-Cryptographic-Failures/)** - Weak crypto, hardcoded credentials
|
||||
- **[A03 - Injection](./OWASP-Top-10/A03-Injection/)** - SQL, XSS, Command, LDAP injection
|
||||
- **[A04 - Insecure Design](./OWASP-Top-10/A04-Insecure-Design/)** - Business logic flaws
|
||||
- **[A05 - Security Misconfiguration](./OWASP-Top-10/A05-Security-Misconfiguration/)** - Default credentials, misconfigurations
|
||||
- **[A06 - Vulnerable Components](./OWASP-Top-10/A06-Vulnerable-Outdated-Components/)** - Known vulnerable libraries
|
||||
- **[A07 - Authentication Failures](./OWASP-Top-10/A07-Identification-Authentication-Failures/)** - Auth bypass, weak passwords
|
||||
- **[A08 - Integrity Failures](./OWASP-Top-10/A08-Software-Data-Integrity-Failures/)** - Deserialization attacks
|
||||
- **[A09 - Logging Failures](./OWASP-Top-10/A09-Security-Logging-Monitoring-Failures/)** - Log injection
|
||||
- **[A10 - SSRF](./OWASP-Top-10/A10-Server-Side-Request-Forgery/)** - Server-side request forgery
|
||||
**Injection Vulnerabilities:**
|
||||
- **[SQL Injection](./SQL-Injection/)** - Database query manipulation
|
||||
- **[XSS (Cross-Site Scripting)](./XSS/)** - Client-side code injection
|
||||
- **[Command Injection](./Command-Injection/)** - OS command execution
|
||||
- **[LDAP Injection](./LDAP-Injection/)** - Directory service manipulation
|
||||
- **[Log Injection](./Log-Injection/)** - Log file manipulation
|
||||
|
||||
**Access Control Vulnerabilities:**
|
||||
- **[Path Traversal](./Path-Traversal/)** - Directory traversal attacks
|
||||
- **[IDOR](./IDOR/)** - Insecure direct object references
|
||||
- **[Open Redirect](./Open-Redirect/)** - Unvalidated redirects
|
||||
|
||||
**Authentication & Authorization:**
|
||||
- **[Authentication Bypass](./Authentication-Bypass/)** - Auth bypass techniques
|
||||
- **[Weak Passwords](./Weak-Passwords/)** - Common weak passwords and defaults
|
||||
|
||||
**Server-Side Vulnerabilities:**
|
||||
- **[SSRF](./SSRF/)** - Server-side request forgery
|
||||
- **[Deserialization](./Deserialization/)** - Insecure deserialization
|
||||
|
||||
**Configuration & Design:**
|
||||
- **[Security Misconfiguration](./Security-Misconfiguration/)** - Default credentials, misconfigurations
|
||||
- **[Business Logic](./Business-Logic/)** - Business logic flaws
|
||||
- **[Weak Cryptography](./Weak-Cryptography/)** - Weak crypto implementations
|
||||
- **[Vulnerable Components](./Vulnerable-Components/)** - Known vulnerable libraries
|
||||
|
||||
## 🎯 Purpose
|
||||
|
||||
@@ -41,8 +56,8 @@ Unauthorized testing is illegal and unethical. Always follow responsible disclos
|
||||
|
||||
## 🚀 Getting Started
|
||||
|
||||
1. Navigate to the [OWASP-Top-10](./OWASP-Top-10/) directory
|
||||
2. Choose the vulnerability category you want to test
|
||||
1. Choose the vulnerability type you want to test from the list above
|
||||
2. Navigate to the corresponding directory
|
||||
3. Review the README.md for context and methodology
|
||||
4. Use the payload files in your authorized testing
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
# SQL Injection
|
||||
|
||||
## Description
|
||||
SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. This can allow an attacker to view, modify, or delete data that they are not normally able to retrieve.
|
||||
|
||||
## Common Attack Vectors
|
||||
- Login forms
|
||||
- Search fields
|
||||
- URL parameters
|
||||
- HTTP headers
|
||||
- Cookie values
|
||||
|
||||
## Testing Approach
|
||||
Submit malicious SQL syntax in input fields and observe application behavior, error messages, and response times to identify SQL injection vulnerabilities.
|
||||
|
||||
## Payloads
|
||||
See `sql-injection-payloads.txt` for a comprehensive list of SQL injection payloads.
|
||||
@@ -0,0 +1,18 @@
|
||||
# Server-Side Request Forgery (SSRF)
|
||||
|
||||
## Description
|
||||
Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This can lead to unauthorized access to internal systems, cloud metadata endpoints, or other sensitive resources.
|
||||
|
||||
## Common Attack Vectors
|
||||
- URL parameters
|
||||
- File upload (via URL)
|
||||
- Webhook endpoints
|
||||
- PDF generators
|
||||
- Image processing services
|
||||
- API integrations
|
||||
|
||||
## Testing Approach
|
||||
Submit URLs pointing to internal resources, cloud metadata endpoints, or localhost to test if the application makes requests to those resources.
|
||||
|
||||
## Payloads
|
||||
See `ssrf-payloads.txt` for a comprehensive list of SSRF payloads.
|
||||
@@ -0,0 +1,26 @@
|
||||
# Security Misconfiguration
|
||||
|
||||
## Description
|
||||
Security misconfiguration vulnerabilities arise from insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. These are among the most common security issues.
|
||||
|
||||
## Common Issues
|
||||
- Default credentials
|
||||
- Unnecessary features enabled
|
||||
- Directory listing enabled
|
||||
- Detailed error messages
|
||||
- Outdated software
|
||||
- Misconfigured security headers
|
||||
- Open cloud storage buckets
|
||||
|
||||
## Common Attack Vectors
|
||||
- Default admin interfaces
|
||||
- Configuration files exposed
|
||||
- Backup files accessible
|
||||
- Development/debug modes enabled
|
||||
- Unnecessary services running
|
||||
|
||||
## Testing Approach
|
||||
Test for common misconfigurations, default credentials, exposed configuration files, and security header weaknesses.
|
||||
|
||||
## Payloads
|
||||
See `default-credentials-payloads.txt` and `misconfiguration-paths-payloads.txt` for comprehensive lists of security misconfiguration tests.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Vulnerable Components
|
||||
|
||||
## Description
|
||||
Using components with known vulnerabilities can lead to serious security breaches. This includes libraries, frameworks, and other software modules that run with the same privileges as the application. Vulnerable components can be exploited to achieve various attacks ranging from data theft to server takeover.
|
||||
|
||||
## Common Issues
|
||||
- Outdated libraries
|
||||
- Unpatched frameworks
|
||||
- Deprecated components
|
||||
- Components with known CVEs
|
||||
- Unnecessary dependencies
|
||||
|
||||
## Common Attack Vectors
|
||||
- Third-party libraries
|
||||
- JavaScript frameworks
|
||||
- Server-side frameworks
|
||||
- CMS platforms
|
||||
- Plugins and extensions
|
||||
- Operating system packages
|
||||
|
||||
## Testing Approach
|
||||
Identify the versions of components used by the application and check them against vulnerability databases for known security issues.
|
||||
|
||||
## Resources
|
||||
See `vulnerable-components-list.txt` for a list of commonly vulnerable components and their indicators.
|
||||
@@ -0,0 +1,18 @@
|
||||
# Weak Cryptography
|
||||
|
||||
## Description
|
||||
Weak cryptography vulnerabilities occur when applications use outdated, weak, or improperly implemented cryptographic algorithms and protocols. This can lead to data exposure, man-in-the-middle attacks, and other security breaches.
|
||||
|
||||
## Common Issues
|
||||
- Use of weak hashing algorithms (MD5, SHA1)
|
||||
- Weak encryption algorithms (DES, RC4)
|
||||
- Hardcoded cryptographic keys
|
||||
- Insufficient key lengths
|
||||
- Improper SSL/TLS configuration
|
||||
- Predictable random number generation
|
||||
|
||||
## Testing Approach
|
||||
Identify cryptographic implementations and test for weak algorithms, hardcoded secrets, and improper configurations.
|
||||
|
||||
## Payloads
|
||||
See `weak-crypto-payloads.txt` for a comprehensive list of weak cryptography indicators and test cases.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Weak Passwords
|
||||
|
||||
## Description
|
||||
Weak password vulnerabilities occur when systems allow or use passwords that are easily guessable or commonly used. This includes default passwords, dictionary words, and simple patterns that can be easily compromised through brute force or dictionary attacks.
|
||||
|
||||
## Common Attack Vectors
|
||||
- Login forms
|
||||
- Account creation
|
||||
- Password reset
|
||||
- Administrative interfaces
|
||||
- Default credentials on devices/services
|
||||
|
||||
## Testing Approach
|
||||
Test systems with common weak passwords, default credentials, and dictionary words to identify weak password policies or default configurations.
|
||||
|
||||
## Payloads
|
||||
See `weak-passwords-payloads.txt` for a comprehensive list of common weak passwords and default credentials.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Cross-Site Scripting (XSS)
|
||||
|
||||
## Description
|
||||
Cross-Site Scripting (XSS) attacks are a type of injection in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.
|
||||
|
||||
## Types of XSS
|
||||
- **Reflected XSS**: Script is reflected off the web server
|
||||
- **Stored XSS**: Script is permanently stored on the target server
|
||||
- **DOM-based XSS**: Vulnerability exists in client-side code
|
||||
|
||||
## Common Attack Vectors
|
||||
- Input fields
|
||||
- URL parameters
|
||||
- HTTP headers
|
||||
- File uploads
|
||||
- Comment sections
|
||||
|
||||
## Testing Approach
|
||||
Submit JavaScript code in various input points and observe if the code gets executed in the browser.
|
||||
|
||||
## Payloads
|
||||
See `xss-payloads.txt` for a comprehensive list of XSS payloads.
|
||||
Reference in New Issue
Block a user