3.4 Các kiểu tấn công ứng dụng web phổ biến
3.4.2 Broken Authentication and Session Management
a. Mô tả
Các cuộc tấn công vào vấn đề xác thực và quản lý phiên là một trong những kiểu tấn công cũng nguy hại không kém Injection và được xếp hạng thứ hai trong
danh sách Top 10 của OWASP năm 2017 (mới nhất). Xác thực là một khía cạnh quan trọng, tuy nhiên một vài chức năng có thể làm suy yếu những cơ chế xác thực ví dụ như quên mật khẩu, nhớ mật khẩu, thay đổi mật khẩu, cập nhật tài khoản và các chức năng khác có liên quan. Chính vì vậy, được khuyến cáo là các chức năng liên quan tới quản lý tài khoản nên được yêu cầu xác minh lại ngay cả khi người dùng có một Session ID hợp lệ.
Xác thực người dùng trên web thường được dùng bằng tên đăng nhập và mật khẩu. Có nhiều cách xác thực ở phần mềm lẫn phần cứng đó là dùng thẻ hoặc sinh trắc học tuy nhiên với các ứng dụng web, đó là điều hầu như khơng thể thực hiện vị vấn đề chi phí.
Những nhóm phát triển thường khơng chú trọng đến sự phức tạp của quản lý hệ thống tài khoản. Các ứng dụng web phải được thiết lập theo dõi session từ mỗi người dùng. Giao thức HTTP không hỗ trợ điều này, do đó các ứng dụng web phải tự làm cho mình. Trong nhiều trường hợp, các lập trình viên thường tạo cho user những session token. Và nếu những session token khơng đúng cách thì kẻ tấn cơng có thể chiếm quyền điều khiển và có một session hợp lệ mà không cần phải biết tên đăng nhập và mật khẩu. Và việc tạo ra một chương trình để tạo ra các session token mạnh và bảo vệ chúng trong suốt vòng đời đã được chứng minh là điều rất khó đối với các lập trình viên. Trừ khi các thơng tin xác thực và định danh người dùng được bảo vệ bằng SSL tại mọi thời điểm và ln được bảo vệ, thì về mặt lý thuyết, kẻ tấn cơng hồn tồn có thể chiếm quyền làm việc của người dùng và giả danh họ.
b. Session Hijacking
Session Hijacking [7] là một kiểu tấn công “hijack” điển hình vào session của hệ thống, bao gồm việc khai thác các cơ chế kiểm soát session vốn thường được bảo vệ bằng session token.
Trong giao thức HTTP, có rất nhiều kết nối TCP được thiết lập và các máy chủ web cần có một phương pháp để nhận biết các kết nối của mỗi người dùng. Cách hữu hiệu nhất đó chính là dựa trên token mà máy chủ web gửi tới người dùng
sau khi đã xác thực thành công. Một session token thường được tạo ra như là một chuỗi có độ dài khơng cố định và được sử dụng bằng nhiều cách, ví dụ như trong URL, trong header của HTTP như một cookie, trong phần khác của header HTTP, hoặc ngay cả trong phần body của HTTP.
Cuộc tấn công Session Hijacking diễn ra bằng cách đánh cắp session token hoặc dự đoán một session token để chiếm quyền xác thực với máy chủ web. Những cách phổ biến nhất là
- Dự đoán session token. - Session sniffing
- Các cuộc tấn cơng trên phía client (XSS, mã Javascript độc, Trojan...) - Cuộc tấn công man-in-the-middle.
- Cuộc tấn cơng man-in-the-browser. c. Ví dụ về Session Hijacking
Ví dụ 1
Trong ví dụ này, kẻ tấn cơng đầu tiên sử dụng một phần mềm có chức năng sniffer để bắt một session token hợp lệ gọi là “session ID” và sau đó sử dụng nó để xác thực với máy chủ web.
Ví dụ 2 Cross-site scripting
Kẻ tấn cơng có thể lấy được session token bằng cách sử dụng các mã độc hoặc những chương trình phía client. Ví dụ dưới đây cho thấy kẻ tấn cơng sử dụng Cross- site Scriping (XSS) để lấy được session ID của người dùng. Khi người dùng click vào một link mà do kẻ tấn cơng gửi tới có chứa mã độc, người dùng sẽ trở thành nạn nhân và đoạn mã độc sẽ được chạy ở phía client. Ví dụ này xuất ra thơng báo session ID và sẽ gửi về kẻ tấn cơng.
Ví dụ 3
Một trang web để session ID ngay trên trình duyệt
Chỉ cần một ai đó gõ hoặc dán đoạn URL này vào trình duyệt là họ hồn tồn được xác thực mà khơng cần biết tên hay mật khẩu.
d. Cách bảo vệ khỏi những cuộc tấn công về session
Sử dụng cẩn thận các chức năng hoặc tắt các cơ chế xác thực và quản lý session sẽ giảm đáng kể rủi ro. Việc xác định và lập các chính sách về quản lý an tồn thơng tin người dùng là một khởi đầu tốt. Việc đảm bảo tính nhất quán trong cơ chế quản lý này là chìa khóa để có một cơ chế xác thực và quản lý session mạnh mẽ. Một số điều chính
- Độ mạnh của mật khẩu cần phải có kích thước đủ lớn và độ mạnh thích hợp. Mật khẩu được khuyến cáo là nên có sự kết hợp của chữ, số và cả các kí tự đặc biệt, và người dùng nên được yêu cầu thay đổi mật khẩu định kỳ. Người dùng nên được ngăn chặn sử dụng lại các mật khẩu trước đó.
- Cách sử dụng mật khẩu người dùng nên bị hạn chế số lần đăng nhập trong một khoảng thời gian cụ thể và những lần đăng nhập không thành công cần phải được ghi lại. Và mật khẩu được cung cấp trong lần đăng nhập thành công không nên được ghi lại. Hệ thống cũng khơng nên chỉ ra chính xác là tên đăng nhập hay mật khẩu đã sai, thay vào đó là một thơng báo chung chung kiểu như là “Invalid Username or Password”, kẻ tấn công sẽ không thể biết được chắc chắn rằng trường nào đã đúng trong hai trường đó. Và người dùng nên được thơng báo về lần đăng nhập thành cơng cuối cùng của mình và số lượng lần truy cập không thành công vào tài khoản của họ trong quá khứ.
- Điều khiển việc thay đổi mật khẩu trong bất cứ tình huống nào, việc thay đổi mật khẩu phải được sử dụng một cơ chế duy nhất và nhất quán. Người dùng luôn luôn phải được yêu cầu cung cấp cả mật khẩu cũ và mật khẩu mới (giống tất cả các thông tin tài khoản khác). Nếu mật khẩu được gửi qua email, hệ thống phải yêu cầu người dùng xác thực lại bất cứ khi nào họ thay đổi địa chỉ email. Nếu khơng, có thể một ai đó có quyền truy cập máy tính của người dùng, thay đổi địa chỉ email và sử dụng chức năng quên mật khẩu để gửi mật khẩu đến cho họ.
- Lưu trữ mật khẩu tất cả mật khẩu phải được lưu trữ dưới dạng hash hoặc đã mã hóa để bảo vệ chúng bị phụ thuộc vào nơi lưu trữ. Hash rất được ưa thích vì nó khơng thể dịch ngược. Mã hóa khi sử dụng là vơ cùng cần thiết, mật khẩu khơng bao giờ được hardcode trong bất kì mã nguồn nào. Giải mã các phím cũng phải được bảo vệ mạnh mẽ để kẻ tấn công không thể nắm lấy và giải mã được mật khẩu.
- Bảo vệ chứng chỉ người dùng trong các giao dịch kỹ thuật được sử dụng phổ biến là SSL.
- Bảo vệ session ID lý tưởng nhất là bảo vệ session ID của người dùng thơng qua SSL. Nếu điều này được thực hiện, thì session ID hay cookie sẽ khơng bị “bắt” và đưa ra khỏi mạng, đây chính là rủi ro lớn nhất của session ID. Nếu SSL là không khả thi, cần phải bảo vệ session ID bằng những cách khác. Thứ nhất, session ID không bao giờ được truyền trên URL, gửi trong header hay là vơ tình gửi tới một người bạn nào đó. Session ID nên dài, phức tạp và khơng thể đoán ra và nên được thay đổi thường xuyên, phải thay đổi khi chuyển sang SSL và người dùng tự chọn session ID là không bao giờ được cho phép.
- Danh sách các tài khoản hệ thống phải được thiết kế sao cho người dùng không thể thấy được danh sách các tài khoản khác. Nếu buộc phải liệt kê ra danh sách người dùng, phải dùng tên thay thế và tên thay thế không thể được dùng để đăng nhập hay thực hiện một giao dịch nào khác.
- Cache của trình duyệt xác thực và dữ liệu về session không bao giờ được gửi đi bằng những cách thông thường như GET/POST, và phải dùng cái khác thay thế. Và trang xác thực phải được đánh dấu là không được lưu vào cache để tránh người dùng sử dụng nút “back” của trình duyệt.
- Tin tưởng các mối quan hệ trong tất cả các thành phần của một trang web hoặc ứng dụng web, cần tránh sự tin tưởng, nghĩa là mỗi thành phần cần được xác thực một cách độc lập trừ khi có một lý do nào đó khác để khơng làm điều này. Và nếu như vậy, cơ chế xác thực cần đảm bảo là không bị lạm dụng.