Trong hệ thống bảo mật dữ liệu nhạy cảm, "secure" không chỉ là có TLS hay token. Câu hỏi thực tế: Nếu attacker capture request hợp lệ và replay thì sao?
Hầu hết hệ thống trả lời yếu ớt:
- ❌ "Có TLS rồi" – Nhưng TLS không chống replay.
- ❌ "Có token rồi" – Token dài hạn dễ lạm dụng.
- ❌ "Có rate limit" – Không hiểu ngữ cảnh quyền hạn.
OBELISK giả định: Mọi request hợp lệ đều có thể bị capture và replay. Vấn đề không phải ngăn replay tuyệt đối, mà giới hạn thiệt hại khi replay xảy ra.
1️⃣ Threat Model của Replay & Abuse
OBELISK giả định attacker có thể:
- ✅ Sniff packet ở client side
- ✅ Capture request hợp lệ
- ✅ Replay nhiều lần
- ✅ Flood hệ thống bằng request "đúng định dạng"
- ✅ Reverse client để hiểu protocol
Không giả định:
- Crypto bị phá
- TLS bị MITM toàn diện
- Kernel bị chiếm lâu dài
Mục tiêu:
- ✅ Replay không mở rộng quyền
- ✅ Abuse không mở rộng phạm vi
- ✅ Flood không chạm data plane
- ✅ Stateless nhưng vẫn kiểm soát chặt chẽ
2️⃣ Vì Sao Session-Based Defense Thất Bại
Cách truyền thống: Login → Tạo session → Gắn quyền → Giữ state server-side.
Vấn đề:
- ❌ Session hijack → Toàn quyền
- ❌ State lưu trữ → Bug, khó scale
- ❌ Session sống lâu → Blast radius lớn
- ❌ Revocation phức tạp
OBELISK bỏ session hoàn toàn – không phải "ngầu", mà vì session là single point of failure cho replay.
3️⃣ Capability Là Nền Tảng Chống Lạm Dụng
OBELISK dùng capability token thay vì access token. Mỗi capability:
- ✅ Chỉ cho 1 hành động
- ✅ Trên 1 resource
- ✅ Trong thời gian rất ngắn
Ví dụ: "READ object X, offset 0–1MB, trong 10 giây".
Nếu replay:
- Chỉ đọc đúng đoạn đó
- Chỉ trong thời gian đó
- Không mở rộng sang object khác
👉 Replay không làm hệ thống nguy hiểm hơn ban đầu.
4️⃣ Stateless ≠ Không Kiểm Soát
OBELISK stateless, nhưng không mù quáng. Mỗi request mang đủ info để verify:
- Action
- Resource
- Time window
- Nonce
- AEAD proof
Server verify mà không cần DB lookup.
Lợi ích:
- ✅ Scale tốt
- ✅ Không session store để tấn công
- ✅ Tránh memory exhaustion
5️⃣ Time Window – Giới Hạn Replay Theo Thời Gian
Replay không loại bỏ hoàn toàn → Giới hạn giá trị của nó.
Nguyên tắc:
- ✅ Capability có not_before
- ✅ not_after
- ✅ Window ngắn (vài giây đến vài chục giây)
Replay sau window → Reject. Replay trong window → Chỉ làm đúng việc được cấp.
Không token "dùng mãi mãi".
6️⃣ Nonce – Không Để Request Giống Nhau
Mỗi capability chứa nonce ngẫu nhiên.
Nonce giúp:
- ✅ Tránh reuse request nguyên
- ✅ Tránh cache replay thô
Không lưu nonce server-side – vì chỉ có giá trị trong time window ngắn.
Kết hợp nonce + time window + action/resource binding → Replay kém hiệu quả.
7️⃣ Header Crypto – Request Phải "Đúng Ngữ Cảnh"
Ngoài capability, request có header crypto:
- Timestamp
- Body hash
- HMAC/AEAD trên toàn request
Ngăn:
- ✅ Sửa payload
- ✅ Đổi method
- ✅ Trộn capability với request khác
Request hợp lệ phải đúng hình dạng + ngữ cảnh.
8️⃣ Chống Abuse Ở Cấp Độ Quyền, Không Chỉ IP
Rate limit truyền thống: Dựa IP, không hiểu nội dung.
OBELISK limit theo:
- ✅ Action
- ✅ Resource
- ✅ Capability scope
Ví dụ:
- READ chỉ gọi N lần/capability
- WRITE giới hạn băng thông
- LIST giới hạn số object
👉 Abuse bị chặn trước khi chạm data thật.
9️⃣ Flood Không Được Chạm Data Plane
Chuỗi phòng thủ: SPA → PF → TLS → Header crypto → Capability verify → Data execution
Flood chết ở:
- ✅ SPA/PF rate-limit
- ✅ Header crypto verify
Data plane chỉ thấy request đã lọc sạch.
🔟 Vì Sao Không Dùng JWT / OAuth / Macaroons
JWT/OAuth: Token lâu, scope rộng, revoke khó, replay = toàn quyền.
Macaroons: Tốt attenuation nhưng phức tạp, dễ misuse, khó audit.
OBELISK chọn capability đơn giản:
- Deterministic
- Dễ audit
- Ít chỗ sai
Trong môi trường nhạy cảm: Ít phép màu = Ít thảm họa.
1️⃣1️⃣ Khi Replay Xảy Ra, Chuyện Gì KHÔNG Xảy Ra
Replay trong OBELISK không dẫn đến:
- ❌ Leo thang quyền
- ❌ Truy cập dữ liệu khác
- ❌ Persistence
- ❌ Lateral movement
Chỉ lặp lại hành động đã cấp trong thời gian ngắn.
Nếu vẫn không chấp nhận → Vấn đề ở quyền ban đầu, không phải replay.
1️⃣2️⃣ Kết Luận
OBELISK không "ngăn replay bằng mọi giá" – mà giới hạn giá trị replay & abuse.
Stateless đúng cách: Kiểm soát bằng toán học, thời gian, và design – không phải session hay niềm tin.
Replay & Abuse Defense đảm bảo: Mọi request đều an toàn theo thiết kế, ngay cả khi bị capture.
