Skip to main content

Chương 21: Business Logic Vulnerabilities

Khái niệm

Business Logic Vulnerabilities là lỗi trong business rules của ứng dụng — không phải lỗi kỹ thuật như injection hay XSS, mà là logic lỗi: ứng dụng làm điều gì đó không đúng với business intent.

Mức độ nguy hiểm: Biến thiên — Từ fraud nhỏ đến financial loss lớn.

Đặc điểm: Khó detect bằng automated tools. Đòi hỏi hiểu business context.


Các loại Business Logic Vulnerabilities

1. Price Manipulation

Scenario: Mua hàng với giá âm

POST /api/cart/add
{"product_id": 1, "quantity": -5}

→ Giá = unit_price × quantity = $10 × (-5) = -$50
→ Total giảm $50 → hacker được tiền!

2. Workflow Bypass

Bình thường:
Step 1: Add to cart → Step 2: Enter address → Step 3: Payment → Step 4: Confirm

Bypass:
Step 1 → Step 4 (nhảy trực tiếp → không cần thanh toán)

Nếu server không check "user đã qua payment step chưa"
→ Order được tạo mà không thu tiền

3. Trust Assumption Lỗi

# Vulnerable: Tin vào client-supplied discount
POST /api/checkout
{
"items": [...],
"discount_code": "ADMIN50",
"discount_percent": 99 # ← Client chỉ định discount %!
}

# Server nhận discount_percent từ client → apply 99% discount

4. Integer Overflow / Underflow

Max quantity per order: 1000
Hacker order: quantity = 2147483648 (max int32)
→ Overflow → quantity becomes negative → price negative

5. Email Case Sensitivity

Đăng ký với: Admin@example.com
Login với: admin@example.com

Nếu app store email as-is nhưng lookup case-insensitive:
→ Có thể tạo nhiều accounts cho cùng email
→ Bypass "1 account per email" restriction

Kịch bản tấn công: Refund Fraud

Target: E-commerce app với refund policy

1. Mua product A ($100)
2. Nhận product A
3. Request refund → $100 được trả lại
4. (Trong một số app) Order status không update correct
5. Return window vẫn open → request another refund
→ Nhận tiền 2 lần, giữ product

Cách phát hiện

□ Thử negative quantities, prices, quantities
□ Bypass multi-step workflows bằng cách nhảy steps
□ Test integer extremes (0, -1, MAX_INT, MIN_INT)
□ Modify hidden fields / client-supplied parameters
□ Test với điều kiện "impossible" (trả hàng nhiều lần)
□ Test timing: actions trong wrong order
□ Test boundary conditions (exact limit)

Phòng chống

# Validate tất cả business rules server-side
def add_to_cart(product_id: int, quantity: int, user_id: int):
# Validate không tin client
if quantity <= 0:
raise ValueError("Quantity must be positive")

if quantity > 100: # Business rule: max 100 per order
raise ValueError("Maximum 100 items per order")

product = db.get_product(product_id)
if not product or not product.is_available:
raise ValueError("Product not available")

# Calculate price server-side, không nhận từ client
price = product.price * quantity
# Apply discounts server-side với verified discount code

# State machine cho workflow
cart = db.get_cart(user_id)
if cart.status != 'OPEN':
raise ValueError("Cart is not in OPEN state")

# State machine cho order workflow
class OrderStateMachine:
VALID_TRANSITIONS = {
'PENDING': ['PAID', 'CANCELLED'],
'PAID': ['SHIPPED', 'REFUNDED'],
'SHIPPED': ['DELIVERED', 'RETURNED'],
'DELIVERED': ['COMPLETED'],
'COMPLETED': [],
}

def transition(self, order, new_status):
current = order.status
if new_status not in self.VALID_TRANSITIONS.get(current, []):
raise ValueError(f"Cannot transition from {current} to {new_status}")
order.status = new_status

Góc nhìn DevOps

Business Logic Testing trong CI/CD:

# Automated business logic tests
def test_negative_quantity_rejected():
response = client.post('/api/cart/add', json={'product_id': 1, 'quantity': -1})
assert response.status_code == 400

def test_price_is_server_calculated():
# Order với giá từ client bị ignore
response = client.post('/api/checkout', json={'price': 0.01})
order = response.json()
assert order['total'] == expected_price # Server price, không client price

def test_workflow_sequence_enforced():
# Cannot skip to confirmation without payment
response = client.post('/api/orders/confirm/ORD-001')
assert response.status_code == 403 # Chưa thanh toán

Tóm tắt

  • Business logic bugs là lỗi về business rules, không phải kỹ thuật.
  • Khó detect bằng tools — cần hiểu business intent.
  • Phổ biến: price manipulation, workflow bypass, trust in client input, integer issues.
  • Phòng chống: validate tất cả business rules server-side, state machines, không tin client-supplied values.

Câu hỏi ôn tập

  1. Business logic vulnerability khác với technical vulnerability như SQLi ở điểm nào?
  2. Tại sao negative quantity attack hoạt động? Cần validate gì?
  3. State machine pattern giúp phòng chống workflow bypass như thế nào?
  4. Tại sao automated scanners khó phát hiện business logic bugs?
  5. Mô tả một business logic vulnerability trong hệ thống banking.