Chào mấy bạn, lại là Zeno đây! :D
Hôm bữa mình có nói về Injection rồi hen. Bữa nay, theo yêu cầu của anh em, mình lên sóng tiếp một món “hại não” không kém trong bảng phong thần OWASP Top 10 2025. Chèng ơi, nhắc tới cái lỗi này là nhiều dev khóc ròng luôn, vì có khi code hoàn hảo, sạch không tì vết, pass 100% test case mà hệ thống vẫn… toang!
Nghe ảo ma Canada chưa? Lỗi gì mà khét dữ thần vậy? Xin trân trọng giới thiệu: A06:2025 - Insecure Design (Thiết kế không an toàn).
Mọi người xắn tay áo lên, pha sẵn ly cà phê nghen, mình vô bài nè!
1. Bản chất của Insecure Design: Sai từ trong “trứng nước”
Hồi xưa mấy anh em coder tụi mình khoái cái câu “Cứ code đi, sai đâu sửa đó”. Ẹc! Nhưng đối với Insecure Design thì “sửa đó” là bán nhà luôn nha!
Trong bảng xếp hạng OWASP Top 10 mới nhất, hạng mục này đã tuột xuống hạng 6 (hạ 2 bậc), nhờ việc giới giang hồ IT dạo này đã chăm chỉ mần Threat Modeling (Mô hình hóa mối đe dọa) hơn rồi.
Vậy Insecure Design thực chất là gì?
- Lỗi thiết kế (Design Flaws) vs Lỗi lập trình (Implementation Bugs): Khác biệt to bự nghen! Lỗi lập trình (như thằng SQLi) là kiểu thợ xây tô tường bị cong. Còn lỗi thiết kế là bản vẽ kiến trúc của kỹ sư ngay từ đầu đã chỉ định xây… nhà không cửa. Code bạn có sạch sẽ đẹp đẽ cỡ nào đi nữa, bản vẽ sai logic thì cũng sập hầm thôi.
- Không thể vá bằng cách “sửa code” đơn thuần: Với Injection, bạn rào lại biến đầu vào, đổi hàm một phát là xong. Nhưng với Insecure Design, bạn buộc phải đập đi xây lại cấu trúc hoặc logic vận hành của cả một hệ thống. Đau ruột chưa?
2. Điểm danh vài ví dụ “đi vào lòng đất”
Lý thuyết nãy giờ đủ rồi, giờ Zeno kể mấy câu chuyện thực chiến cho anh em dễ hình dung sự lợi hại của mấy lỗi thiết kế này.
a. Thiếu giới hạn tần suất (No Rate Limiting)
Hệ thống cho phép user đăng nhập hoặc gọi API “thả ga” không giới hạn. Mấy anh hacker thấy vậy khoái chí đem tool ra Brute-Force, gửi cả triệu request mỗi giây. Kết quả: Sập server, hoặc dễ dàng mò ra pass, mà dev ngồi ngó vì… ủa tui có code sai đâu, API vẫn hoạt động đúng chức năng mà?! :v
b. Khôi phục mật khẩu “dễ như ăn kẹo”
Bạn quên mật khẩu ư? Không sao, hệ thống chỉ cần bạn trả lời câu hỏi bảo mật: “Tên con chó nhà bạn là gì?”. Không cần mã OTP gửi qua điện thoại, không cần email xác nhận. Kết quả: Thằng bạn thân (hoặc một người lạ xoi mói Facebook bạn biết tên thú cưng) dễ dàng chiếm tài khoản ngon lành cành đào!
c. Thao túng logic giỏ hàng (Business Logic Flaw)
Cái này vui nè! User mua cái áo 500k, sau đó xài Burp Suite chặn request và sửa giá (price) gửi lên thành -500k. Hệ thống (do thiết kế ngây thơ, thiếu kiểm tra chéo ở backend) tính ra tổng tiền thanh toán là số âm, thế là tự nhiên ví của bạn được hoàn lại 500k. Hết nước chấm! Lỗ hổng này không do code dở, mà do bỏ quên rào chắn bảo vệ logic nghiệp vụ.
d. Thiếu cơ chế chống gian lận
Một ứng dụng tài chính xịn xò cho phép chuyển tiền mà không hề có bước kiểm tra hạn mức giao dịch bất thường (ví dụ: account cá nhân mà chuyển 1 tỷ lúc 3 giờ sáng). Code chạy đúng, tiền đi đến nơi về đến chốn, nhưng thiếu Security Design cho nghiệp vụ, thế là tiền bốc hơi không vết tích.
3. Bí kíp “phòng bệnh hơn chữa bệnh”
Vậy làm sao để chặn họa từ trong trứng nước? Zeno gợi ý mấy chiêu sau, anh em ráng làm tới tới nghen:
Dịch chuyển về bên trái (Shift Left): Nghe hàn lâm vậy thôi, chứ “trái” ở đây là kéo cái công cuộc bảo mật về những bước đầu tiên của quy trình làm app (lúc còn đang vẽ vời ý tưởng). Đừng để code xong hết trơn mới kêu pentester vô đập phá.
Mô hình hóa mối đe dọa (Threat Modeling): Chiêu này đỉnh của chóp! Trước khi viết dòng code đầu tiên, cả team ngồi lại tưởng tượng: “Nếu tui là hacker, tui sẽ phá cái app này kiểu gì?”. Chủ động giả định các kịch bản tấn công để rào trước đón sau.
Sử dụng Kiến trúc tham chiếu (Secure Design Patterns): Đừng có tự chế (như tự chế thư viện mã hóa là tối kỵ nghen). Cứ xài mấy mẫu thiết kế, thư viện an toàn đã được cộng đồng thế giới kiểm chứng.
Thiết lập chu kỳ phát triển an toàn (Secure SDLC): Tích hợp việc đánh giá rủi ro vào mọi khâu, từ lên ý tưởng, thiết kế, code, tới lúc release. Bảo mật là một quá trình liên tục chứ không phải check-box một lần rồi thôi!
4. Tóm lại
A06: Insecure Design là lời nhắc nhở thấm thía: Đừng chỉ cắm đầu vào bàn phím gõ code. Hãy lùi lại một bước, ngắm nghía cái bản vẽ kiến trúc, thiết kế cho an toàn ngay từ đầu thì sau này đỡ ăn hành!
Hẹn gặp lại anh em ở bài kế tiếp của chuỗi OWASP Top 10 nha! Cần demo code thực tế hay hướng dẫn mần Threat Modeling thì cứ hú Zeno một tiếng! :D