Thử nghiệm truyền thông tin xác thực xác minh rằng các ứng dụng web mã hóa dữ liệu xác thực trong quá trình truyền. Mã hóa này ngăn những kẻ tấn công chiếm đoạt tài khoản bằng cách đánh hơi lưu lượng mạng. Các ứng dụng web sử dụng HTTPS để mã hóa thông tin trong quá trình truyền cho cả máy khách đến máy chủ và máy chủ với máy khách. Khách hàng có thể gửi hoặc nhận dữ liệu xác thực trong các tương tác sau:
- Khách hàng gửi thông tin đăng nhập để yêu cầu đăng nhập
- Máy chủ phản hồi đăng nhập thành công bằng mã thông báo phiên
- Ứng dụng khách đã xác thực sẽ gửi mã thông báo phiên để yêu cầu thông tin nhạy cảm từ trang web
- Một khách hàng gửi mã thông báo đến trang web nếu họ quên mật khẩu của mình
Việc không mã hóa bất kỳ thông tin đăng nhập nào trong số này khi chuyển tiếp có thể cho phép những kẻ tấn công bằng các công cụ dò tìm mạng xem thông tin đăng nhập và có thể sử dụng chúng để đánh cắp tài khoản của người dùng. Kẻ tấn công có thể đánh hơi lưu lượng truy cập trực tiếp bằng cách sử dụng Wireshark hoặc các công cụ tương tự hoặc chúng có thể thiết lập proxy để nắm bắt các yêu cầu HTTP. Dữ liệu nhạy cảm phải được mã hóa khi chuyển tiếp để ngăn chặn điều này.
Các bài viết liên quan:
Thực tế là lưu lượng truy cập được mã hóa không nhất thiết có nghĩa là nó hoàn toàn an toàn. Bảo mật cũng phụ thuộc vào thuật toán mã hóa được sử dụng và độ mạnh của các khóa mà ứng dụng đang sử dụng. Xem Kiểm tra bảo mật lớp truyền tải yếu để xác minh thuật toán mã hóa là đủ.
Mục tiêu kiểm tra
Đánh giá xem liệu bất kỳ trường hợp sử dụng nào của trang web hoặc ứng dụng khiến máy chủ hoặc máy khách trao đổi thông tin xác thực mà không cần mã hóa.
Làm thế nào để kiểm tra
Để kiểm tra quá trình truyền thông tin xác thực, hãy nắm bắt lưu lượng truy cập giữa máy khách và máy chủ ứng dụng web cần thông tin xác thực. Kiểm tra thông tin đăng nhập được chuyển trong khi đăng nhập và trong khi sử dụng ứng dụng với một phiên hợp lệ. Để thiết lập cho bài kiểm tra:
- Thiết lập và bắt đầu một công cụ để nắm bắt lưu lượng truy cập, chẳng hạn như một trong những công cụ sau:
- Các công cụ dành cho nhà phát triển của trình duyệt web
- Một proxy bao gồm OWASP ZAP
- Tắt bất kỳ tính năng hoặc plugin nào khiến trình duyệt web ưa thích HTTPS. Một số trình duyệt hoặc tiện ích mở rộng, chẳng hạn như HTTPS Everywhere, sẽ chống lại việc buộc phải duyệt web bằng cách chuyển hướng các yêu cầu HTTP đến HTTPS.
Trong lưu lượng truy cập đã thu thập, hãy tìm kiếm dữ liệu nhạy cảm bao gồm những thông tin sau:
- Cụm mật khẩu hoặc mật khẩu, thường bên trong nội dung thư
- Mã thông báo, thường là bên trong cookie
- Mã đặt lại tài khoản hoặc mật khẩu
Đối với bất kỳ thư nào chứa dữ liệu nhạy cảm này, hãy xác minh trao đổi đã xảy ra bằng HTTPS (chứ không phải HTTP). Các ví dụ sau đây hiển thị dữ liệu được chụp cho biết các bài kiểm tra đạt hoặc không đạt, trong đó ứng dụng web nằm trên máy chủ có tên www.example.org.
Đăng nhập
Tìm địa chỉ của trang đăng nhập và cố gắng chuyển giao thức sang HTTP. Ví dụ: URL cho duyệt bắt buộc có thể giống như sau: http://www.example.org/login.
Nếu trang đăng nhập bình thường là HTTPS, hãy thử xóa “S” để xem trang đăng nhập có tải dưới dạng HTTP hay không.
Đăng nhập bằng tài khoản hợp lệ trong khi cố gắng buộc sử dụng HTTP không được mã hóa. Trong một bài kiểm tra vượt qua, yêu cầu đăng nhập phải là HTTPS:
Trong đăng nhập, thông tin xác thực được mã hóa do URL yêu cầu HTTPS
Nếu máy chủ trả về thông tin cookie cho mã thông báo phiên, cookie cũng phải bao gồm thuộc tính Bảo mật để tránh máy khách để lộ cookie qua các kênh không được mã hóa sau này. Tìm từ khóa Bảo mật trong tiêu đề phản hồi.
Kiểm tra không thành công nếu bất kỳ đăng nhập nào chuyển thông tin xác thực qua HTTP, tương tự như sau:
Trong ví dụ thử nghiệm thất bại này:
URL tìm nạp là http: // và nó hiển thị văn bản rõ ràng j_username và j_password thông qua dữ liệu bài đăng.
Trong trường hợp này, vì quá trình kiểm tra đã hiển thị dữ liệu POST hiển thị tất cả thông tin đăng nhập, nên không có tiêu đề phản hồi kiểm tra điểm (cũng có thể sẽ hiển thị mã thông báo phiên hoặc cookie).
Tạo tài khoản
Để kiểm tra việc tạo tài khoản không được mã hóa, hãy cố gắng buộc duyệt đến phiên bản HTTP của việc tạo tài khoản và tạo tài khoản, ví dụ: http://www.example.org/securityRealm/createAccount
Kiểm tra sẽ vượt qua nếu ngay cả sau khi bắt buộc duyệt, khách hàng vẫn gửi yêu cầu tài khoản mới thông qua HTTPS:
Tương tự như đăng nhập, hầu hết các ứng dụng web tự động cung cấp mã thông báo phiên khi tạo tài khoản thành công. Nếu có Set-Cookie :, hãy xác minh rằng nó có Bảo mật; thuộc tính nữa.
Kiểm tra không thành công nếu khách hàng gửi yêu cầu tài khoản mới với HTTP không được mã hóa:
Biểu mẫu tạo người dùng Jenkins này hiển thị tất cả các chi tiết người dùng mới (tên, họ tên và mật khẩu) trong dữ liệu POST đến trang tài khoản tạo HTTP
Đặt lại mật khẩu, thay đổi mật khẩu hoặc thao tác tài khoản khác
Tương tự như đăng nhập và tạo tài khoản, nếu ứng dụng web có các tính năng cho phép người dùng thay đổi tài khoản hoặc gọi một dịch vụ khác bằng thông tin đăng nhập, hãy xác minh tất cả các tương tác đó là HTTPS. Các tương tác cần kiểm tra bao gồm:
- Các biểu mẫu cho phép người dùng xử lý mật khẩu bị quên hoặc thông tin đăng nhập khác
- Biểu mẫu cho phép người dùng chỉnh sửa thông tin đăng nhập
- Các biểu mẫu yêu cầu người dùng xác thực với nhà cung cấp khác (ví dụ: xử lý thanh toán)
Truy cập tài nguyên khi đăng nhập
Sau khi đăng nhập, hãy truy cập tất cả các tính năng của ứng dụng, bao gồm cả các tính năng công khai mà không nhất thiết phải đăng nhập để truy cập. Buộc duyệt đến phiên bản HTTP của trang web để xem liệu máy khách có bị rò rỉ thông tin đăng nhập hay không.
Quá trình kiểm tra sẽ vượt qua nếu tất cả các tương tác gửi mã thông báo phiên qua HTTPS tương tự như ví dụ sau:
Mã phiên trong cookie được mã hóa vì URL yêu cầu là HTTPS
Kiểm tra không thành công nếu trình duyệt gửi mã thông báo phiên qua HTTP trong bất kỳ phần nào của trang web, ngay cả khi bắt buộc phải duyệt để kích hoạt trường hợp này:
Yêu cầu GET đã hiển thị mã thông báo phiên JSESSIONID (từ trình duyệt đến máy chủ) trong URL yêu cầu http://www.example.org/
Biện pháp khắc phục hậu quả
Sử dụng HTTPS cho toàn bộ trang web. Triển khai HSTS và chuyển hướng bất kỳ HTTP nào sang HTTPS. Trang web nhận được những lợi ích sau khi sử dụng HTTPS cho tất cả các tính năng của nó:
Nó ngăn những kẻ tấn công sửa đổi các tương tác với máy chủ web (bao gồm cả việc đặt phần mềm độc hại JavaScript thông qua một bộ định tuyến bị xâm phạm).
Nó tránh để mất khách hàng vào những cảnh báo trang web không an toàn. Các trình duyệt mới đánh dấu các trang web dựa trên HTTP là không an toàn.
Nó làm cho việc viết một số ứng dụng dễ dàng hơn. Ví dụ: API Android cần ghi đè lên kết nối với bất kỳ thứ gì qua HTTP.
Nếu việc chuyển sang HTTPS là rườm rà, hãy ưu tiên sử dụng HTTPS cho các thao tác nhạy cảm trước. Về trung hạn, hãy lên kế hoạch chuyển đổi toàn bộ ứng dụng sang HTTPS để tránh mất khách hàng để thỏa hiệp hoặc các cảnh báo về HTTP không an toàn. Nếu tổ chức chưa mua chứng chỉ cho HTTPS, hãy xem Let’s Encrypt hoặc các tổ chức phát hành chứng chỉ miễn phí khác trên máy chủ.
