iOS thỉnh thoảng gửi các cookie cũ

Question

Tôi có một ứng dụng thường xuyên xoay các giá trị cookie mã thông báo auth.

Mỗi khi máy chủ quay mã thông báo, nó sẽ không đánh dấu nó là "tốt" cho đến khi nó thấy khách hàng có mã thông báo (vì khách hàng bao gồm nó trong tiêu đề yêu cầu cho tài nguyên).

Tôi có một tình huống rất cụ thể CHỈ trên iOS (10.3), trong đó thỉnh thoảng nó sẽ gửi một cookie rất cũ khi điều kiện mạng thay đổi (ví dụ: xuống tàu điện ngầm). Khi điều kiện này chạm vào nó "hãy quên" về giá trị cookie gần đây nhất và "bắt đầu sống trong quá khứ" và gửi và giá trị cũ.

^{** An ninh lưu ý: địa chỉ IP được công khai phân bổ t-mobile ở New York và mã thông báo từ lâu đã được xóa từ DB của chúng tôi}

• Đây có phải là một vấn đề được biết đến?
• Có cách nào để xử lý cookie mạnh mẽ hơn trên iOS không? localstorage không lý tưởng vì các cookie này chỉ là http.

Để làm rõ ... đây là dòng chảy:

1. Khách hàng (iOS Safari) đã cookie có tên _t với giá trị old
2. Khách hàng (iOS Safari) tạo ra một yêu cầu đến máy chủ
3. Chúng tôi phát hành Set-Cookie và đặt _t cookie thành giá trị mới new (chỉ http, cookie an toàn)
4. Khách hàng thực hiện yêu cầu khác với cookie mới v alue new. Chúng tôi gắn cờ rằng giá trị cookie là tốt và khách hàng có nó.
5. Thời gian trôi qua
6. khách hàng tạo ra một yêu cầu với cookie _t với giá trị old

Answer 1

Đây là lý thuyết của tôi về những gì đã xảy ra:

Từ vòng đời cookies, bất cứ khi nào thay đổi trạng thái người dùng xác thực (người dùng đăng nhập -> người dùng đăng xuất || người dùng đăng xuất -> người dùng đăng nhập), cookie cũ sẽ bị vô hiệu và được thay thế bằng một cookie mới.

Nhưng tại sao điều đó lại xảy ra trong tàu điện ngầm chứ không phải ở những nơi khác?
1. Những ngày này hầu hết các tàu điện ngầm cung cấp Wi-Fi không có bảo đảm miễn phí để bổ sung kết nối mạng không dây kém trong khi ngầm.
2. Có một số báo cáo về vấn đề kết nối mạng ở 10.3 và this one nói riêng là thú vị, vì vấn đề là location dependent.
3. Tôi nghĩ rằng sự kết hợp của (1) và (2) ở trên đã khiến ứng dụng xác thực lại máy chủ. Có lẽ bạn có thể kéo các bản ghi để kiểm tra xem đó thực sự là trường hợp?

Giải pháp có thể xảy ra?

Có thể không có.
Chúng tôi không thể ngăn người dùng iPhone nâng cấp iOS. Và hầu hết đã làm.
Ngoài ra, hậu quả an ninh của việc không thay đổi cookie sau khi việc xác thực lại tồi tệ hơn.

Cập nhật dựa trên những nhận xét như của 2017/05/31:

Với các chi tiết như trong nhận xét. Chúng ta có thể giải thích tốt hơn.

Trong chu kỳ cuộc sống cookie, khi người dùng đăng xuất, server-side-invalidation sẽ diễn ra.

Quy trình làm việc:
1. Khi người dùng logout, authenticated sessionID bị xóa khỏi trình duyệt.
2. Nhưng điều đó là không đủ. Máy chủ cần phải invalidate rằng sessionID quá. Khác có thể có hậu quả an ninh.
3. Có thể trong trường hợp máy chủ không bị vô hiệu. Vì vậy, nó vẫn mong đợi một SessionID đã được deleted from the browser.

Đây chỉ là một giải thích có thể có. Để được chính xác, chi tiết hơn phân tích tệp nhật ký và nhiều thử nghiệm hơn sẽ được yêu cầu.

Ví dụ: trong khoảng thời gian đó, tại nhật ký máy chủ đã xảy ra bất kỳ xác thực lại nào không?
Chúng tôi có thể thử nghiệm trong môi trường được kiểm soát, nếu server-side-invalidation đã được triển khai đúng cách không?

Answer 2

Cơ sở dữ liệu SQLite, nếu bạn sẵn sàng hy sinh một chút bảo mật.

Answer 3

Tôi đã bị cô lập này là một lỗi trong cách Safari và Safari View Controller tương tác.

Sao chép thấy repo này:

https://github.com/SamSaffron/test-cookie-rotate

Trong Safari điều hướng đến URL của ứng dụng bạn
Trong Safari View Controller điều hướng đến cùng một URL

Ứng dụng quay cookie mỗi 3 giây và cảnh báo nếu có bất kỳ điều gì bị lạc lối, ví dụ như bị loại ra khỏi cookie chuỗi.

Rời khỏi Safari và mọi thứ hoạt động ... nhất quán. Để nó trên Safari View Controller và mọi thứ hoạt động ... nhất quán.

Bắt đầu chuyển từ Safari trở lại Xem bộ điều khiển v.v. và rất nhanh chóng, bạn sẽ thấy thông báo lỗi đồng bộ hóa. Trong thực tế nó có thể nhận được như vậy xấu mà bạn "mất" một giá trị xác nhận bạn nhận được từ máy chủ.

Báo cáo về khoảng trống là trình theo dõi lỗi của Apple.

Answer 4

Kinh nghiệm của tôi

tôi cũng sử dụng xác thực thông qua ID mà thay đổi với mỗi yêu cầu và được lưu trữ trong cookie. Tôi có thể xác nhận hành vi này và nó vẫn có trong iOS 11 (và iOS 11.1 beta 3). Trong các tệp nhật ký của tôi, tôi có thể thấy rằng đôi khi các cookie cũ được lưu trữ ngẫu nhiên trong Safari. Điều này xảy ra trong một ứng dụng web độc lập khi nó được đóng và mở lại.

Phương pháp của tôi dự phòng

tôi đã xây dựng một phương pháp dự phòng trên localStorage. Yêu cầu với cookie cũ thường sẽ đánh dấu tất cả dữ liệu trong cơ sở dữ liệu của tôi là không hợp lệ. Nếu tác nhân người dùng trỏ đến thiết bị có iOS, tôi không đánh dấu dữ liệu là không hợp lệ và cung cấp cho khách hàng một nỗ lực thứ hai để xác thực chính nó.

Ở phía máy khách, tôi kiểm tra localStorage và tạo cookie mới với dữ liệu này. Sau đó, một xác thực mới diễn ra. LocalStorage được viết lại như các cookie với mỗi yêu cầu. Nếu xác thực không thành công một lần nữa, tôi đánh dấu dữ liệu là không hợp lệ.