Application Security

Application Security thường viết tắt là AppSec là việc bảo vệ ứng dụng khỏi các lỗ hổng và hành vi tấn công trong suốt vòng đời phát triển và vận hành phần mềm.

AppSec không bắt đầu khi ứng dụng đã code xong.

Nó nên bắt đầu từ lúc xác định requirement.

Một requirement như “người dùng có thể xem booking của mình” chưa đủ nếu chưa xác định ai được phép xem booking nào và hệ thống phải kiểm tra quyền ở đâu.

Đó đã là một vấn đề Application Security.

Application Security vì vậy không chỉ là chạy một công cụ scan trước ngày go-live.

Nó liên quan đến requirement architecture design coding testing deployment monitoring và vulnerability management.

Mục tiêu không phải tạo ra phần mềm “không bao giờ có lỗ hổng”.

Mục tiêu thực tế hơn là giảm xác suất xuất hiện lỗ hổng giảm tác động khi lỗ hổng xảy ra và phát hiện xử lý vấn đề đủ nhanh.

Một phần quan trọng của AppSec là Security Requirements.

Các requirement bảo mật nên được xác định cùng với requirement chức năng.

Ví dụ hệ thống cần xác định cách xác thực người dùng chính sách phiên đăng nhập quyền truy cập bảo vệ dữ liệu audit log và những hành động nhạy cảm cần kiểm soát.

Nếu security requirement chỉ xuất hiện sau khi code hoàn tất nhiều quyết định kiến trúc đã trở nên khó sửa.

Threat Modeling giúp đội phát triển suy nghĩ trước về cách hệ thống có thể bị tấn công.

Thay vì chỉ hỏi ứng dụng hoạt động như thế nào có thể hỏi thêm:

Ai có thể tấn công hệ thống.

Tài sản nào cần bảo vệ.

Trust boundary nằm ở đâu.

Dữ liệu đi qua những thành phần nào.

Điều gì xảy ra nếu một thành phần bị kiểm soát.

Threat Modeling không cần biến thành một buổi họp dài đầy sơ đồ.

Ngay cả việc vẽ data flow rồi hỏi những câu hỏi đúng cũng có thể phát hiện nhiều vấn đề trước khi chúng biến thành code.

Authentication là một phần quan trọng của Application Security.

Authentication trả lời câu hỏi:

Bạn là ai?

Ứng dụng cần xử lý password session token MFA password reset và những cơ chế đăng nhập khác một cách an toàn.

Nhưng đăng nhập thành công chưa có nghĩa người dùng được phép làm mọi thứ.

Đó là nhiệm vụ của Authorization.

Authorization trả lời câu hỏi:

Bạn được phép làm gì?

Một lỗi rất nguy hiểm xảy ra khi ứng dụng kiểm tra người dùng đã đăng nhập nhưng không kiểm tra họ có quyền truy cập tài nguyên cụ thể hay không.

Ví dụ thay đổi một booking_id trên URL rồi xem được booking của người khác là vấn đề authorization chứ không phải authentication.

Đây là lý do access control phải được kiểm tra ở phía server.

Ẩn một button trên frontend không phải access control.

Input Validation cũng là nền tảng AppSec.

Dữ liệu đến từ browser mobile app API file upload message queue hoặc hệ thống khác đều nên được xem là input cần kiểm tra.

Không nên mặc định dữ liệu an toàn chỉ vì nó đến từ một ứng dụng nội bộ.

Validation nên dựa trên loại dữ liệu mà hệ thống cho phép thay vì cố tạo một danh sách vô hạn những chuỗi bị cấm.

Injection là một nhóm vấn đề quen thuộc.

SQL Injection có thể xảy ra khi dữ liệu không đáng tin được ghép trực tiếp vào câu SQL theo cách khiến dữ liệu trở thành một phần của câu lệnh.

Sử dụng parameterized query hoặc cơ chế tương đương là một biện pháp phòng vệ quan trọng.

Nhưng injection không chỉ tồn tại trong SQL.

Các hệ thống có thể gặp command injection template injection LDAP injection hoặc những dạng khác tùy công nghệ.

Cross-Site Scripting hay XSS liên quan đến việc dữ liệu không đáng tin được đưa vào nội dung web theo cách cho phép thực thi script ngoài ý muốn.

Giải pháp không đơn giản là “lọc ký tự đặc biệt”.

Cần sử dụng output encoding phù hợp với context và tận dụng cơ chế an toàn của framework.

CSRF là một vấn đề khác khi kẻ tấn công khiến browser của người dùng đã đăng nhập gửi một request ngoài ý muốn.

Các biện pháp như CSRF token SameSite cookie và thiết kế API phù hợp có thể tham gia vào việc phòng vệ tùy kiến trúc.

