Session cookies
- Đọc tham khảo thêm bài sau về token authentication
- Cách đơn giản nhất để triển khai authentication theo dạng token, và cũng là cách được triển khai rất phổ biến trong các website, là sử dụng cookie. Một luồng đơn giản bao gồm: Sau khi người dùng xác thực danh tính bằng tài khoản, mật khẩu, …, hệ thống sẽ trả về 1 header Set-Cookie ở response, yêu cầu trình duyệt sẽ lưu 1 token ngẫu nhiên trong bộ nhớ cookie. Các kết nối tiếp theo vào trang web sẽ có đính kèm header Cookie chứa token. Hệ thống sẽ kiểm tra xem có người dùng nào gắn với token này không.
Ví dụ thực tế về session cookie
- Bạn đến phòng gửi đồ, gửi đồ của mình gồm ví tiền, đồ cá nhân, …
- Phòng gửi đồ cất đồ, và cho bạn 1 thẻ id là ID_NGUOI_DUNG_1, họ sẽ nhớ là với cái id này thì được lấy đống đồ kia
- Lần sau bạn tới với id trên, phòng gửi đồ sẽ cho bạn quyền được sử dụng đồ theo id này. Hiển nhiên id sẽ được sinh 1 cách ngẫu nhiên và bảo mật để khó lòng đoán được trong thực tế.
Session Fixation
Case kẻ tấn công có thể sử dụng như ví dụ trên:
- Hacker đầu tiên đến phòng gửi đồ, xưng danh và được cho thẻ ID là ID_NGUOI_DUNG_1
- Hacker bằng cách nào đó khiến người dùng cầm thẻ ID đó đi gửi đồ, phòng gửi đồ sẽ cất các đồ vào ID_NGUOI_DUNG_1
- Lúc này hacker dùng id kia đi lấy được đồ của người dùng.
Về việc làm sao để khiến người dùng cầm thẻ id đi gửi đồ thì có rất nhiều cách, có thể kể tới:
- Hacker gửi cho bạn 1 đường link kèm id bên trong, người dùng khi click vào, hệ thống yêu cầu đăng nhập. Sau khi người dùng đăng nhập bằng tài khoản mật khẩu của mình, hệ thống lại gán id của hacker vào các thông tin có thể truy cập của người dùng
- Tấn công theo subdomain. Ví dụ ta có trang web example.com và hacker.example.com. Hacker có quyền kiểm soát ở subdomain, khi người dùng vào hacker.example.com, người dùng đã nhận được id được sinh ra của hacker, và khi đăng nhập ở example.com thì id đó sẽ được gán với thông tin của người dùng
- Giả sử đây là một đoạn code triển khai cookie token và có thể bị dính Session Fixation
- Để giải quyết vấn đề trên code trên. Rất đơn giản, ta cần đảm bảo khi người dùng đăng nhập, các session cũ phải bị huỷ đi và đảm bảo thông tin người dùng chỉ có thể gắn với 1 id được tạo mới, và hacker không đoán được.
Luồng như ví dụ thực tế:
- Khi người dùng cầm id của hacker đến phòng gửi đồ để tạo id mới
- phòng gửi đồ kiểm tra và thấy id này đã được tạo ra từ trước.
- Phòng gửi đồ huỷ id cũ đi nếu đã tồn tại
- Tạo id mới
Các cách solution khác được suggest:
- Solution: Utilize SSL / TLS session identifier: Các giao thức mã hoá SSL/TLS cũng sinh ra các session identifier để định danh. Ta có thể sử dụng luôn phần này vì nó đã được làm bảo mật mạnh. Tuy nhiên một số trình duyệt sẽ không hỗ trợ cách trên
- Accept only server-generated SIDs: Các SID (session id) chỉ nên được sinh ra bởi server để hạn chế khả năng hacker tạo sid
- Logout function: Ta có thể có các chức năng đăng xuất, rời trình duyệt, … khi đó sẽ huỷ luôn id để đảm bảo không có request nào khác được gửi vào
- Verify that additional information is consistent throughout session: Thông thường thì khi người dùng sử dụng, họ chỉ sử dụng 1 địa chỉ ip, hoặc 1 địa chỉ mac, … tuỳ vào usecase. Ta có thể kiểm tra giữa các request có thông tin nào bị thay đổi không để tăng thêm khả năng bảo mật
- Do not accept session identifiers from GET / POST variables: Không nên để SID vào trong các biến ở request, điều này khiến hacker dễ dàng tạo các url chứa sid độc để tấn công hơn.
Tham khảo:
- API Security in Action
- https://en.wikipedia.org/wiki/Session_fixation?useskin=vector