WordPress Bảo mật nhật ký gỡ lỗi: Tìm lỗi, bảo vệ dữ liệu

Nhà phát triển của bạn bật ghi nhật ký để theo dõi biểu mẫu bị hỏng. Biểu mẫu được cố định. Nhật ký tiếp tục phát triển.

Tệp đó có thể chứa nhiều thông báo lỗi. Việc ghi nhật ký được viết kém có thể nắm bắt được địa chỉ email, dữ liệu yêu cầu, đường dẫn tệp hoặc bí mật API. WordPress bảo mật nhật ký gỡ lỗi có nghĩa là thu thập đủ bằng chứng để sửa lỗi trong khi không cho công chúng xem bằng chứng đó.

Tách các lỗi màn hình khỏi nhật ký riêng tư

Trang đang hoạt động không được hiển thị kết quả gỡ lỗi thô cho khách truy cập. Nó có thể tiết lộ các chi tiết nội bộ và làm cho trang web trông có vẻ bị hỏng. Nhật ký riêng cung cấp cho nhóm một nơi để kiểm tra lỗi mà không cần đặt chúng vào trang.

WordPress sử dụng WP_DEBUG để bật chế độ gỡ lỗi. WP_DEBUG_LOG kiểm soát việc ghi nhật ký và WP_DEBUG_DISPLAY kiểm soát các thông báo trên trang. Các cài đặt này phục vụ các mục đích khác nhau. Tắt hiển thị không xóa tệp nhật ký.

các hướng dẫn gỡ lỗi chính thức mô tả các cài đặt. Đối với sự cố trực tiếp, hãy yêu cầu máy chủ hoặc nhà phát triển của bạn sử dụng cửa sổ ghi nhật ký ngắn, được kiểm soát.

Chọn một nơi được bảo vệ cho nhật ký

Khi được bật với cài đặt thực sự đơn giản, WP_DEBUG_LOG thường ghi vào wp-content/debug.log. WordPress cũng hỗ trợ đường dẫn nhật ký tùy chỉnh.

Ưu tiên một vị trí được máy chủ phê duyệt bên ngoài web root công khai. Đặt quyền truy cập tệp để chỉ dịch vụ và nhóm được yêu cầu mới có thể đọc được. Ngoài ra, hãy kiểm tra các công cụ sao lưu và vận chuyển nhật ký: tệp riêng tư vẫn có thể được sao chép sang đích công khai.

Nếu nhật ký phải nằm trong đường dẫn có thể truy cập được trên web, hãy chặn quyền truy cập tại máy chủ và xác minh khối đó. Đừng dựa vào tên tập tin khó đoán. Của chúng tôi hướng dẫn cấp quyền tập tin giải thích việc kiểm tra quyền sở hữu liên quan.

Ghi lại sự kiện, không phải bí mật

Các mục nhật ký hữu ích bao gồm dấu thời gian, mã lỗi, tính năng bị ảnh hưởng và ID yêu cầu. ID yêu cầu cho phép nhà phát triển theo dõi một lỗi trên các hệ thống mà không cần sao chép toàn bộ hồ sơ khách hàng.

Tránh ghi nhật ký mật khẩu, tiêu đề xác thực, dữ liệu thanh toán, mã thông báo riêng tư hoặc gửi biểu mẫu đầy đủ. Che dấu các trường nhạy cảm trước khi thư đến đĩa. Việc loại bỏ chúng sau này sẽ kém tin cậy hơn vì các bản sao có thể đã tồn tại.

Ví dụ: “Yêu cầu CRM không thành công: hết thời gian chờ; yêu cầu 427” có thể đủ để bắt đầu theo dõi. Việc tải toàn bộ tải trọng gửi đi có thể bộc lộ nhiều hơn những gì nhóm cần.

Của chúng tôi hướng dẫn quản lý bí mật bao gồm phản hồi nếu một khóa đã đạt đến nhật ký.

Đặt cửa sổ khắc phục sự cố hẹp

Viết ra lỗi và cách tái tạo nó. Lưu ý thời gian bắt đầu. Chạy thử nghiệm nhỏ nhất gây ra sự cố, sau đó kiểm tra các mục nhập trùng khớp.

Sử dụng dữ liệu giả trên một trang web tổ chức được bảo vệ khi bạn có thể. Nếu sự cố chỉ xảy ra trực tiếp, hãy thống nhất về thử nghiệm chính xác, ai có thể đọc nhật ký và khi nào việc ghi nhật ký bổ sung sẽ dừng lại.

