Xác thực và quản lý phiên bao gồm tất cả các khía cạnh của việc xử lý xác thực người dùng và quản lý các phiên hoạt động. Xác thực là một khía cạnh quan trọng của quá trình này, nhưng ngay cả các cơ chế xác thực vững chắc cũng có thể bị phá hủy bởi các chức năng quản lý thông tin xác thực bị lỗi, bao gồm thay đổi mật khẩu, quên mật khẩu, nhớ mật khẩu, cập nhật tài khoản và các chức năng liên quan khác. Bởi vì các cuộc tấn công “đi qua” có khả năng xảy ra đối với nhiều ứng dụng web, tất cả các chức năng quản lý tài khoản nên yêu cầu xác thực lại ngay cả khi người dùng có id phiên hợp lệ.
Xác thực người dùng trên web thường liên quan đến việc sử dụng id người dùng và mật khẩu. Có các phương pháp xác thực mạnh mẽ hơn có sẵn thương mại như token mã hóa dựa trên phần mềm và phần cứng hoặc sinh trắc học, nhưng những cơ chế như vậy có chi phí cấm đoán đối với hầu hết các ứng dụng web. Một loạt các lỗi trong quản lý tài khoản và phiên có thể dẫn đến việc tài khoản người dùng hoặc quản trị hệ thống bị xâm phạm. Các nhóm phát triển thường đánh giá thấp độ phức tạp của việc thiết kế một lược đồ xác thực và quản lý phiên mà bảo vệ đầy đủ thông tin xác thực trong tất cả các khía cạnh của trang web. Các ứng dụng web phải thiết lập các phiên để theo dõi dòng yêu cầu từ mỗi người dùng. HTTP không cung cấp khả năng này, vì vậy các ứng dụng web phải tự tạo ra nó. Thường xuyên, môi trường ứng dụng web cung cấp khả năng phiên, nhưng nhiều nhà phát triển thích tạo token phiên của riêng mình. Trong cả hai trường hợp, nếu token phiên không được bảo vệ đúng cách, kẻ tấn công có thể chiếm đoạt một phiên hoạt động và giả mạo danh tính của một người dùng. Việc tạo ra một lược đồ để tạo token phiên mạnh và bảo vệ chúng trong suốt vòng đời của chúng đã trở nên khó khăn đối với nhiều nhà phát triển. Trừ khi tất cả thông tin xác thực và định danh phiên được bảo vệ bằng SSL mọi lúc và được bảo vệ khỏi sự tiết lộ từ các lỗi khác, chẳng hạn như scripting giữa các trang, kẻ tấn công có thể chiếm đoạt phiên của một người dùng và giả mạo danh tính của họ.
Giải pháp
Việc sử dụng cẩn thận và đúng cách các cơ chế xác thực và quản lý phiên tùy chỉnh hoặc sẵn có nên giảm đáng kể khả năng xảy ra vấn đề trong lĩnh vực này. Định rõ và tài liệu hóa chính sách của trang web của bạn về việc quản lý an toàn thông tin xác thực của người dùng là bước đầu tiên tốt. Đảm bảo rằng việc thực hiện của bạn tuân thủ một cách nhất quán chính sách này là chìa khóa để có một cơ chế xác thực và quản lý phiên an toàn và vững chắc. Một số lĩnh vực quan trọng bao gồm:
- Độ mạnh của mật khẩu – mật khẩu nên có các hạn chế yêu cầu kích thước tối thiểu và độ phức tạp cho mật khẩu. Độ phức tạp thường yêu cầu sử dụng các kết hợp tối thiểu của các ký tự chữ cái, số và/hoặc không chữ số trong mật khẩu của một người dùng (ví dụ: ít nhất một của mỗi loại). Người dùng nên được yêu cầu thay đổi mật khẩu của họ theo định kỳ. Người dùng nên được ngăn chặn không sử dụng lại các mật khẩu trước đó.
- Sử dụng mật khẩu – Người dùng nên bị hạn chế về số lần đăng nhập được xác định trên mỗi đơn vị thời gian và các lần đăng nhập thất bại lặp lại nên được ghi lại. Mật khẩu được cung cấp trong các lần đăng nhập thất bại không nên được ghi lại, vì điều này có thể tiết lộ mật khẩu của một người dùng cho bất kỳ ai có thể truy cập vào nhật ký này. Hệ thống không nên chỉ ra liệu tên người dùng hay mật khẩu đã sai nếu một lần đăng nhập thất bại. Người dùng nên được thông báo về ngày/giờ đăng nhập thành công cuối cùng của họ và số lần thất bại trong việc truy cập vào tài khoản của họ kể từ thời điểm đó.
- Kiểm soát thay đổi mật khẩu – Một cơ chế thay đổi mật khẩu duy nhất nên được sử dụng ở bất cứ nơi nào người dùng được phép thay đổi mật khẩu, bất kể tình hình. Người dùng luôn phải được yêu cầu cung cấp cả mật khẩu cũ và mới của họ khi thay đổi mật khẩu của họ (giống như tất cả thông tin tài khoản). Nếu mật khẩu bị quên được gửi qua email cho người dùng, hệ thống nên yêu cầu người dùng xác thực lại bất cứ khi nào người dùng đang thay đổi địa chỉ email của họ, nếu không, một kẻ tấn công tạm thời có quyền truy cập vào phiên của họ (ví dụ: bằng cách đi lên máy tính của họ trong khi họ đang đăng nhập) có thể đơn giản thay đổi địa chỉ email của họ và yêu cầu gửi mật khẩu ‘bị quên’.
- Lưu trữ mật khẩu – Tất cả các mật khẩu phải được lưu trữ dưới dạng băm hoặc mã hóa để bảo vệ chúng khỏi sự tiết lộ, bất kể chúng được lưu trữ ở đâu. Dạng băm được ưa chuộng vì nó không thể đảo ngược. Mã hóa nên được sử dụng khi cần mật khẩu dạng văn bản thuần túy, chẳng hạn như khi sử dụng mật khẩu để đăng nhập vào hệ thống khác. Mật khẩu không bao giờ được mã hóa cứng trong bất kỳ mã nguồn nào. Các khóa giải mã phải được bảo vệ mạnh mẽ để đảm bảo rằng chúng không thể bị lấy và sử dụng để giải mã tệp mật khẩu.
- Bảo vệ thông tin xác thực trong quá trình truyền – Kỹ thuật duy nhất hiệu quả là mã hóa toàn bộ giao dịch đăng nhập bằng cách sử dụng một thứ gì đó như SSL. Các biến đổi đơn giản của mật khẩu như băm nó trên máy khách trước khi truyền đi cung cấp ít bảo vệ vì phiên bản băm có thể đơn giản bị chặn và gửi lại mặc dù mật khẩu dạng văn bản thuần túy thực sự có thể không được biết.
- Bảo vệ ID phiên – Lý tưởng nhất, toàn bộ phiên của một người dùng nên được bảo vệ thông qua SSL. Nếu điều này được thực hiện, thì ID phiên (ví dụ: cookie phiên) không thể bị lấy từ mạng, đây là rủi ro lớn nhất về sự tiết lộ ID phiên. Nếu SSL không khả thi vì hiệu suất hoặc lý do khác thì chính ID phiên phải được bảo vệ theo các cách khác. Đầu tiên, chúng không bao giờ được bao gồm trong URL vì chúng có thể được lưu trong bộ nhớ cache của trình duyệt, gửi trong tiêu đề tham chiếu, hoặc vô tình chuyển tiếp đến một ‘bạn’. ID phiên nên dài, phức tạp, số ngẫu nhiên mà không thể dễ dàng đoán được. ID phiên cũng có thể được thay đổi thường xuyên trong suốt một phiên để giảm thời gian mà ID phiên là hợp lệ. ID phiên phải được thay đổi khi chuyển sang SSL, xác thực, hoặc các chuyển đổi lớn khác. ID phiên do người dùng chọn không bao giờ được chấp nhận.
- Danh sách tài khoản – Các hệ thống nên được thiết kế để tránh cho phép người dùng truy cập vào danh sách các tên tài khoản trên trang web. Nếu danh sách người dùng phải được trình bày, nên khuyến nghị sử dụng một hình thức của bí danh (tên màn hình) mà ánh xạ đến tài khoản thực được liệt kê thay thế. Như vậy, bí danh không thể được sử dụng trong một lần đăng nhập hoặc một số hack khác mà tấn công vào tài khoản của một người dùng.
- Bộ nhớ cache trình duyệt – Dữ liệu xác thực và phiên không bao giờ được gửi như một phần của GET, POST luôn luôn được sử dụng thay thế. Các trang xác thực nên được đánh dấu với tất cả các loại thẻ không lưu vào bộ nhớ cache để ngăn chặn ai đó sử dụng nút quay lại trong trình duyệt của một người dùng để sao lưu lại trang đăng nhập và gửi lại các thông tin xác thực đã nhập trước đó. Nhiều trình duyệt hiện nay hỗ trợ cờ AUTOCOMPLETE=OFF để ngăn chặn việc lưu trữ thông tin xác thực trong bộ nhớ cache tự động hoàn thành.
- Mối quan hệ tin tưởng – Kiến trúc trang web của bạn nên tránh sự tin tưởng ngầm giữa các thành phần bất cứ khi nào có thể. Mỗi thành phần nên xác thực chính nó với bất kỳ thành phần khác mà nó đang tương tác trừ khi có lý do mạnh mẽ để không làm như vậy (như hiệu suất hoặc thiếu một cơ chế có thể sử dụng). Nếu mối quan hệ tin tưởng được yêu cầu, các cơ chế thủ tục và kiến trúc mạnh mẽ nên được đặt để đảm bảo rằng sự tin tưởng như vậy không thể bị lạm dụng khi kiến trúc trang web phát triển theo thời gian.
Đối với việc quét lỗ hổng toàn diện và bảo vệ, hãy xem xét việc hợp tác với một giải pháp đáng tin cậy như INFRA (www.infrascan.net). INFRA cung cấp dịch vụ quét an ninh tiên tiến với check.website và dịch vụ giám sát để xác định và giải quyết tất cả các lỗ hổng, đảm bảo sự vững chắc của các ứng dụng web của bạn.