# Uuid Security Audit

> Audit web applications for UUID security vulnerabilities. Use this skill whenever you need to analyze UUID implementations, identify predictable UUID patterns, assess password reset token security, or perform security testing on any system using UUIDs. Trigger this skill for any request about UUID security, identifier predictability, token brute-force risks, or when reviewing authentication/authorization systems that use UUIDs.

- Skill: `abelrguezr/uuid-security-audit` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/uuid-security-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/uuid-security-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/uuid-security-audit

---


# UUID Security Audit Skill

A skill for identifying and assessing UUID-related security vulnerabilities in web applications and systems.

## When to Use This Skill

Use this skill when:
- Analyzing web applications that use UUIDs for tokens, session IDs, or identifiers
- Reviewing password reset mechanisms that rely on UUIDs
- Assessing the security of any system using UUIDs as secrets or tokens
- Investigating potential identifier prediction vulnerabilities
- Performing security audits on authentication systems
- Understanding UUID version implications for security

## UUID Security Fundamentals

### UUID Versions and Security Implications

| Version | Generation Method | Security Risk |
|---------|-------------------|---------------|
| v1 | Time-based + MAC address | **HIGH** - Predictable, exposes system info |
| v2 | Time-based + local domain | **HIGH** - Similar to v1 |
| v3 | MD5 hash | **MEDIUM** - Deterministic from namespace+name |
| v4 | Random | **LOW** - Cryptographically random |
| v5 | SHA-1 hash | **MEDIUM** - Deterministic from namespace+name |

### UUID Structure

UUIDs follow this format: `xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx`

- **Position M** (13th character): Indicates UUID version (1-5)
- **Position N** (17th character): Indicates UUID variant

**Example:** `12345678-abcd-1a56-a539-103755193864`
- Version: `1` (v1 - time-based)
- Variant: `a` (standard UUID variant)

## Security Assessment Checklist

### 1. Identify UUID Version

Check the version digit in position 13:
- **v1/v2**: Time-based, potentially predictable
- **v3/v5**: Hash-based, deterministic
- **v4**: Random, most secure for tokens

### 2. Assess Predictability Risk

**High Risk Indicators:**
- UUID v1 used for security tokens (password resets, session IDs)
- Sequential UUID generation without randomness
- UUIDs generated in rapid succession
- No rate limiting on UUID-based endpoints

**Medium Risk Indicators:**
- UUID v3/v5 with predictable namespace/name
- UUIDs exposed in URLs or logs

**Low Risk Indicators:**
- UUID v4 with proper random number generator
- UUIDs used only as non-secret identifiers

### 3. Evaluate Implementation Context

**Critical Security Contexts** (require UUID v4 or better):
- Password reset tokens
- Session identifiers
- API keys or secrets
- Two-factor authentication codes
- Account recovery links

**Acceptable for Non-Secret Identifiers:**
- Database primary keys (when not exposed)
- Internal object references
- Non-sensitive tracking IDs

## Sandwich Attack Analysis

The sandwich attack exploits predictable UUID v1 generation in time-sensitive operations.

### Attack Scenario

1. **Prerequisites:**
   - Application uses UUID v1 for security tokens
   - Multiple accounts can trigger token generation
   - No rate limiting on token validation endpoints

2. **Attack Flow:**
   ```
   Attacker Account 1 → Request Token → Get UUID_A
   Victim Account     → Request Token → Get UUID_V (unknown)
   Attacker Account 2 → Request Token → Get UUID_B
   
   UUID_V falls between UUID_A and UUID_B
   Brute force the range to find UUID_V
   ```

3. **Detection Signs:**
   - UUIDs generated in sequence show predictable patterns
   - Time-based components increment sequentially
   - Same node ID (MAC address) across UUIDs

### Mitigation Strategies

1. **Use UUID v4** for all security-sensitive tokens
2. **Implement rate limiting** on token validation endpoints
3. **Add expiration** to all tokens (short-lived)
4. **Use cryptographically secure random** generators
5. **Consider alternative token formats** (JWT, opaque tokens)

## Testing Procedures

### Step 1: Enumerate UUID Usage

Identify where UUIDs appear in the application:
- URLs and query parameters
- API responses
- Cookies and headers
- Database schemas
- Log files

### Step 2: Analyze UUID Patterns

For each UUID found:
1. Extract the version digit (position 13)
2. Check for sequential patterns across multiple UUIDs
3. Look for consistent node IDs (last 12 characters in v1)
4. Assess if UUIDs are used as secrets or just identifiers

### Step 3: Test Predictability

If UUID v1 is detected:
1. Generate multiple UUIDs in quick succession
2. Compare the time-based components
3. Calculate the time delta between UUIDs
4. Estimate brute-force feasibility

### Step 4: Validate Token Endpoints

For each UUID-based endpoint:
1. Test with invalid UUIDs (check error messages)
2. Test rate limiting (rapid requests)
3. Test with sequential UUIDs
4. Check for information disclosure in responses

## Tools and Resources

### Detection Tools

- **UUID Detector (Burp Suite)**: Extension to identify UUIDs in traffic
- **Custom scripts**: Use `scripts/analyze-uuids.py` for batch analysis

### Attack Simulation (Educational Only)

- **Sandwich Tool**: https://github.com/Lupin-Holmes/sandwich
- **Custom brute-force**: Use `scripts/uuid-range-test.py` for testing

### References

- [UUID Security Best Practices](https://versprite.com/blog/universally-unique-identifiers/)
- [RFC 4122 - UUID Specification](https://datatracker.ietf.org/doc/html/rfc4122)
- [OWASP - Broken Authentication](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Authentication_Failures/)

## Reporting Findings

### Severity Classification

| Finding | Severity | Remediation |
|---------|----------|-------------|
| UUID v1 for security tokens | **Critical** | Switch to UUID v4 |
| No rate limiting on UUID endpoints | **High** | Implement rate limiting |
| UUID v3/v5 with predictable input | **Medium** | Use UUID v4 or random namespace |
| UUIDs in URLs (non-sensitive) | **Low** | Consider POST or headers |

### Report Template

```
## UUID Security Finding

**Location**: [endpoint/path]
**UUID Version**: [v1/v2/v3/v4/v5]
**Usage Context**: [password reset/session ID/etc.]
**Risk Level**: [Critical/High/Medium/Low]

**Description**:
[Explain the vulnerability]

**Evidence**:
[Sample UUIDs, request/response examples]

**Impact**:
[What an attacker could achieve]

**Remediation**:
[Specific steps to fix]
```

## Quick Reference

### UUID Version Detection

```python
# Position 13 (0-indexed: 14) indicates version
uuid_string = "12345678-abcd-1a56-a539-103755193864"
version = uuid_string[14]  # Returns '1' for v1
```

### Security Decision Tree

1. Is the UUID used as a secret/token? → **Must use v4**
2. Is the UUID exposed in URLs/logs? → **Prefer v4**
3. Is the UUID generated frequently? → **Avoid v1**
4. Is the UUID for internal use only? → **v1 acceptable**

## Common Mistakes to Avoid

❌ Using UUID v1 for password reset tokens
❌ Relying on UUID obscurity for security
❌ Not rate-limiting UUID validation endpoints
❌ Using predictable namespaces in v3/v5
❌ Exposing UUIDs in error messages

✅ Use UUID v4 for all security tokens
✅ Implement proper rate limiting
✅ Add token expiration
✅ Use cryptographically secure RNG
✅ Validate UUIDs server-side