Một thử nghiệm rõ ràng có thể là: gửi một biểu mẫu liên hệ thử nghiệm, kiểm tra xem email của nó có được xếp hàng đợi hay không và khớp với ID yêu cầu. Điều đó dễ dàng hơn để xem xét hơn là một ngày với các yêu cầu không bị hạn chế.

Xác minh rằng nhật ký không được công khai

Kiểm tra URL nhật ký đã biết khi đăng xuất. Máy chủ sẽ từ chối quyền truy cập hoặc không trả lại tệp như vậy. Ngoài ra, hãy kiểm tra các bản sao được đổi tên hoặc nén có thể được tạo bởi quá trình ghi nhật ký của riêng bạn.

Kiểm tra thông qua CDN và với sự trợ giúp của máy chủ của bạn, tại điểm gốc. Quy tắc biên không chứng minh rằng quyền truy cập trực tiếp vào máy chủ bị chặn. Bao gồm bất kỳ nhóm lưu trữ nào được sử dụng cho nhật ký được xuất.

Không dán nhật ký thô vào các diễn đàn công khai hoặc trình theo dõi vấn đề. Chia sẻ một mẫu ngắn, được biên tập lại thông qua kênh hỗ trợ đã được phê duyệt. Chỉ giữ những bằng chứng chưa được chỉnh sửa ở nơi nhóm cần.

Quản lý kích thước, tỷ lệ lưu giữ và cảnh báo

Cảnh báo ồn ào có thể lấp đầy dung lượng ổ đĩa ngay cả khi không có cuộc tấn công nào xảy ra. Đặt xoay vòng nhật ký, giới hạn kích thước và thời gian lưu giữ. Các giá trị phù hợp phụ thuộc vào lưu lượng truy cập và tốc độ xem xét vấn đề của nhóm bạn.

Ai đó phải nhận được cảnh báo khi quá trình ghi nhật ký dừng lại hoặc mức sử dụng đĩa tăng lên. Của chúng tôi hướng dẫn giám sát an ninh giúp kết nối các lỗi với các sự kiện khác của trang web.

Sau khi khắc phục, hãy tắt cài đặt gỡ lỗi tạm thời, xác nhận tính năng ghi nhật ký bình thường vẫn hoạt động và xử lý các tệp cũ theo chính sách lưu giữ của bạn. Kiểm tra để đảm bảo các bản sao lưu không giữ bí mật bị lộ lâu hơn dự định.

Nếu nhật ký gỡ lỗi bị lộ

Trước tiên hãy hạn chế quyền truy cập và bảo quản bằng chứng cần thiết để đánh giá sự kiện. Xác định dữ liệu trong tệp, thời gian hiển thị và mọi nội dung tải xuống mà bạn có thể xác nhận.

Xoay những bí mật có thể đã bị rò rỉ. Việc xóa tệp sẽ không thu hồi khóa đã sao chép. Sử dụng của chúng tôi kế hoạch ứng phó sự cố để theo dõi quá trình phục hồi và theo dõi công việc.

Nếu nhóm của bạn cần trợ giúp để có thể lặp lại điều này, chúng tôi dịch vụ bảo trì có thể bao gồm việc gỡ lỗi an toàn và đánh giá nhật ký.

Các câu hỏi thường gặp

Việc tắt WP_DEBUG có xóa debug.log không?

Không. Việc thay đổi cài đặt sẽ không xóa tệp hiện có. Xem lại nhật ký cũ và xử lý chúng theo chính sách lưu giữ của bạn.

Tôi có thể giữ WordPress lỗi đăng nhập trong quá trình sản xuất không?

Có, với thiết lập ghi nhật ký có kiểm soát. Ngăn chặn lỗi khỏi các trang công khai, bảo vệ quyền truy cập nhật ký, hạn chế dữ liệu nhạy cảm và quản lý kích thước cũng như lưu giữ tệp.

Nhật ký gỡ lỗi có an toàn không nếu URL của nó khó đoán?

Không. Sử dụng các biện pháp kiểm soát quyền truy cập hoặc một vị trí bên ngoài web root công cộng, sau đó kiểm tra xem tệp có thể được tải xuống không.

Tôi nên làm gì nếu khóa API xuất hiện trong nhật ký công khai?

Thu hồi hoặc xoay phím và đánh giá mức độ phơi sáng. Chỉ xóa nhật ký không ngăn được ai đó sử dụng bí mật đã sao chép.