Replay Attack Demonstration

Educational Demo for CSCE Software Security Class

This project demonstrates replay attacks and their prevention mechanisms in a practical, hands-on way. It includes both vulnerable and secure implementations to illustrate the difference.

📚 What is a Replay Attack?

A replay attack is a form of network attack where valid data transmission is maliciously or fraudulently repeated or delayed. An attacker intercepts (or captures) legitimate communication and "replays" it later to:

• Gain unauthorized access
• Duplicate transactions
• Bypass authentication mechanisms

Real-World Examples:

• Financial: Replaying a money transfer request multiple times
• Authentication: Reusing captured session tokens
• IoT: Replaying unlock commands to smart locks

🎯 Project Structure

csce_demo/
├── main.py              # Interactive menu for running demos
├── server.py            # Vulnerable server (NO replay protection)
├── server_secure.py     # Secure server (WITH replay protection)
├── client.py            # Legitimate client application
├── attacker.py          # Replay attack simulator
├── pyproject.toml       # Python dependencies
└── README.md            # This file

🚀 Quick Start

Prerequisites

• Python 3.10+
• Flask (for HTTP server)
• Requests (for HTTP client)

Installation

# Install dependencies
pip install flask requests

# Or using uv (if available)
uv add flask requests

Running the Demo

# Interactive menu (recommended for first-time users)
python main.py

The interactive menu provides three demonstrations:

1. Vulnerable Server Demo - Shows successful replay attack
2. Secure Server Demo - Shows replay attack prevention
3. Side-by-Side Comparison - Run both servers simultaneously

Manual Testing

You can also run components individually:

# Terminal 1: Start vulnerable server
python server.py

# Terminal 2: Run legitimate client
python client.py

# Terminal 3: Launch replay attack
python attacker.py

For secure server testing:

# Terminal 1: Start secure server
python server_secure.py

# Terminal 2: Modify client/attacker to use port 5001

🔍 How the Attack Works

Phase 1: Normal Authentication

Client → Server: POST /login (username, password)
Server → Client: 200 OK (token: abc123)

Phase 2: Legitimate Transaction

Client → Server: POST /transfer (token: abc123, to: bob, amount: $100)
Server → Client: 200 OK (transfer successful)

Phase 3: Replay Attack

Attacker → Server: POST /transfer (token: abc123, to: attacker, amount: $100)
Server → Client: 200 OK (transfer successful) ⚠️ VULNERABILITY!

The attacker uses the same token without needing credentials!

🛡️ Prevention Mechanisms

The secure server implements two layers of defense:

1. Timestamp Validation

# Request must include current timestamp
{
    "to": "bob",
    "amount": 100,
    "timestamp": 1705401234.567  # Current Unix timestamp
}

Server validates:

• Timestamp is within acceptable window (60 seconds)
• Rejects requests with old or future timestamps

2. Nonce (Number Used Once)

# Request must include unique nonce
{
    "to": "bob",
    "amount": 100,
    "nonce": "4f8a3c2d1b9e7f6a"  # Unique random value
}

Server validates:

• Nonce hasn't been used before
• Tracks used nonces in memory
• Cleans up expired nonces (5-minute window)

Combined Protection

# Secure request format
{
    "to": "bob",
    "amount": 100,
    "timestamp": 1705401234.567,
    "nonce": "4f8a3c2d1b9e7f6a"
}

Even if an attacker captures this request, they cannot:

• Replay immediately: Same nonce will be rejected
• Replay later: Timestamp will be too old
• Modify timestamp: Would need to generate new nonce

📊 Demo Scenarios

Scenario 1: Vulnerable System

1. Alice logs in → Token: abc123
2. Alice transfers $100 to Bob → Success
3. Attacker captures token: abc123
4. Attacker transfers $50 to self → Success ⚠️
5. Attacker transfers $50 to self → Success ⚠️
6. Attacker transfers $50 to self → Success ⚠️

Result: Alice loses $250 total (1 legitimate + 3 replay attacks)

Scenario 2: Secure System

1. Alice logs in → Token: xyz789
2. Alice transfers $100 (nonce: n1, time: t1) → Success
3. Attacker captures token & request
4. Attacker replays exact request → BLOCKED (duplicate nonce)
5. Attacker tries with old timestamp → BLOCKED (timestamp expired)
6. Attacker tries with new timestamp → BLOCKED (still needs valid nonce)

Result: Alice loses only $100 (legitimate transaction only) ✅

🔐 Key Security Lessons

Why Tokens Alone Aren't Enough

• Tokens can be intercepted (man-in-the-middle, network sniffing)
• Without context, same token = same access
• Unlimited validity = unlimited risk

Defense-in-Depth Approach

1. Timestamp: Limits replay window
2. Nonce: Prevents duplicate requests
3. Token Expiry: Limits token lifetime
4. HTTPS: Encrypts communication (not shown in demo)
5. Request Signing: Cryptographic verification (advanced)

Production Recommendations

• Always use HTTPS/TLS
• Implement both timestamp AND nonce validation
• Use short token expiration (5-15 minutes)
• Consider request signing with HMAC/JWT
• Log and monitor for replay attempt patterns
• Implement rate limiting

🧪 Testing the Security

Test 1: Replay After Logout

# In vulnerable system
1. Login and capture token
2. Logout
3. Use captured token → Still works! ⚠️

# In secure system
1. Login and capture token
2. Logout
3. Use captured token → Rejected ✅

Test 2: Delayed Replay

# In vulnerable system
1. Capture request at 10:00 AM
2. Replay at 10:05 AM → Still works! ⚠️

# In secure system
1. Capture request at 10:00 AM (timestamp: t1)
2. Replay at 10:05 AM → Rejected (timestamp too old) ✅

Test 3: Modified Replay

# Attacker tries to be clever
1. Capture: {to: "bob", amount: 100, nonce: "n1", time: t1}
2. Modify: {to: "attacker", amount: 1000, nonce: "n1", time: t2}
3. Replay → Rejected (nonce already used) ✅

📖 Educational Use

For Instructors

This demo is designed for classroom use:

• Duration: 20-30 minutes for full demonstration
• Prerequisites: Basic understanding of HTTP, REST APIs
• Learning Objectives:
  • Understand replay attack mechanics
  • Learn defense mechanisms (timestamp, nonce)
  • Appreciate defense-in-depth security

Discussion Points

1. Why is timestamp validation alone insufficient?
2. What are the trade-offs of nonce storage?
3. How does HTTPS/TLS relate to replay protection?
4. What other attacks might this system be vulnerable to?
5. How would you implement this in a distributed system?

Hands-On Exercises

1. Modify the attacker to try bypassing timestamp validation
2. Implement request signing using HMAC
3. Add rate limiting to prevent brute-force
4. Create a distributed nonce store using Redis
5. Implement token refresh mechanisms

⚠️ Security Disclaimer

This code is intentionally vulnerable for educational purposes.

• DO NOT use the vulnerable server in production
• DO NOT use this code as a template for real applications
• Always follow security best practices in production code
• This demo simplifies many real-world complexities

🔗 Additional Resources

• OWASP: Replay Attack
• RFC 6749: OAuth 2.0
• JWT Best Practices
• NIST: Authentication Guidelines

📝 License

Educational use only. For CSCE Software Security class demonstrations.

---

Remember: Security is not a feature you add at the end—it must be designed in from the start. This demo shows why security by design matters! 🛡️