A2-Lỗi sai lầm trong kiểm tra định danh - Broken Authentication and Session Management

Tìm hiểu về Lỗi Sai lầm trong kiểm tra định danh

2. A2 – Sai lầm trong kiểm tra định danh

Kẻ tấn công có thể là những kẻ tấn công nặc danh, hoặc người người dùng sở hữu tài khoản muốn ăn cắp thông tin từ tài khoản khác. Cũng nên cân nhắc những đối tượng nội bộ muốn che dấu hành động Kẽ tấn công lợi dụng những sơ hở trong các đoạn mã kiểm tra định danh (ví dụ: xem tài khoản, password, ID phân làm việc) để giả mạo người dùng Người phát triển thường xuyên tự xây dựng những mô hình chứng thực và quản lý các phiên làm việc, nhưng xây dựng đúng cách thì không dễ. Kết quả là những cái tùy chọn đó thường xuyên có lỗi trong nhiều phần như đăng xuất, quản lý password, thời gian chờ, ghi nhớ người dùng, câu hỏi bí mật, cập nhật tài khoản v.v. Tìm những lỗi này có thể rất khó khăn bởi vì các cách triển khai có thể độc lập, không giống nhau. Lỗi như thế có thể cho phép một vài hoặc toàn bộ tài khoản bị tấn công. Khi đã thành công, kẻ tấn công có thể làm nhiều thứ dưới quyền của nạn nhân. Những tài khoản đặc quyền thường là mục tiêu chính Ta cần cân nhắc đến giá trị của những hệ thống và dữ liệu bị ảnh hưởng. Cũng nên cân nhắc đến tác động kinh tế của việc lỗi này bị trình bày trước công luận

Tôi có bị mắc lỗi không ? Thông tin tài khoản và phiên làm việc là những thứ cần được bảo vệ:

Những thông tin tài khoản có được bảo vệ khi lưu trữ dưới dạng băm hoặc mã hóa không ? Xem A7
Thông tin có thể bị đoán ra hoặc thay thế vì những điểm yếu trong các chương trình quản lý tài khoản hay không ? (tạo tài khoản, đồi password, lấy lại password, điểm yếu trong id phiên làm việc)
ID phiên làm việc có hiển thị trong URL không
ID phiên làm việc có thể bị giả mạo bằng các phương pháp định hình phiên làm việc hay không
Id phiên làm việc có thời gian chờ không và người dùng có thể đăng xuất không ?
Id phiên làm việc có thay đổi sau khi người dùng đăng nhập lại không
Password, Id phiên làm việc và những thông tin khác có được gửi đi sử dụng TLS connection không ? Xem thêm A9 Xem ASVS phần những yêu cầu V2 và V3 để biết thêm chi tiết Làm cách nào để ngăn chặn ? Phương pháp được khuyến khích cho một tổ chức là cho phép người phát triển truy cập:
Một tập hợp những phương thức quản lý định danh mạnh. Nó cho phép: a) Đáp ứng tất cả những yêu cầu của kiểm tra định danh được định nghĩa trong OWASP’s Application Security Verification Standard (ASVS) phần V2 (chứng thực) và V3 (quản lý phiên làm việc) b) Có một giao diện đơn giản cho người phát triển. Hãy xem xét ESAPI Authentication and User APIs như một ví dụ điển hình cho việc sử dụng, phát triển
Cũng nên bỏ nhiều công sức để tránh bị ăn cắp phiên làm việc qua lỗi XSS , Xem thêm A2

Vi dụ về kịch bản tấn công: Kịch bản 1: Ứng dụng đặt vé máy bay cho phép viết lại URL, đặt id phiên làm việc trong URL http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii Một người dùng bình thường muốn cho người bạn của anh ta biết về việc bán vé. Anh ta email liên kết trên mà không biết anh ta đang gửi id phiên làm việc của mình. Người bạn của anh ta sử dụng liên kết đó có thể sử dụng phiên làm việc và cả thẻ tín dụng Kịch bản 2: Thời gian chờ của ứng dụng không được chỉnh hợp lý. Người dung sử dụng một máy công cộng để truy cập vào trang web. Thay vì chọn “đăng xuất” anh ta chỉ đóng trình duyệt và đi. Một người khác sử dụng cùng trình duyệt đó vài giờ sau vẫn có thể sử dụng phiên làm việc đó Kịch bản 3: Người nội bộ hoặc kẻ tấn công có quyền truy cập đến cơ sở dữ liệu lưu trữ password. Password không được mã hóa cho phép kẻ tấn công ăn cắp được những tài khoản đó