Danh sách kiểm tra email dành cho nhà phát triển: Từ yêu cầu đến hết hạn

Kiểm tra email không chỉ là xác nhận rằng một tin nhắn đã xuất hiện. Quá trình kiểm tra đáng tin cậy sẽ diễn ra sau sự kiện từ yêu cầu ứng dụng đến quá trình phân phối, hiển thị, hành động của người dùng, hết hạn và thử lại. Nó cũng kiểm tra xem luồng có bị lỗi một cách an toàn hay không.

Chỉ sử dụng danh sách kiểm tra này trên các hệ thống và tài khoản mà bạn sở hữu hoặc được phép kiểm tra. Không sử dụng hộp thư đến tạm thời để tạo tài khoản hàng loạt, trốn tránh giới hạn của trang web khác hoặc kiểm tra quy trình đặt lại của bên thứ ba mà không được phép. Once Email chỉ nhận tin nhắn; nó không gửi trả lời và không thể chứng minh điều gì đã xảy ra bên trong ứng dụng của người gửi.

1. Xác định một trường hợp kiểm thử trước khi yêu cầu thư

Ghi lại môi trường, bản dựng, trình duyệt, tính năng và kết quả mong đợi trước khi nhấn nút. Cung cấp cho mỗi lần chạy một mã định danh trung lập, chẳng hạn như signup-valid-address hoặc reset-expired-link; không đặt mật khẩu, mã thông báo hoặc địa chỉ cá nhân vào tên bài kiểm tra.

Chuẩn bị các trường hợp cho các đường dẫn mà sản phẩm thực sự hỗ trợ:

• yêu cầu đăng ký hoặc xác minh địa chỉ hợp lệ;
• một địa chỉ có lỗi đầu vào rõ ràng;
• yêu cầu lặp lại trong khi tin nhắn đầu tiên vẫn hợp lệ;
• mã đã hết hạn hoặc đã được sử dụng;
• yêu cầu đặt lại mật khẩu cho cả tài khoản hiện có và tài khoản không tồn tại;
• hủy, quay lại điều hướng và phiên trình duyệt thứ hai nếu có liên quan.

Hướng dẫn kiểm tra bảo mật web OWASP coi việc đặt lại là một lộ trình thay thế vào tài khoản và khuyên bạn nên xem lại mọi giao diện được hỗ trợ. Do đó, kế hoạch kiểm thử của bạn phải bao gồm giao diện web, ứng dụng di động và API riêng biệt khi hoạt động của chúng có thể khác nhau.

2. Kiểm tra phản hồi yêu cầu mà không liệt kê người dùng

Gửi một yêu cầu được ủy quyền và lưu ý phản hồi, trạng thái và thời gian hiển thị. Để khôi phục mật khẩu, các tài khoản hiện tại và không tồn tại không được tiết lộ tư cách thành viên tài khoản thông qua các tin nhắn hoặc thời gian phản hồi khác nhau rõ ràng.

Không tạo ra một mẫu lớn để kiểm tra điều này. Phối hợp kiểm tra tải, lạm dụng và giới hạn tốc độ với chủ sở hữu hệ thống, sử dụng môi trường chuyên dụng và dừng lại ở ranh giới được phê duyệt. Quên bảng mã gian lận mật khẩu của OWASP đề xuất các phản hồi nhất quán và biện pháp bảo vệ chống lại việc gửi tự động quá mức vì điểm cuối đặt lại có thể làm lộ sự tồn tại của tài khoản hoặc làm ngập hộp thư đến.

Xác minh rằng lần nhấp thứ hai không âm thầm tạo ra một bộ sưu tập bí mật hợp lệ đồng thời không an toàn. Chính sách dự định có thể vô hiệu hóa mã đầu tiên, sử dụng lại yêu cầu đang chờ xử lý hoặc cho phép số lượng được giới hạn một cách cẩn thận; nhóm sản phẩm phải xác định kết quả nào là chính xác.

3. Quan sát việc phân phối dưới dạng trạng thái tính thời gian, không phải xác nhận ngay lập tức

Bắt đầu hẹn giờ khi ứng dụng chấp nhận yêu cầu. Ghi lại thời điểm thông báo hiển thị nhưng sử dụng cửa sổ quan sát hợp lý thay vì coi độ trễ vài giây là lỗi. Thư đi qua hàng đợi và bộ lọc, do đó thời gian đến là một sự phân bổ chứ không phải là một hằng số cố định.

Khi sử dụng Once Email cho thử nghiệm rủi ro thấp được ủy quyền:

1. Tạo hoặc chọn địa chỉ chỉ nhận với đủ thời gian tồn tại.
2. Sao chép chính xác địa chỉ vào ứng dụng đang thử nghiệm.
3. Yêu cầu một tin nhắn và giữ hộp thư đến luôn mở.
4. Nếu nó không xuất hiện, hãy cố tình làm mới và làm theo danh sách kiểm tra khắc phục sự cố email xác minh.
5. Ghi lại yêu cầu và thời gian đến được quan sát theo giờ UTC, cùng với môi trường thử nghiệm.

Đừng cho rằng một tin nhắn bị thiếu chứng tỏ người gửi chưa bao giờ gửi nó. Nhật ký ứng dụng, sự kiện của nhà cung cấp và tiêu đề thư là những nguồn bằng chứng riêng biệt. Sử dụng giá trị tương quan do hệ thống thử nghiệm tạo ra khi có thể, nhưng không công khai giá trị đó nếu nó cấp quyền truy cập hoặc nhận dạng người dùng.

