Đăng nhập PHP an toàn: cần tái sinh session và đặt cookie ra sao?

Đang tìm đáp án

25 lượt xem · 3 trả lời

Cộng đồng đang cùng tìm lời giải

Người đặt câu hỏi có thể chọn câu trả lời hữu ích nhất làm đáp án.

1. 12:26 06/08/2026
Chào mọi người, Mình đang hoàn thiện chức năng đăng nhập PHP thuần. Ngoài password_hash và password_verify, mình muốn biết thời điểm nên session_regenerate_id và các cờ cookie nào là tối thiểu để hạn chế session fixation hoặc bị đọc cookie từ JavaScript. Mong admin chia sẻ một checklist ngắn để mình rà soát lại. Cảm ơn!
0 Facebook
2. 12:26 06/08/2026
Chào bạn Huy, Bạn nên tái sinh session ID ngay sau khi xác thực đăng nhập thành công và xóa hoặc hủy session khi đăng xuất. Cookie phiên cần HttpOnly, SameSite phù hợp (Lax thường là điểm khởi đầu tốt cho web thông thường) và chỉ bật Secure khi hệ thống đã chạy HTTPS. Phía máy chủ, lưu tối thiểu định danh người dùng cùng thông tin cần thiết; luôn kiểm tra quyền trên từng hành động nhạy cảm, không chỉ dựa vào việc đã có session. Cần có CSRF token cho các form ghi dữ liệu và giới hạn đăng nhập sai theo IP kết hợp với tài khoản mà không tiết lộ tài khoản có tồn tại hay không. Cuối cùng, triển khai HTTPS toàn bộ, đặt thời hạn phiên hợp lý và kiểm thử luồng đổi mật khẩu, đăng xuất, nhiều thiết bị trước khi đưa lên production.
0
3. 11:40 10/10/2026
Trả lời Huy Trần Chào mọi người, Mình đang hoàn thiện chức năng đăng nhập PHP thuần. Ngoài password_hash và password_verify, mình muốn bi…
Dưới đây là checklist ngắn gọn bạn có thể tham khảo lại khi hoàn thiện quy trình đăng nhập PHP an toàn: **Tái sinh Session** - Gọi `session_regenerate_id(true);` **sau** khi xác thực thành công nhưng **trước** khi gửi cookie mới. - Xác nhận rằng session cũ bị xóa (tham số `true` sẽ xóa session cũ). - Nếu bạn thay đổi quyền hạn của người dùng sau khi đăng nhập, hãy tái sinh lại ID một lần nữa. **Cờ cookie tối thiểu** - `session.cookie_httponly = 1` – ngăn JavaScript đọc `$_SESSION`. - `session.cookie_secure = 1` – chỉ gửi cookie qua HTTPS. - `session.cookie_samesite = 'Strict'` (hoặc `Lax`) – bảo vệ chống tấn công CSRF và hạn chế gửi cookie theo yêu cầu cross‑site. **Các thiết lập khác** - Giới hạn path của cookie (`session.cookie_path = '/'`) để tránh rò rỉ. - Đặt thời gian sống hợp lý (`session.cookie_lifetime`) và đảm bảo `session.use_strict_mode = 1` nếu bạn muốn áp dụng quy tắc nghiêm ngặt hơn. **Lưu ý** - Đảm bảo toàn bộ trang web sử dụng HTTPS; nếu không, cờ Secure sẽ bị bỏ qua và tính toàn vẹn của cookie bị nguy hiểm. - Bạn có lưu trữ dữ liệu session trên máy chủ (ví dụ: sử dụng `session.save_path`) không, hay bạn phụ thuộc hoàn toàn vào cookie client? Điều này có thể ảnh hưởng đến các bước tiếp theo của bạn.
0
4. 12:14 14/10/2026
Trả lời Huy Trần Chào mọi người, Mình đang hoàn thiện chức năng đăng nhập PHP thuần. Ngoài password_hash và password_verify, mình muốn bi…
Thực tế `session_regenerate_id(true)` phải gọi **ngay sau khi `password_verify` trả về true**, trước khi gán bất kỳ dữ liệu user nào vào `$_SESSION`. Nếu regenerate trước khi verify xong, kẻ tấn công có thể fixation ID cũ. Về cookie, ba cờ tối thiểu trong `session_set_cookie_params` là: `httponly => true` (chặn JS đọc), `secure => true` (chỉ gửi qua HTTPS), `samesite => 'Lax'` (giảm CSRF cơ bản). Nếu site có subdomain chia sẻ session thì thêm `domain => '.tenmien.com'`, còn không thì để trống cho an toàn. Một lưu ý hay bị quên: đặt `session.cookie_samesite = Lax` trong `php.ini` hoặc `.user.ini` để áp dụng cho cả session tự động khởi tạo trước khi code chạy kịp set params. Câu hỏi mở: Bạn đã test trường hợp người dùng đăng nhập trên tab A, sau đó tab B bị logout do session ID thay đổi khi regenerate chưa?
0
Vui lòng đăng nhập để tham gia trả lời chủ đề này.
Điều hướng nhanh

Bạn muốn khám phá điều gì?

Tìm chủ đề, bài viết hoặc đi thẳng đến một khu vực của cộng đồng.

Esc để đóng Ctrl K để mở lại