Câu trả lời:
Đặc tả cookie hiện tại là RFC 6265 , thay thế RFC 2109 và RFC 2965 (cả hai RFC hiện được đánh dấu là "Lịch sử") và chính thức hóa cú pháp cho việc sử dụng cookie trong thế giới thực. Nó nêu rõ:
- Giới thiệu
...
Vì lý do lịch sử, cookie chứa một số lỗi không bảo mật và quyền riêng tư. Ví dụ: một máy chủ có thể chỉ ra rằng một cookie nhất định được dành cho các kết nối "an toàn", nhưng thuộc tính Secure không cung cấp tính toàn vẹn khi có kẻ tấn công mạng đang hoạt động. Tương tự, cookie cho một máy chủ nhất định được chia sẻ trên tất cả các cổng trên máy chủ đó, mặc dù "chính sách cùng nguồn gốc" thông thường được sử dụng bởi các trình duyệt web tách biệt nội dung được truy xuất qua các cổng khác nhau.
Và cũng:
8,5. Bảo mật yếu
Cookies không cung cấp sự cô lập bởi cổng . Nếu một dịch vụ chạy trên một cổng có thể đọc được cookie, thì cookie cũng có thể đọc được bởi một dịch vụ chạy trên một cổng khác của cùng một máy chủ. Nếu một cookie có thể ghi được bởi một dịch vụ trên một cổng, thì cookie cũng có thể ghi được bởi một dịch vụ chạy trên một cổng khác của cùng một máy chủ. Vì lý do này, các máy chủ KHÔNG NÊN chạy cả hai dịch vụ không tin tưởng lẫn nhau trên các cổng khác nhau của cùng một máy chủ và sử dụng cookie để lưu trữ thông tin nhạy cảm về bảo mật.
Theo RFC2965 3.3.1 (có thể được theo dõi bởi các trình duyệt), trừ khi cổng được chỉ định rõ ràng thông qua porttham số của Set-Cookietiêu đề, cookie có thể hoặc không thể được gửi đến bất kỳ cổng nào.
Sổ tay bảo mật trình duyệt của Google cho biết: theo mặc định, phạm vi cookie được giới hạn ở tất cả các URL trên tên máy chủ hiện tại - và không bị ràng buộc với thông tin cổng hoặc giao thức. và một số dòng sau Không có cách nào để giới hạn cookie chỉ với một tên DNS duy nhất [...], không có cách nào để giới hạn chúng ở một cổng cụ thể. (Ngoài ra, hãy nhớ rằng IE không chịu ảnh hưởng số cổng vào chính sách cùng nguồn gốc của nó ở tất cả .)
Vì vậy, dường như không an toàn khi dựa vào bất kỳ hành vi nào được xác định rõ ở đây.
Đây là một câu hỏi thực sự cũ nhưng tôi nghĩ rằng tôi sẽ thêm một cách giải quyết mà tôi đã sử dụng.
Tôi có hai dịch vụ chạy trên máy tính xách tay của mình (một trên cổng 3000 và dịch vụ khác trên 4000). Khi tôi sẽ nhảy giữa ( http://localhost:3000vàhttp://localhost:4000 ), Chrome sẽ chuyển qua cùng một cookie, mỗi dịch vụ sẽ không hiểu cookie và tạo một cái mới.
Tôi thấy rằng nếu tôi truy cập http://localhost:3000vàhttp://127.0.0.1:4000 , sự cố đã biến mất do Chrome giữ cookie cho localhost và một cho 127.0.0.1.
Một lần nữa, không ai có thể quan tâm vào thời điểm này nhưng nó rất dễ dàng và hữu ích cho tình huống của tôi.
localhostkhông thể được chia sẻ với 127.0.0.1và ngược lại. Nhưng cookie trên cùng một máy chủ / tên miền, bất kể cổng, đều có thể chia sẻ được.
Đây là một khu vực màu xám lớn trong SOP cookie (Chính sách xuất xứ tương tự).
Về mặt lý thuyết, bạn có thể chỉ định số cổng trong miền và cookie sẽ không được chia sẻ. Trong thực tế, điều này không hoạt động với một số trình duyệt và bạn sẽ gặp các vấn đề khác. Vì vậy, điều này chỉ khả thi nếu các trang web của bạn không dành cho công chúng nói chung và bạn có thể kiểm soát những trình duyệt nào sẽ sử dụng.
Cách tiếp cận tốt hơn là lấy 2 tên miền cho cùng một IP và không dựa vào số cổng cho cookie.
Một cách khác để giải quyết vấn đề là làm cho tên của cookie phiên có liên quan đến cổng. Ví dụ:
Mã của bạn có thể truy cập cấu hình máy chủ web để tìm ra cổng nào mà máy chủ của bạn sử dụng và đặt tên cho cookie.
Hãy nhớ rằng ứng dụng của bạn sẽ nhận được cả hai cookie và bạn cần yêu cầu cái tương ứng với cổng của bạn.
Không cần phải có số cổng chính xác trong tên cookie, nhưng điều này thuận tiện hơn.
Nói chung, tên cookie có thể mã hóa bất kỳ tham số nào khác cụ thể cho trường hợp máy chủ bạn sử dụng, do đó, tên này có thể được giải mã theo ngữ cảnh phù hợp.
Tôi đã gặp một vấn đề tương tự khi chạy (và cố gắng gỡ lỗi) hai ứng dụng Django khác nhau trên cùng một máy.
Tôi đã chạy chúng với các lệnh sau:
./manage.py runserver 8000
./manage.py runserver 8001
Khi tôi đã đăng nhập vào cái đầu tiên và sau đó trong cái thứ hai, tôi luôn luôn đăng xuất cái đầu tiên và ngược lại.
Tôi đã thêm cái này vào / etc / hosts
127.0.0.1 app1
127.0.0.1 app2
Sau đó, tôi bắt đầu hai ứng dụng với các lệnh sau:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Vấn đề đã được giải quyết :)
127.0.0.1:8000cho một, localhost:8000trong một giây và có thể ::1:8000(có thể [::1]:8080) cho một phần ba mà không cần phải chạm vào tệp máy chủ.
::1 app1 app2 app3 app4 app5 appN
Đó là tùy chọn.
Cổng có thể được chỉ định để cookie có thể là cổng cụ thể. Không cần thiết, máy chủ / ứng dụng web phải quan tâm đến vấn đề này.
Nguồn: Bài viết Wikipedia tiếng Đức , RFC2109 , Chương 4.3.1
Porttham số trongSet-Cookietiêu đề (vì hầu như không ai thực sự sử dụng nó trong thực tế) và làm cho nó rất rõ ràng rằng các cookie trên cùng một máy chủ không còn bị phân tán bởi các cổng nữa.