## 17.5 API Exploitation Techniques ### API Exploitation in LLM Context API exploitation gets a whole lot scarier when you throw LLMs into the mix. The LLM acts like an automated client that attackers can manipulate through prompts. Traditional API security relies on the assumption that a human is on the other end, or at least a predictable script. LLMs blindly follow patterns, and that creates some unique openings for attackers. ### Why LLM-Driven APIs are Vulnerable 1. **Automated Exploitation**: Attackers can trick LLMs into launching rapid-fire attacks. 2. **No Security Awareness**: The LLM has no concept of "malicious" versus "legitimate"—it just follows instructions. 3. **Parameter Generation**: Since the LLM generates API parameters from prompts, injection risks skyrocket. 4. **Rate Limit Bypass**: A single user prompt can trigger a cascade of API calls. 5. **Credential Exposure**: LLMs have a bad habit of leaking API keys in their responses if you're not careful. ### Common API Exploitation Vectors - **Parameter tampering**: Modifying request parameters to do things they shouldn't. - **Mass assignment**: Sending unauthorized fields to update critical data. - **IDOR**: Accessing other users' resources by just guessing IDs. - **Rate limit bypass**: Getting around restrictions on how many requests you can make. - **Authentication bypass**: Skipping the login line entirely. ### 17.5.1 Parameter Tampering #### What is Parameter Tampering? Parameter tampering is exactly what it sounds like: messing with API request parameters to access unauthorized data or trigger unintended behavior. When an LLM generates API calls, attackers can manipulate prompts to force these tampered parameters into the request. #### Attack Scenario 1. A plugin makes an API call using parameters controlled by the user. 2. The attacker crafts a prompt to inject malicious values into those parameters. 3. The LLM obliges and generates an API call with the tampered data. 4. The API processes the request without checking if it makes sense. 5. Unauthorized action executes. #### Example Attack ### 17.5.1 API Enumeration and Discovery **Understanding API Enumeration:** API enumeration is the recon phase. Attackers systematically poke around for hidden or undocumented endpoints that might have weaker security than the public-facing ones. Companies often leave debug, admin, or internal endpoints exposed when they really shouldn't. **Why This Matters for LLM Plugins:** LLM plugins often talk to APIs that do a lot more than what the plugin exposes. If an attacker finds those extra endpoints, they can: 1. Bypass plugin-level security checks. 2. Access administrative functions. 3. Find debug interfaces that don't ask for passwords. 4. Identify internal APIs leaking sensitive data. **How the Enumeration Code Works:** 1. **Wordlist Generation**: It mixes common names (`users`, `admin`, `api`) with common actions (`list`, `get`, `create`) to guess endpoints. 2. **Path Pattern Testing**: It tries different URL structures like `/{endpoint}/{action}`, `/api/...`, and `/v1/...`. 3. **Response Code Analysis**: If it gets a 200 (OK), 401 (Unauthorized), or 403 (Forbidden), that endpoint **exists**. 404 means it's gone. 4. **Discovery Collection**: It builds a list of everything it found for the next stage of the attack. **Security Implications:** - `/admin/delete` might exist without checking who's calling it. - `/debug/config` could be spilling your configuration files. - `/internal/metrics` might leak system stats. - `/api/v1/export` could allow mass data extraction. **Defense Against Enumeration:** 1. **Consistent Error Responses**: Return 404 for both "doesn't exist" AND "unauthorized access". Don't give them a clue. 2. **Rate Limiting**: Cap requests from a single IP so they can't brute-force your endpoints. 3. **Web Application Firewall (WAF)**: Block these enumeration patterns. 4. **Minimal API Surface**: Don't put debug or admin endpoints in production. Just don't. 5. **Authentication on All Endpoints**: Even "hidden" URLs need a lock on the door. #### Endpoint discovery ```python import requests import itertools class APIEnumerator: """Discover hidden API endpoints""" def __init__(self, base_url): self.base_url = base_url self.discovered_endpoints = [] def enumerate_endpoints(self): """Brute force common endpoint patterns""" common_endpoints = [ 'users', 'admin', 'api', 'v1', 'v2', 'auth', 'login', 'logout', 'register', 'config', 'debug', 'test', 'internal', 'metrics' ] common_actions = [ 'list', 'get', 'create', 'update', 'delete', 'search', 'export', 'import' ] for endpoint, action in itertools.product(common_endpoints, common_actions): urls = [ f"{self.base_url}/{endpoint}/{action}", f"{self.base_url}/api/{endpoint}/{action}", f"{self.base_url}/v1/{endpoint}/{action}" ] for url in urls: if self.test_endpoint(url): self.discovered_endpoints.append(url) return self.discovered_endpoints def test_endpoint(self, url): """Test if endpoint exists""" try: response = requests.get(url) # 200 OK or 401/403 (exists but needs auth) return response.status_code in [200, 401, 403] except: return False ``` **Real-World Impact:** According to industry security research, a significant percentage of APIs have undocumented endpoints exposed, many with vulnerabilities. This highlights the importance of API enumeration in security testing. #### Parameter fuzzing ```python class ParameterFuzzer: """Discover hidden API parameters""" def __init__(self): self.common_params = [ 'id', 'user_id', 'username', 'email', 'token', 'api_key', 'debug', 'admin', 'limit', 'offset', 'format', 'callback', 'redirect', 'url' ] def fuzz_parameters(self, endpoint): """Test common parameter names""" results = [] for param in self.common_params: # Test with different values test_values = ['1', 'true', 'admin', '../', '">