Session Management cũng cần được thiết kế cẩn thận.

Session identifier cần khó đoán.

Session nên hết hạn phù hợp.

Những sự kiện như đổi password đăng xuất hoặc phát hiện tài khoản bị xâm nhập có thể cần thu hồi session.

Cookie nhạy cảm thường cần các thuộc tính bảo vệ phù hợp như Secure HttpOnly và SameSite tùy use case.

Cryptography là một lĩnh vực dễ bị sử dụng sai.

Không nên tự thiết kế thuật toán mã hóa.

Nên sử dụng thuật toán thư viện và giao thức đã được kiểm chứng phù hợp với mục đích.

Password cũng không nên được lưu bằng cách mã hóa rồi có thể giải mã trở lại.

Thông thường password cần được lưu bằng password hashing phù hợp với salt và tham số đủ mạnh.

Secrets Management là một phần khác thường bị bỏ quên.

API key database password private key và access token không nên được hard-code vào source code.

Đặc biệt không nên commit secret vào repository rồi nghĩ rằng xóa commit sau đó là xong.

Nếu secret đã bị lộ nó nên được xem xét rotate hoặc revoke tùy trường hợp.

Logging hỗ trợ phát hiện và điều tra sự cố bảo mật.

Các sự kiện như đăng nhập thất bại thay đổi quyền thao tác quản trị hoặc hành động nhạy cảm có thể cần được ghi lại.

Nhưng log cũng có thể trở thành nguồn rò rỉ dữ liệu.

Password access token thông tin thẻ thanh toán hoặc dữ liệu nhạy cảm không nên bị ghi vào log một cách tùy tiện.

Error Handling cũng liên quan đến bảo mật.

Một thông báo lỗi gửi toàn bộ stack trace connection string hoặc SQL query ra ngoài có thể tiết lộ nhiều thông tin hữu ích cho người tấn công.

Ứng dụng nên cung cấp cho người dùng thông tin đủ để xử lý lỗi nhưng không làm lộ chi tiết nội bộ không cần thiết.

Dependency Security ngày càng quan trọng vì phần lớn ứng dụng hiện đại sử dụng rất nhiều thư viện bên thứ ba.

Một ứng dụng có thể không chứa code dễ bị tấn công do đội phát triển viết nhưng vẫn bị ảnh hưởng bởi dependency có lỗ hổng.

Do đó cần biết phần mềm đang phụ thuộc vào những package nào phiên bản nào và tình trạng bảo mật của chúng.

Tuy nhiên chỉ cập nhật mọi dependency lên phiên bản mới nhất cũng không phải một chiến lược hoàn chỉnh.

Mỗi update vẫn cần được đánh giá về compatibility và rủi ro.

Software Supply Chain Security mở rộng vấn đề sang package registry build pipeline artifact CI/CD và nguồn cung cấp phần mềm.

Kẻ tấn công không nhất thiết phải tìm lỗ hổng trực tiếp trong code của ứng dụng.

Đôi khi tấn công một dependency build server hoặc credential của developer hiệu quả hơn.

Application Security vì vậy ngày càng liên quan đến cả quá trình tạo ra phần mềm.

Secure Coding là một phần của AppSec nhưng không phải toàn bộ AppSec.

Developer có thể viết code rất cẩn thận nhưng một kiến trúc authorization sai vẫn tạo ra lỗ hổng.

Ngược lại một kiến trúc tốt vẫn có thể bị phá vỡ bởi một đoạn code xử lý input không an toàn.

Security cần nhiều lớp.

Code Review có thể giúp phát hiện vấn đề trước khi merge.

Reviewer có thể kiểm tra những thay đổi liên quan đến authentication authorization input validation cryptography logging hoặc các vùng nhạy cảm khác.

AI Code Review cũng có thể hỗ trợ AppSec.

AI có thể phát hiện một số pattern đáng ngờ hoặc đặt câu hỏi về logic security.

Nhưng AI không nên được xem là công cụ xác nhận rằng code “an toàn”.

AI có thể bỏ sót lỗ hổng và cũng có thể báo lỗi giả.

Các finding vẫn cần được kiểm chứng.

SAST hay Static Application Security Testing phân tích source code bytecode hoặc binary mà không cần chạy ứng dụng theo cách kiểm thử động.

Nó có thể phát hiện một số pattern bảo mật trong quá trình phát triển và CI.

DAST hay Dynamic Application Security Testing kiểm tra ứng dụng đang chạy từ bên ngoài.

Cách này có thể phát hiện những vấn đề chỉ xuất hiện khi ứng dụng thực sự hoạt động.

