business-logic-flaws-ai-generated-code

What this skill does

# Business Logic Vulnerabilities in AI-Generated Code

## The Subtlety of Logic Flaws

According to Contrast Security:

> "Business logic flaws in AI-generated code are particularly insidious because they **often pass all functional tests** while creating significant security vulnerabilities."

These vulnerabilities arise from the AI's **lack of understanding of business context** and security implications.

## 1.5.1 Race Conditions

### The Problem

Race conditions occur when multiple requests access shared resources simultaneously without proper synchronization. The AI generates "correct" code for single-user scenarios but fails to consider concurrent access.

### AI-Generated Vulnerable Code

```javascript
// Prompt: "Implement flash sale with limited quantity"
let availableStock = 100;

app.post('/api/purchase', async (req, res) => {
    const { userId, quantity } = req.body;

    // ❌ VULNERABLE: Race condition - multiple requests can pass this check
    if (availableStock >= quantity) {
        // Time window where multiple requests see stock as available
        availableStock -= quantity;

        // ❌ VULNERABLE: Database update happens after check
        await db.orders.create({
            userId,
            quantity,
            timestamp: Date.now()
        });

        await db.products.update(
            { id: 'flash-sale-item' },
            { stock: availableStock }
        );

        res.json({ success: true, remaining: availableStock });
    } else {
        res.status(400).json({ error: 'Insufficient stock' });
    }
});

// Attack: Send 100 concurrent requests for 1 item each
// Result: Could sell 200+ items when only 100 available
```

### Why This Is Vulnerable

**The Race Condition Timeline:**

```
Time    Request A            Request B            Stock
T0      Read stock: 100      Read stock: 100      100
T1      Check: 100 >= 1 ✓    Check: 100 >= 1 ✓    100
T2      stock = 99           stock = 99           100
T3      Update DB: 99        -                    99
T4      -                    Update DB: 99        99
Result: Both purchases succeed, but stock should be 98!
```

**With 100 concurrent requests:**
- All read stock = 100 at T0
- All pass check at T1
- All decrement to 99 at T2
- Final stock = 99 (should be 0)
- **Oversold by 99 items!**

### Real-World Impact

**Flash Sale Scenarios:**
- Limited edition product: 100 units
- 1000 customers try to purchase
- Race condition allows 200+ purchases
- Company must fulfill or refund
- Loss: product cost × oversold quantity
- Reputation damage

**Financial Services:**
- Account balance: $1000
- Concurrent withdrawals of $800 each
- Both succeed (race condition)
- Account balance: -$600
- Bank loses money

**Documented Incident:**
- Major retailer flash sale: 100 units
- 10,000 customers rushed to buy
- Race condition allowed **1,500 purchases**
- Loss: **$500,000** (product cost + shipping + reputation)

### Secure Implementation

#### Option 1: Database Transactions with Locking

```javascript
// ✅ SECURE: Using database transactions and locks
const { Sequelize, Transaction } = require('sequelize');

app.post('/api/purchase', async (req, res) => {
    const { userId, quantity } = req.body;

    // ✅ SECURE: Use database transaction with row locking
    const transaction = await sequelize.transaction({
        isolationLevel: Transaction.ISOLATION_LEVELS.SERIALIZABLE
    });

    try {
        // ✅ SECURE: Lock the product row during read
        const product = await Product.findOne({
            where: { id: 'flash-sale-item' },
            lock: transaction.LOCK.UPDATE,
            transaction
        });

        if (product.stock >= quantity) {
            // ✅ SECURE: Atomic update
            await product.decrement('stock', {
                by: quantity,
                transaction
            });

            // Create order
            const order = await Order.create({
                userId,
                productId: product.id,
                quantity,
                price: product.price * quantity,
                timestamp: Date.now()
            }, { transaction });

            // ✅ SECURE: Commit only if all operations succeed
            await transaction.commit();

            res.json({
                success: true,
                orderId: order.id,
                remaining: product.stock - quantity
            });
        } else {
            await transaction.rollback();
            res.status(400).json({
                error: 'Insufficient stock',
                available: product.stock
            });
        }
    } catch (error) {
        await transaction.rollback();

        // ✅ SECURE: Log error securely
        logger.error('Purchase failed', {
            userId,
            error: error.code,
            timestamp: new Date().toISOString()
        });

        res.status(500).json({ error: 'Purchase failed' });
    }
});
```

#### Option 2: Redis Distributed Locking

```javascript
// ✅ SECURE: Alternative using Redis for distributed locking
const Redis = require('ioredis');
const Redlock = require('redlock');

const redis = new Redis();
const redlock = new Redlock([redis], {
    driftFactor: 0.01,
    retryCount: 10,
    retryDelay: 200,
    retryJitter: 200
});

app.post('/api/purchase-redis', async (req, res) => {
    const { userId, quantity } = req.body;
    const lockKey = 'lock:flash-sale-item';

    try {
        // ✅ SECURE: Acquire distributed lock
        const lock = await redlock.acquire([lockKey], 5000);

        try {
            const stock = await redis.get('stock:flash-sale-item');

            if (parseInt(stock) >= quantity) {
                // ✅ SECURE: Atomic decrement
                const newStock = await redis.decrby('stock:flash-sale-item', quantity);

                // Record order
                await saveOrder(userId, quantity);

                res.json({ success: true, remaining: newStock });
            } else {
                res.status(400).json({ error: 'Insufficient stock' });
            }
        } finally {
            // ✅ SECURE: Always release lock
            await lock.release();
        }
    } catch (error) {
        if (error.name === 'LockError') {
            res.status(503).json({ error: 'System busy, please retry' });
        } else {
            res.status(500).json({ error: 'Purchase failed' });
        }
    }
});
```

### Why AI Generates Race Conditions

**1. Single-Request Testing:**
- AI tests with one request at a time
- Functional test passes: "Can I purchase?" ✓
- Never tests concurrent requests
- Race condition invisible in single-threaded test

**2. Synchronous Thinking:**
- AI generates code as if sequential
- Doesn't reason about concurrent execution
- Treats database as instant (no time gap)

**3. Simplicity Over Correctness:**
- Simple check-then-update pattern
- No transactions (complex to generate)
- No locking (requires understanding concurrency)

---

## 1.5.2 Integer Overflow and Business Logic Flaws

### The Problem

AI generates calculations that work for normal inputs but fail (often catastrophically) with edge cases or malicious inputs.

### AI-Generated Vulnerable Code

```python
# Prompt: "Calculate shopping cart total with discounts"
def calculate_cart_total(items, discount_percent=0):
    total = 0

    for item in items:
        # ❌ VULNERABLE: No validation of negative quantities
        subtotal = item['price'] * item['quantity']
        total += subtotal

    # ❌ VULNERABLE: No validation of discount range
    discount_amount = total * (discount_percent / 100)
    final_total = total - discount_amount

    return final_total

# Attack vectors:
# 1. items = [{'price': 100, 'quantity': -10}]  # Negative total
# 2. discount_percent = 150  # Final total becomes negative
# 3. items = [{'price': 999999999, 'quantity': 999999999}]  # Integer overflow
```

### Attack Scenarios

**Attack 1: Negative Quantities**
```python
items = [
    {'price': 100