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