SCA hay Software Composition Analysis thường được sử dụng để nhận diện dependency và những vấn đề liên quan đến thành phần bên thứ ba.

Không có một công cụ nào tìm được mọi lỗ hổng.

SAST DAST SCA penetration testing code review và automated tests nhìn hệ thống từ những góc khác nhau.

AppSec tốt thường sử dụng nhiều lớp kiểm soát thay vì tìm một công cụ duy nhất để “quét hết bảo mật”.

Penetration Testing cũng là một phần hữu ích nhưng không nên trở thành lớp bảo vệ duy nhất.

Nếu ứng dụng chỉ được kiểm tra bảo mật vài ngày trước go-live thì những lỗi kiến trúc lớn có thể rất đắt để sửa.

Đưa security vào sớm hơn trong SDLC thường giúp giảm chi phí sửa lỗi.

Khái niệm này thường được gọi là shift left.

Nhưng shift left không có nghĩa chuyển toàn bộ trách nhiệm security sang developer.

Security vẫn cần tiếp tục sau khi triển khai.

Vulnerability mới có thể được phát hiện.

Dependency có thể xuất hiện CVE mới.

Credential có thể bị lộ.

Cấu hình production có thể thay đổi.

Do đó cũng cần shift right bằng monitoring detection incident response và vulnerability management trong môi trường vận hành.

OWASP là một nguồn tài liệu quan trọng trong Application Security.

OWASP Top 10 giúp nâng cao nhận thức về một số nhóm rủi ro phổ biến trong web application security.

Nhưng OWASP Top 10 không phải checklist hoàn chỉnh để chứng minh một ứng dụng an toàn.

Đây là điểm rất dễ bị hiểu sai.

Kiểm tra đủ mười mục không có nghĩa ứng dụng đã “đạt chuẩn bảo mật”.

Với requirement và verification chi tiết hơn có thể tham khảo OWASP Application Security Verification Standard hay ASVS.

ASVS cung cấp một bộ yêu cầu giúp thiết kế phát triển và kiểm chứng các kiểm soát bảo mật trong ứng dụng web và web service.

Điều quan trọng là sử dụng tiêu chuẩn theo risk của hệ thống thay vì copy toàn bộ checklist rồi đánh dấu cho đủ.

Một trang giới thiệu đơn giản và một hệ thống thanh toán không nên có cùng mô hình threat và mức kiểm soát.

Risk mới là trung tâm của Application Security.

Một finding không nên được đánh giá chỉ bằng tên lỗ hổng.

Cần xem khả năng khai thác tài sản bị ảnh hưởng dữ liệu có thể bị lộ phạm vi tác động và khả năng kiểm soát hoặc phục hồi.

Một lỗ hổng nghiêm trọng trong một chức năng không thể truy cập có thể có risk khác với một lỗi tưởng nhỏ nhưng nằm trên API xử lý toàn bộ dữ liệu khách hàng.

Application Security cũng không chỉ là trách nhiệm của đội Security.

Product cần hiểu security requirement.

Architect cần thiết kế trust boundary và access control.

Developer cần viết code an toàn.

Reviewer cần kiểm tra thay đổi.

DevOps cần bảo vệ pipeline và secret.

Operations cần giám sát hệ thống.

Security team hỗ trợ threat modeling verification policy và xử lý vulnerability.

Trách nhiệm có thể khác nhau giữa các tổ chức nhưng security không nên trở thành chiếc vé cuối cùng chuyển sang một phòng ban khác.

Một quy trình Application Security đơn giản có thể đi theo chuỗi:

Security Requirements → Threat Modeling → Secure Design → Secure Coding → Code Review → Automated Security Testing → Verification → Deployment Controls → Monitoring → Vulnerability Response.

Không phải dự án nào cũng cần cùng mức kiểm soát.

Điều quan trọng là mức kiểm soát phải tương xứng với risk.

Một nguyên tắc hữu ích khác là defense in depth.

Không nên dựa vào một lớp bảo vệ duy nhất.

Nếu validation ở frontend bị vượt qua server vẫn phải kiểm tra.

Nếu credential bị lộ authorization vẫn phải hạn chế quyền.

Nếu một vulnerability bị khai thác logging và monitoring vẫn cần giúp phát hiện hành vi bất thường.

Mỗi lớp đều có thể thất bại.

Nhiều lớp làm giảm khả năng một lỗi duy nhất phá vỡ toàn bộ hệ thống.

Tag Application Security tổng hợp các bài viết và kiến thức về bảo mật ứng dụng secure SDLC threat modeling authentication authorization secure coding OWASP security testing dependency security vulnerability management và cách đưa bảo mật vào quá trình phát triển phần mềm từ đầu thay vì chờ đến lúc go-live mới kiểm tra.