Tweet
🔥 Bạn đang chặn tấn công bằng cách nào? Allow List hay Deny List – đâu mới là chiến thuật đúng?
Trong chiến trường an ninh mạng, nơi mỗi dòng code có thể là cổng vào cho một cuộc tấn công, kỹ năng xử lý dữ liệu đầu vào là tuyến phòng thủ đầu tiên – và đôi khi cũng là cuối cùng. Nếu bạn vẫn còn tin rằng “cấm ký tự nguy hiểm là đủ an toàn”, thì bài viết này dành cho bạn.
⚙️ Ý nghĩa kỹ thuật – Không chỉ là code, mà là cả hệ thống
Mỗi khi bạn triển khai một phần mềm mới, thêm một module xác thực, hay đơn giản là cấu hình lại một rule trong tường lửa – bạn đang tạo ra các hậu quả kỹ thuật (technical implications).
Ví dụ thực tế:
✅ Allow List – Phòng thủ chủ động bằng cách chỉ cho phép điều bạn hiểu
Danh sách cho phép (Allow list) là phương pháp cho phép chỉ những giá trị hợp lệ được nhập vào hệ thống. Nó giống như nói với hệ thống rằng: "Chỉ những thứ này được chấp nhận, mọi thứ còn lại đều nghi ngờ."
Ví dụ thực tế:
🔍 Nhưng khi bạn xử lý trường nhập tự do (free-form), mọi chuyện phức tạp hơn:
❌ Deny List – Hạn chế tạm thời, rủi ro dài hạn
Deny List (hoặc block list) là phương pháp cổ điển: liệt kê các ký tự xấu và cấm nhập.
Nghe có vẻ hợp lý:
Ví dụ:
🧠 Tổng kết cho anh em IT: Dùng Allow List, né Deny List
📌 Tips thực chiến cho Dev, Admin, và Blue Team:
🛡️ Nhớ: hacker không cần biết bạn đang validate kiểu gì – họ chỉ cần tìm một chỗ bạn bỏ sót. Input Validation phải là lớp đầu tiên, không phải tấm khiên cuối cùng.
Nếu thấy bài viết hữu ích, hãy chia sẻ với team của bạn và comment nếu bạn đã từng gặp lỗi do xử lý đầu vào sai! 🚨
vnpro #SecurityFirst #InputValidation #AllowListVsDenyList ccnp #DevSecOps owasp #CyberDefense #Regex #SecurityTips
Trong chiến trường an ninh mạng, nơi mỗi dòng code có thể là cổng vào cho một cuộc tấn công, kỹ năng xử lý dữ liệu đầu vào là tuyến phòng thủ đầu tiên – và đôi khi cũng là cuối cùng. Nếu bạn vẫn còn tin rằng “cấm ký tự nguy hiểm là đủ an toàn”, thì bài viết này dành cho bạn.
⚙️ Ý nghĩa kỹ thuật – Không chỉ là code, mà là cả hệ thống
Mỗi khi bạn triển khai một phần mềm mới, thêm một module xác thực, hay đơn giản là cấu hình lại một rule trong tường lửa – bạn đang tạo ra các hậu quả kỹ thuật (technical implications).
Ví dụ thực tế:
- Triển khai SIEM mới → cần mở cổng log, ảnh hưởng rule firewall → có thể cần thêm VLAN hoặc subnet riêng.
- Chuyển từ xác thực truyền thống sang MFA → tăng bảo mật nhưng yêu cầu đồng bộ hóa máy chủ xác thực và cải tiến app client.
- Cài thêm agent để phát hiện xâm nhập (EDR) → tiêu tốn CPU RAM, gây chậm máy → ảnh hưởng đến vận hành.
✅ Allow List – Phòng thủ chủ động bằng cách chỉ cho phép điều bạn hiểu
Danh sách cho phép (Allow list) là phương pháp cho phép chỉ những giá trị hợp lệ được nhập vào hệ thống. Nó giống như nói với hệ thống rằng: "Chỉ những thứ này được chấp nhận, mọi thứ còn lại đều nghi ngờ."
Ví dụ thực tế:
- Trường số điện thoại chỉ nhận chuỗi số 10 chữ số.
- Trường email chỉ nhận định dạng có @vnpro.vn.
- Trường mã nhân viên chỉ được nhập các ký tự [A-Z]{3}[0-9]{4}.
🔍 Nhưng khi bạn xử lý trường nhập tự do (free-form), mọi chuyện phức tạp hơn:
- Bạn có cho phép chữ tiếng Nhật, Ả Rập không?
- Người dùng copy từ Word xuống → Unicode có thể sai chuẩn.
- Có khoảng trắng vô hình, ký tự “smart quote”, hoặc emoji?
- Dùng Unicode character categories để xác định loại ký tự hợp lệ.
- Dùng normalize() để chuẩn hóa encoding (ví dụ NFC/NFD) → chống bypass kiểu e + ´ = é.
❌ Deny List – Hạn chế tạm thời, rủi ro dài hạn
Deny List (hoặc block list) là phương pháp cổ điển: liệt kê các ký tự xấu và cấm nhập.
Nghe có vẻ hợp lý:
- Cấm ', ; để chặn SQL injection.
- Cấm <> để ngăn HTML/XSS.
- Cấm () để chặn JS.
Ví dụ:
- SQL injection vẫn hoạt động khi dùng UNION SELECT viết hoa/thường xen kẽ (uNiOn SeLeCt).
- HTML có thể viết bằng mã <script> thay vì <script>.
- Deny list dễ gây lỗi ứng dụng vì chặn nhầm.
- Rất dễ bỏ sót các mẫu tấn công mới → tưởng an toàn nhưng vẫn hở sườn.
- Không thể dùng làm hàng rào chính, chỉ nên dùng làm “tạm thời” trong xử lý sự cố hoặc vá nhanh.
🧠 Tổng kết cho anh em IT: Dùng Allow List, né Deny List
| Cơ chế | Chỉ chấp nhận cái đúng | Cấm những gì thấy nguy hiểm |
| Độ an toàn | Cao (nếu duy trì tốt) | Thấp (dễ bị bypass) |
| Dễ duy trì | Không, cần quản lý cẩn thận | Khó, và dễ lỗi nếu sót |
| Ứng dụng thực tế | Đầu vào định dạng rõ (số, email) | Vá lỗi nhanh, ứng phó tạm thời |
- ✅ Dùng Allow List với regex hoặc HTML5 form.
- ✅ Normalize dữ liệu đầu vào trước khi xử lý.
- ✅ Không bao giờ chỉ dựa vào Deny List.
- ✅ Tích hợp input validation trong pipeline CI/CD.
- ✅ Test input với payload như BurpSuite, fuzzers, OWASP Zap.
🛡️ Nhớ: hacker không cần biết bạn đang validate kiểu gì – họ chỉ cần tìm một chỗ bạn bỏ sót. Input Validation phải là lớp đầu tiên, không phải tấm khiên cuối cùng.
Nếu thấy bài viết hữu ích, hãy chia sẻ với team của bạn và comment nếu bạn đã từng gặp lỗi do xử lý đầu vào sai! 🚨
vnpro #SecurityFirst #InputValidation #AllowListVsDenyList ccnp #DevSecOps owasp #CyberDefense #Regex #SecurityTips