Danh sách kiểm thử OWASP Top 10 cho ứng dụng web: Hướng dẫn thực hành kiểm thử phần mềm

Bảo mật trong ứng dụng web không phải là một tính năng ��ơn lẻ; đó là tập hợp các hành vi cần được xác minh trong suốt vòng đời phát triển. Danh sách kiểm thử OWASP Top 10 cho ứng dụng web này được thiết kế cho các lập trình viên và kỹ sư QA muốn có các kiểm tra tập trung, có thể lặp lại và phù hợp với quy trình kiểm thử phần mềm hàng ngày. Mục tiêu không phải là biến các kiểm thử viên thành chuyên gia tấn công. Mà là đảm bảo các rủi ro phổ biến nhất được phát hiện sớm, ghi chép rõ ràng và kiểm tra lại sau khi khắc phục.

Hãy sử dụng danh sách này trong các buổi đánh giá pull request, kiểm thử sprint và kiểm soát phát hành. Mỗi mục dưới đây bao gồm những gì cần kiểm tra, cách thực hiện kiểm tra đơn giản và các tín hiệu phổ biến cho thấy có vấn đề. Giữ phạm vi thực tế: kiểm tra các luồng xác thực, các API nhạy cảm nhất và các trang xử lý đầu vào của người dùng hoặc dữ liệu kinh doanh.

1. Kiểm soát truy cập bị hỏng

Các vấn đề kiểm soát truy cập xảy ra khi người dùng có thể thực hiện hành động ngoài phạm vi quyền được cho phép. Hãy xác minh rằng các hành động trái phép bị chặn nhất quán.

• Nội dung kiểm tra: Người dùng thông thường có thể truy cập các endpoint quản trị bằng cách thay đổi URL hoặc tham số yêu cầu không? Người dùng có thể chỉnh sửa dữ liệu của người dùng khác bằng cách thay đổi ID trong yêu cầu không?
• Cách kiểm tra: Tạo ít nhất hai tài khoản không phải quản trị viên. Thử đọc, cập nhật hoặc xóa tài nguyên thuộc về tài khoản khác. Kiểm tra truy cập trực tiếp qua URL đến các trang và tuyến API được bảo vệ.
• Tín hiệu cảnh báo: Thiếu kiểm tra phía máy chủ, ủy quyền không nhất quán giữa các endpoint tương tự hoặc các tuyến ẩn trả về dữ liệu khi được gọi trực tiếp.

2. Lỗi mật mã học

Các lỗi mật mã học bao gồm thuật toán yếu, lưu trữ văn bản thuần và truyền tải không an toàn. Tập trung vào cách dữ liệu nhạy cảm được bảo vệ trong quá trình truyền và lưu trữ.

• Nội dung kiểm tra: Tất cả các trang trong môi trường sản xuất có được phục vụ qua HTTPS không? Mật khẩu có được băm bằng thuật toán hiện đại, chậm không? Các bí mật có được lưu trữ ngoài mã nguồn và nhật ký không?
• Cách kiểm tra: Xác minh cấu hình TLS và tính hợp lệ của chứng chỉ. Kiểm tra r���ng các endpoint đăng nhập và đăng ký từ chối HTTP thuần. Xem xét định dạng lưu trữ mật khẩu trong môi trường kiểm thử và xác nhận không có bí mật nào xuất hiện trong nhật ký hoặc thông báo lỗi.
• Tín hiệu cảnh báo: Sử dụng các thuật toán lỗi thời, cảnh báo nội dung hỗn hợp hoặc token và khóa xuất hiện trong lưu trữ phía máy khách hoặc nhật ký.

3. Tiêm mã

Các lỗ hổng tiêm mã xảy ra khi đầu vào không đáng tin cậy được sử dụng trong lệnh, truy vấn hoặc mẫu mà không được xử lý đúng cách. Điều này bao gồm tiêm SQL, NoSQL, hệ điều hành và LDAP.

• Nội dung kiểm tra: Các biểu mẫu và API có sử dụng truy vấn tham số hóa hoặc trình tạo truy vấn an toàn không? Các lệnh hệ thống có được xây dựng an toàn không? Đầu vào có được xác thực trước khi sử dụng không?
• Cách kiểm tra: Gửi các tải trọng đơn giản như dấu nháy đơn, dấu nháy kép và ký tự điều khiển vào các trường tìm kiếm, lọc và đăng nhập. Quan sát thông báo lỗi và hành vi ứng dụng. Xác minh rằng các ký tự nguy hiểm không thay đổi cấu trúc truy vấn hoặc thực thi lệnh.
• Tín hiệu cảnh báo: Chuỗi lỗi cơ sở dữ liệu trong phản hồi, đầu ra lệnh không mong đợi hoặc đầu vào được nối trực tiếp vào truy vấn hoặc lệnh shell.

