├── .gitattributes ├── 1) Recon ├── Active Recon │ └── README.md ├── Passive Recon │ └── README.md └── README.md ├── 2) Reverse Engineering API Documentation └── README.md └── README.md /.gitattributes: -------------------------------------------------------------------------------- 1 | # Auto detect text files and perform LF normalization 2 | * text=auto 3 | -------------------------------------------------------------------------------- /1) Recon/Active Recon/README.md: -------------------------------------------------------------------------------- 1 | # Objectives of Active Recon 2 | Active reconnaissance in API penetration testing involves directly interacting with the target system to uncover as much information as possible regarding its API infrastructure. The essential objectives of active reconnaissance include: 3 | - Identifying Target APIs: Actively seek out the target's APIs through hands-on interaction. 4 | - Scanning Systems: Utilize scanning tools to identify live systems and their open ports. 5 | - Enumerating Open Ports: Determine which ports are open and the types of services they are hosting, specifically those utilizing HTTP. 6 | - Discovering Services Using HTTP: Since APIs typically communicate over HTTP/HTTPS, identifying such services is crucial. 7 | - Uncovering API-Related Directories: By scanning web applications, researchers can discover directories related to APIs. 8 | - Building Out the Target's API Attack Surface: The ultimate goal is to piecemeal together a comprehensive overview of the target's API ecosystem to identify potential vulnerabilities. 9 | 10 | # Techniques and Tools for Active Reconnaissance 11 | A variety of tools are employed during active reconnaissance, each serving specific functions, from scanning ports to enumerating services and discovering API endpoints. 12 | 13 | ## 1. Nmap 14 | Nmap is a versatile tool for discovering services and vulnerabilities on a network. 15 | 16 | ### Nmap Commands 17 | This command employs default scripts (`-sC`) and service enumeration (`-sV`) against the target, saving the output in three formats for later analysis. 18 | ``` 19 | nmap -sC -sV [target address or network range] -oA nameofoutput 20 | ``` 21 | Quickly checks all 65,535 TCP ports to identify any running services, their application versions, and the operating system. 22 | ``` 23 | nmap -p- [target address] -oA allportscan 24 | ``` 25 | Uses the NSE script `http-enum` to enumerate web services on standard HTTP and HTTPS ports as well as common alternative web ports. 26 | ``` 27 | nmap -sV --script=http-enum -p 80,443,8000,8080 28 | ``` 29 | 30 | ## 2. OWASP Amass 31 | OWASP Amass gathers information about a target’s external network and services using Open Source Intelligence (OSINT). 32 | 33 | ### OWASP Amass Commands 34 | Before using Amass, enhance its capabilities with API keys. This command fetches a sample `config.ini` file. Then, obtain and add API keys to this file to improve the tool’s scanning efficiency. 35 | ``` 36 | sudo curl https://raw.githubusercontent.com/OWASP/Amass/master/examples/config.ini > ~/.config/amass/config.ini 37 | ``` 38 | This scan will reveal API subdomains that could be of particular interest, like `legacy-api.target-name.com`, suggesting potential vulnerabilities. 39 | ``` 40 | amass enum -active -d target-name.com |grep api 41 | ``` 42 | Use the intel command to collect SSL certificates, search reverse Whois records, and find ASN IDs. 43 | ``` 44 | amass intel -addr [target IPs] 45 | ``` 46 | Domains can be passed to intel with the whois option to perform a reverse Whois lookup. 47 | ``` 48 | amass intel -d [target domain] –whois 49 | ``` 50 | Passively enumerated subdomains. 51 | ``` 52 | amass enum -passive -d [target domain] 53 | ``` 54 | Active enum scan does most scans as the passive one, however it will add domain name resolution, attempt DNS zone transfers, and SSL certificate information. 55 | ``` 56 | amass enum -active -d [target domain] 57 | ``` 58 | Add the -brute option to brute-force subdomains, -w to specify the API_superlist wordlist, and then the -dir option to send the output to the directory of your choice. 59 | ``` 60 | amass enum -active -brute -w /usr/share/wordlists/API_superlist -d [target domain] -dir [directory name] 61 | ``` 62 | 63 | ## 3. Gobuster 64 | Gobuster is a command-line tool for brute-forcing URIs and DNS subdomains using wordlists. 65 | 66 | ### Gobuster Commands 67 | This scan will discover API directories by brute-forcing paths from a wordlist. 68 | ``` 69 | gobuster dir -u target-name.com:8000 -w /home/hapihacker/api/wordlists/common_apis_160 70 | ``` 71 | 72 | ## 4. Kiterunner 73 | Kiterunner offers a novel approach to discovering API endpoints by simulating complex API request patterns beyond the customary HTTP GET requests. 74 | 75 | ### Kiterunner Commands 76 | This command allows Kiterunner to attempt common API request types and paths, identifying potential API endpoints. 77 | ``` 78 | kr scan HTTP://127.0.0.1 -w ~/api/wordlists/data/kiterunner/routes-large.kite 79 | ``` 80 | Use a text wordlist rather than a .kite file. 81 | ``` 82 | kr brute -w ~/wordlist.txt 83 | ``` 84 | 85 | ### DevTools 86 | DevTools in browsers is an invaluable tool for interactive exploration of web applications and APIs. By monitoring network traffic in DevTools, researchers can identify API calls, inspect and modify them, and even resend modified requests to observe behavior. This helps in understanding how the application interacts with its backend APIs. -------------------------------------------------------------------------------- /1) Recon/Passive Recon/README.md: -------------------------------------------------------------------------------- 1 | # Objectives of Passive Recon 2 | - Identify API endpoints. 3 | - Discover exposed credentials and sensitive information. 4 | - Collect information on API versions and documentation. 5 | - Understand the API’s purpose and potential business logic flaws. 6 | - Find API keys, JSON Web Tokens (JWT), and other secrets. 7 | 8 | # Techniques and Tools for Passive Recon 9 | ## 1. Google Dorking 10 | Google Dorking leverages specific search queries to find information that is not easily visible through regular search attempts. 11 | 12 | ### Google Dorking Queries 13 | Finds WordPress user directories. 14 | ``` 15 | inurl:"/wp-json/wp/v2/users" 16 | ``` 17 | Locates API key files. 18 | ``` 19 | intitle:"index.of" intext:"api.txt" 20 | ``` 21 | Unveils API directories. 22 | ``` 23 | inurl:"/api/v1" intext:"index of /" 24 | ``` 25 | Searches for sites with a potential XenAPI SQL injection vulnerability. 26 | ``` 27 | ext:php inurl:"api.php?action=" 28 | ``` 29 | Lists potentially exposed API keys. 30 | ``` 31 | intitle:"index of" api_key OR "api key" OR apiKey -pool 32 | ``` 33 | 34 | ## 2. Git Dorking 35 | Searching GitHub and other repository hosting services for sensitive information disclosure. 36 | 37 | ### GitHub Search Techniques 38 | - Search by filename (e.g., filename:swagger.json) or extension (e.g., extension:.json) for specific sensitive files. 39 | - Look for secrets using keywords in the organization’s GitHub repositories such as "api key," "authorization: Bearer," "access_token," "secret," or "token." 40 | - Investigate various GitHub repository tabs like Code, Issues, and Pull requests to discover potential weaknesses. 41 | 42 | ## 3. TruffleHog 43 | A tool for automatically discovering exposed secrets in git repositories. 44 | 45 | ### Using TruffleHog 46 | This command initiates a scan of the specified organization's GitHub repositories for secrets. 47 | ``` 48 | sudo docker run -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --org=target-name 49 | ``` 50 | 51 | ## 4. API Directories 52 | Platforms like ProgrammableWeb (https://www.programmableweb.com/apis/directory) provide extensive data on APIs. 53 | 54 | ### ProgrammableWeb API Directory 55 | - Access a searchable database of over 23,000 APIs. 56 | - Find information such as API endpoints, version details, business logic, and SDKs. 57 | 58 | ## 5. Shodan 59 | Shodan is instrumental in discovering internet-facing APIs and devices. 60 | 61 | ### Useful Shodan Queries 62 | Basic search for a target’s domain name. 63 | ``` 64 | hostname:"targetname.com" 65 | ``` 66 | Filters results to those responding with JSON or XML. 67 | ``` 68 | "content-type: application/json" and "content-type: application/xml" 69 | ``` 70 | Limits results to those with successful responses. 71 | ``` 72 | "200 OK" 73 | ``` 74 | Searches for web applications using the WordPress API. 75 | ``` 76 | "wp-json" 77 | ``` 78 | 79 | ## 6. The Wayback Machine 80 | The Wayback Machine is valuable for examining historical versions of a target’s API or web presence. 81 | 82 | ### Using The Wayback Machine 83 | - Check for changes in the API documentation to find deprecated or "zombie" APIs. 84 | - Analyze alterations to web pages where APIs were previously advertised. -------------------------------------------------------------------------------- /1) Recon/README.md: -------------------------------------------------------------------------------- 1 | # API Recon Intro 2 | API Recon is a crucial initial step in API penetration testing aimed at uncovering the API attack surface of a target. The process is divided into passive and active techniques, focusing on identifying how an API can be found and utilized based on its intended use—ranging from public, partner, to private APIs. 3 | 4 | # Types of APIs Based on Accessibility 5 | ## 1. Public APIs 6 | Accessibility: Meant to be easily found and used by end-users. 7 | Authentication: May not require authentication if only public information is handled. Otherwise, authentication is typically needed. 8 | Documentation: Providers share documentation that is user-friendly and easily accessible. 9 | ## 2. Partner APIs 10 | Accessibility: Intended for use exclusively by partners of the provider and might be harder to locate without partnership status. 11 | Documentation: Documented, though often limited to partners. 12 | ## 3. Private APIs 13 | Accessibility: Used within an organization, generally not intended for external use. 14 | Documentation: Less documented than partner APIs, if documented at all. 15 | 16 | # API Recon Techniques 17 | ## Passive Recon 18 | Objective: Discover APIs and their documentation without engaging the target system directly. 19 | ## Active Recon 20 | Involves direct interaction with the target to discover APIs. 21 | 22 | # Web API Indicators 23 | Identifying APIs can be straightforward by looking for specific indicators, such as: 24 | - URL Naming Schemes: e.g., https://api.target-name.com/v1, https://target-name.com/docs 25 | - Directory Names: /api, /v1, /graphql, /swagger.json 26 | - Subdomains: e.g., api.target-name.com, dev.target-name.com 27 | - HTTP Headers: Content-Type indicating JSON or XML usage 28 | - HTTP Responses: Messages like {"message": "Missing Authorization token"} 29 | - Third-Party Sources for Discovering APIs: 30 | - GitHub: https://github.com/ 31 | - Postman: https://www.postman.com/explore/apis 32 | - ProgrammableWeb: https://www.programmableweb.com/apis/directory 33 | - APIs Guru: https://apis.guru/ 34 | - RapidAPI Hub: https://rapidapi.com/search/ 35 | -------------------------------------------------------------------------------- /2) Reverse Engineering API Documentation/README.md: -------------------------------------------------------------------------------- 1 | # Reverse Engineering API Documentation 2 | This section provides a systematic approach to reverse engineer an API when documentation or specification files are unavailable. It introduces manual and automatic methods to build your collection of API requests, aiding in the discovery of potential vulnerabilities and attack surfaces. 3 | 4 | # Manual Request Collection with Postman 5 | ## 1) Creating a Workspace 6 | - Create a workspace in Postman to organize your collections. 7 | 8 | ## 2) Using the Postman Proxy 9 | 1. Click the `Capture Requests` button at the bottom right of Postman. 10 | 2. In the "Capture requests" window, enable the proxy, ensuring the port matches the FoxyProxy setup. 11 | 3. Add your target URL in the "URL must contain" field and initiate the request capture by clicking `Start Capture`. 12 | 4. Use FoxyProxy to proxy the web browser's traffic through Postman and navigate through the web application's entire functionality: 13 | - Registration, login, visiting profiles, posting comments, etc. 14 | - Make sure to interact thoroughly, as missing functionalities could lead to blind spots in the API's attack surface. 15 | 16 | ## 3) Building the API Collection 17 | After capturing the necessary data: 18 | 1. Stop the proxy in Postman. 19 | 2. Create a new collection named "API Proxy Collection". 20 | 3. Organize requests by endpoints, grouping similar requests, and renaming them for better clarity. 21 | 22 | # Automatic Documentation with mitmproxy2swagger 23 | Another efficient way of reverse engineering an API is by capturing web traffic with mitmweb and then using mitmproxy2swagger to generate an Open API 3.0 specification. 24 | 25 | ## 1) Setting Up mitmweb 26 | 1. Start mitmweb to listen on port `8080`. 27 | ``` 28 | mitmweb 29 | ``` 30 | 31 | ## 2) Capturing and Saving Requests 32 | 1. Use FoxyProxy to proxy the web browser's traffic through mitmweb and navigate through the web application's entire functionality: 33 | - Registration, login, visiting profiles, posting comments, etc. 34 | - Make sure to interact thoroughly, as missing functionalities could lead to blind spots in the API's attack surface. 35 | 2. Save the session to a file named `flows` for further processing. 36 | 37 | ## 3) Generating the Open API Documentation 38 | 39 | 1. Convert the `flows` file into an Open API 3.0 YAML documentation. 40 | ``` 41 | $sudo mitmproxy2swagger -i /Downloads/flows -o spec.yml -p http://api.example.com -f flow 42 | ``` 43 | 2. Edit the `spec.yml` file to ensure no endpoints are overlooked and update the file's title for clarity. 44 | - Remove `ignore:` from endpoints you wish to include using a text editor. 45 | - Validate and correct formatting by running the `mitmproxy2swagger` script again, adding `--examples` flag for enriched documentation. 46 | ``` 47 | sudo mitmproxy2swagger -i /Downloads/flows -o spec.yml -p http://api.example.com -f flow --examples 48 | ``` 49 | 50 | ## 4) Validation and Importation into Postman 51 | 1. Validate the YAML file using the Swagger Editor(https://editor.swagger.io/). You can also interact with the API and read the collected documentation on the site. 52 | 2. Import the validated YAML file into Postman as a collection for penetration testing purposes. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # API-Hacking-Notebook 2 | These are my personal notes for everything I learned regarding hacking APIs. Enjoy. 3 | 4 | # API Hacking Resources 5 | - https://www.apisecuniversity.com/ --------------------------------------------------------------------------------