4. Xác thực tin nhắn theo nội dung và dữ liệu

So sánh chủ đề nhận được, miền người gửi và mục đích hiển thị với mẫu đã được phê duyệt. Kiểm tra các lựa chọn thay thế văn bản thuần túy và HTML khi ứng dụng tạo ra cả hai. Xem lại khoảng cách, khoảng cách, độ tương phản màu sắc và thứ tự có ý nghĩa của nội dung trên máy tính để bàn và chế độ xem hẹp trên thiết bị di động.

Sau đó kiểm tra dữ liệu biến:

• địa chỉ dự định kiểm tra xuất hiện ở nơi được yêu cầu và không có nơi nào ngoài dự kiến;
• tên môi trường đủ rõ ràng để tránh nhầm lẫn thư dàn dựng với thư sản xuất;
• ngày và báo cáo hết hạn sử dụng múi giờ rõ ràng;
• mã hoặc hành động được liên kết với trường hợp kiểm thử chính xác;
• liên kết sử dụng HTTPS và máy chủ dự kiến;
• không xuất hiện dấu vết ngăn xếp nội bộ, khóa API, mật khẩu hoặc dữ liệu khách hàng không liên quan.

Đừng mở một liên kết đáng ngờ chỉ để khám phá đích đến của nó. Sao chép thông báo HTML vào trình duyệt cục bộ email link checker để liệt kê các URL và tài nguyên từ xa mà không hiển thị email, sau đó so sánh máy chủ đích với thông số kiểm tra.

5. Thực hiện thành công, tái sử dụng và hết hạn

Đối với mã hoặc liên kết, hãy kiểm tra đường dẫn hạnh phúc đã được phê duyệt một lần. Xác nhận rằng nó chỉ thực hiện hành động dự định, tiếp cận đúng môi trường và không tiết lộ bí mật trong một thành phần trang hoặc sự kiện phân tích không cần thiết.

Tiếp theo, kiểm tra các chuyển tiếp bảo mật:

• bí mật sử dụng một lần sẽ ngừng hoạt động sau khi thành công;
• một bí mật hết hạn bị từ chối mà không hoàn thành hành động;
• một giá trị không đúng định dạng sẽ thất bại một cách an toàn;
• yêu cầu thay thế tuân theo quy tắc vô hiệu hóa được ghi lại;
• mở hành động trong một trình duyệt khác không bỏ qua ngữ cảnh bắt buộc;
• việc đặt lại mật khẩu không tự động làm suy yếu xác thực đa yếu tố hoặc để các phiên không mong muốn hoạt động.

OWASP khuyến nghị các bí mật đặt lại ngẫu nhiên, đủ dài, được lưu trữ an toàn, sử dụng một lần và sắp hết hạn. Nó cũng khuyến nghị các URL đặt lại HTTPS và các biện pháp bảo vệ chống đoán. Thử nghiệm của bạn phải xác minh hoạt động của sản phẩm chứ không phải cố gắng dùng vũ lực không kiểm soát được.

6. Thông báo kiểm tra lỗi và khôi phục

Người dùng cần bước tiếp theo hữu ích khi giao hàng bị trì hoãn, mã hết hạn hoặc liên kết đã được sử dụng. Xác nhận rằng lỗi không tiết lộ sự tồn tại của tài khoản, các đoạn bí mật hoặc cơ sở hạ tầng nội bộ. Giao diện phải cho phép thử lại hợp pháp mà không khuyến khích các yêu cầu nhanh chóng lặp đi lặp lại.

Đồng thời kiểm tra xem điều gì sẽ xảy ra khi hộp thư đến tạm thời hết hạn trước khi luồng tài khoản hoàn tất. Địa chỉ dùng một lần không phù hợp khi tài khoản cần khôi phục lâu dài, biên lai hoặc thông báo bảo mật. Hướng dẫn email tạm thời và vĩnh viễn giải thích khi nào địa chỉ cố định, được kiểm soát là giả định kiểm tra an toàn hơn.

7. Ghi lại kết quả tối thiểu, có thể lặp lại

Kết quả kiểm tra hữu ích bao gồm trường hợp, môi trường, bản dựng, dòng thời gian UTC, kết quả mong đợi, kết quả thực tế và một mục bằng chứng được biên tập lại cẩn thận. Nêu rõ vấn đề nằm ở việc tạo yêu cầu, gửi tin nhắn, nội dung, hành động, hết hạn hay khôi phục. Tránh đưa ra kết quả mơ hồ chẳng hạn như “email bị hỏng”.

Nếu bằng chứng chứa địa chỉ, mã xác minh, liên kết đặt lại, ID tin nhắn, cookie hoặc tên máy chủ nội bộ, thì đừng tải nó lên mà không thay đổi. Thực hiện theo hướng dẫn biên tập bằng chứng kiểm tra email trước khi đính kèm nó vào một vấn đề.

Danh sách kiểm tra quyết định phát hành

Trước khi đánh dấu luồng sẵn sàng, hãy xác nhận rằng các trường hợp thành công được ủy quyền đã vượt qua, các trường hợp tiêu cực không thành công một cách an toàn, các quy tắc thử lại và hết hạn phù hợp với đặc tả, nội dung hoạt động ở phạm vi hẹp, không có bí mật nào được nhập vào nhật ký hoặc phân tích và bằng chứng có thể tái tạo các lỗi mà không làm lộ thông tin xác thực có thể sử dụng được. Một lần gửi email thành công là bằng chứng hữu ích nhưng nó không phải là một bài kiểm tra luồng email hoàn chỉnh.