4. Thiết kế không an toàn

Thiết kế không an toàn liên quan đến việc thiếu hoặc yếu các biện pháp kiểm soát ở cấp độ kiến trúc. Trọng tâm ở đây là liệu ứng dụng có các biện pháp bảo vệ phù hợp cho các trường hợp sử dụng dự kiến không.

• Nội dung kiểm tra: Các luồng rủi ro cao có được bảo vệ bởi giới hạn tốc độ, các bước phê duyệt hoặc xác minh bổ sung không? Các quy tắc kinh doanh có được thực thi phía máy chủ không?
• Cách kiểm tra: Theo dõi các hành trình người dùng quan trọng như tạo tài khoản, đặt lại mật khẩu, thanh toán và xuất dữ liệu. Thử bỏ qua các bước, phát lại yêu cầu hoặc lạm dụng chức năng hợp pháp.
• Tín hiệu cảnh báo: Không có giới hạn tốc độ trên các endpoint nhạy cảm, thiếu các bước xác nhận cho các hành động không thể hoàn tác hoặc dựa vào logic phía máy khách cho các quy tắc kinh doanh.

5. Cấu hình bảo mật sai

Các cài đặt mặc định, thư mục mở, lỗi chi tiết và các tính năng không cần thiết thường tạo ra các con đường tấn công dễ dàng.

• Nội dung kiểm tra: Các tài khoản và thông tin đăng nhập mặc định có bị vô hiệu hóa không? Liệt kê thư mục có bị tắt không? Các trang lỗi có hiển thị thông tin chung trong môi trường sản xuất không? Các dịch vụ và tính năng không sử dụng có bị xóa không?
• Cách kiểm tra: Yêu cầu các đường dẫn phổ biến như /.env, /backup, /debug và /robots.txt. Xem xét các header bảo mật HTTP như Content-Security-Policy, X-Content-Type-Options và Referrer-Policy. Xác nhận chính sách CORS có chặt chẽ và có chủ đích.
• Tín hiệu cảnh báo: Các tệp cấu hình bị lộ, dấu vết ngăn xếp trong phản hồi hoặc các header và chính sách quá thoáng.

6. Thành phần có lỗ hổng và lỗi thời

Các ứng dụng thường dựa vào các thư viện và khung có vấn đề đã biết. Hãy duy trì danh sách và cập nhật thường xuyên.

• Nội dung kiểm tra: Có danh sách hiện tại về các phụ thuộc trực tiếp và gián tiếp không? Các bản cập nhật bảo mật có được áp dụng kịp thời không?
• Cách kiểm tra: Chạy các công cụ kiểm thử phần mềm quét phụ thuộc để tìm các lỗ hổng đã biết. So sánh kết quả với mức độ chấp nhận rủi ro và lịch sửa lỗi của dự án. Xác minh rằng các bản sửa lỗi quan trọng được bao gồm trong ghi chú phát hành và hồ sơ triển khai.
• Tín hiệu cảnh báo: Các tệp phụ thuộc không thay đổi trong thời gian dài, các phát hiện lặp lại qua các sprint hoặc các thư viện được đánh dấu là không còn được bảo trì.

7. Lỗi nhận dạng và xác thực

Xác thực yếu cho phép chiếm đoạt tài khoản. Hãy xác minh sức mạnh của cơ chế đăng nhập, phiên và đặt lại mật khẩu.

• Nội dung kiểm tra: Có hỗ trợ xác thực đa yếu tố cho các tài khoản nhạy cảm không? Mật khẩu có được kiểm tra so với danh sách phổ biến không? Phiên có bị vô hiệu hóa sau khi đăng xuất và thay đổi m��t khẩu không?
• Cách kiểm tra: Thử đăng nhập với các mật khẩu yếu đã biết. Kiểm tra khóa tài khoản hoặc giới hạn tốc độ sau khi đăng nhập sai nhiều lần. Xác nhận ID phiên thay đổi sau khi xác thực lại và việc đăng xuất thực sự kết thúc phiên.
• Tín hiệu cảnh báo: Không có tùy chọn MFA, token phiên có thể dự đoán được hoặc sử dụng lại giá trị phiên cũ sau khi đăng xuất.

8. Lỗi toàn vẹn phần mềm và dữ liệu

Danh mục này bao gồm giải tuần tự không an toàn, bản cập nhật chưa ký và pipeline CI/CD không an toàn. Tập trung vào việc liệu các thành phần quan trọng có được xác minh trước khi thực thi không.

• Nội dung kiểm tra: Các phụ thuộc và plugin có được cài đặt từ nguồn đáng tin cậy với kiểm tra toàn vẹn không? Đầu vào giải tuần tự có được xác thực và giới hạn không?
• Cách kiểm tra: Xem xét các script xây dựng và triển khai để tìm các artifact chưa ký. Kiểm tra các tính năng nhập dữ liệu với tải trọng bị l���i hoặc không mong đợi. Xác nhận rằng cơ chế cập nhật tự động xác minh chữ ký.
• Tín hiệu cảnh báo: Thiếu băm toàn vẹn, gói chưa ký hoặc giải tuần tự dữ liệu không đáng tin cậy mà không có kiểm tra kiểu nghiêm ngặt.

9. Lỗi nhật ký và giám sát bảo mật

Không có nhật ký và giám sát phù hợp, các cuộc tấn công có thể không đư��c phát hiện. Hãy đảm bảo rằng các sự kiện liên quan đến bảo mật được ghi lại và có thể xem xét.

• Nội dung kiểm tra: Các lần đăng nhập, từ chối truy cập và hành động rủi ro cao có được ghi nhật ký với thông tin ngữ cảnh hữu ích không? Nhật ký có được bảo vệ khỏi việc thay đổi và hiển thị quá mức không?
• Cách kiểm tra: Kích hoạt các lỗi đăng nhập, lỗi quyền và các sự kiện quy trình công việc quan trọng. Xác minh rằng nhật ký bao gồm dấu thời gian, định danh người dùng và ngữ cảnh yêu cầu. Xác nhận rằng nhật ký được gửi đến hệ thống trung tâm và lưu trữ phù hợp.
• Tín hiệu cảnh báo: Thiếu nhật ký cho các sự kiện chính, dữ liệu nhạy cảm được ghi vào nhật ký hoặc không có cảnh báo khi lỗi lặp lại.

10. Giả mạo yêu cầu phía máy chủ (SSRF)

SSRF xảy ra khi ứng dụng gửi yêu cầu đến các URL do người dùng kiểm soát mà không có xác minh phù hợp. Điều này có thể làm lộ các hệ thống nội bộ.

• Nội dung kiểm tra: Các trường đầu vào URL, webhook, trình nhập tệp hoặc trình hiển thị tài liệu có gửi yêu cầu đi không? Các địa chỉ nội bộ có bị chặn không?
• Cách kiểm tra: Cung cấp URL trỏ đến localhost, dải IP riêng và endpoint metadata đám mây. Xác nhận rằng ứng dụng chặn hoặc xử lý các đích này. Xem xét danh sách cho phép và quy tắc mạng giới hạn truy cập đi.
• Tín hiệu cảnh báo: Yêu cầu thành công đến địa chỉ nội bộ, phản hồi tiết lộ chi tiết dịch vụ nội bộ hoặc thiếu kiểm soát lưu lượng đi.

Cách sử dụng danh sách kiểm thử này trong thực tế

Hãy coi danh sách này là cơ sở, không phải bài tập một lần. Thêm các kiểm tra này vào định nghĩa hoàn thành cho các tính năng xử lý xác thực, đầu vào người dùng, thanh toán hoặc dữ liệu nhạy cảm. Kết hợp danh sách kiểm thử với tự động hóa đơn giản ở những nơi có lợi, chẳng hạn như quét phụ thuộc, kiểm tra header và fuzzing đầu vào cơ bản. Lưu trữ các trường hợp kiểm thử, phát hiện và kết quả kiểm tra lại để tiến trình được rõ ràng qua các sprint.

Đối với các nhóm lớn, phân chia trách nhiệm: lập trình viên xác minh các kiểm soát cấp mã trong quá trình triển khai, QA xác thực các luồng đầu cuối trong staging và đánh giá bảo mật tập trung vào các khu vực rủi ro cao. Xem xét lại danh sách kiểm thử mỗi khi kiến trúc thay đổi, các thành phần bên thứ ba mới được thêm vào hoặc sự cố sản xuất cho thấy khoảng trống.

Quan trọng nhất, hãy giữ phạm vi thực tế. Bạn không cần phải bao quát mọi trường hợp biên trong mỗi bản phát hành. Tập trung vào các con đường mang rủi ro cao nhất, áp dụng các kiểm tra nhất quán và cải thiện phạm vi theo thời gian. Một quy trình ổn định, có thể lặp lại sẽ mang lại kết quả tốt hơn so với các chu kỳ kiểm thử thỉnh thoảng và quá lớn.