2011-12-19 48 views
9

Vấn đề tôi đang gặp phải, có thể không giải quyết được, như sau:Bảo mật cookie và phiên

Tôi có một khách hàng lớn với hơn 1.500 người dùng tại 7-8 địa điểm khác nhau. Ứng dụng này là một ứng dụng PHP được xây dựng trên khung công tác Kohana v3.0. Tổ chức này ngồi đằng sau một máy chủ lọc proxy ở cấp ISP. Mỗi địa điểm có một địa chỉ IP công khai chính mà các kênh thông qua proxy sau đó đến web. Mỗi người dùng có một máy trạm Mac hoặc Windows do người sử dụng lao động cấp.

Những gì họ đang gặp có vẻ là xung đột cookie. Ví dụ: Một người dùng đăng nhập vào máy trạm của họ sau đó người dùng khác đăng nhập từ cùng một vị trí, máy trạm khác nhau, với cùng một hệ điều hành và loại trình duyệt. Người dùng thứ hai nhận được phiên hoạt động của người dùng đầu tiên bằng cách nhận được một cookie (mã thông báo) mới được tạo ra khớp với người dùng đầu tiên. Điều này dường như chỉ liên quan đến cookie 'authautologin' (được đặt khi hộp kiểm nhớ tôi tham gia trên màn hình đăng nhập), nhưng tôi vẫn giữ các tùy chọn của mình mở để lưu vào bộ nhớ đệm từ proxy (Tôi không thể chứng minh rằng proxy đang được lưu vào bộ đệm).

Do thiết lập mạng, máy chủ thấy hàng trăm người dùng đăng nhập từ cùng một địa chỉ IP với cùng một tác nhân người dùng. Ý tưởng ban đầu của tôi là cách tạo cookie của Kohana v3 là duy nhất cho trình duyệt (tác nhân người dùng) không phải là duy nhất đủ cho ứng dụng thực tế này.

Có ai từng trải nghiệm bất cứ điều gì như thế này không? Và những hành động thích hợp để thực hiện việc tạo cookie và phiên là gì? Việc quản lý cookie và các phiên hoạt động trong cơ sở dữ liệu có tốt hơn không?

  • Kohana Modules: Jelly-Auth, Jelly, và Auth

  • Server: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1 + lenny8 với Suhosin-patch mod_ssl/2.2.9 OpenSSL/0.9.8g

  • trình duyệt biết: IE 8 & 9, Firefox (OS và Win) và Safari (OS)

+0

+1: Câu hỏi được đặt cẩn thận - với các chi tiết tốt có sẵn. Làm tốt. –

+0

Tôi đồng ý, nhưng đây có phải là vấn đề với proxy áp dụng cho bất kỳ dịch vụ nào sử dụng cookie đăng nhập tự động không? –

+0

@Pekka đã là suy nghĩ/thất vọng của tôi trong tuần qua. Sau đó, sau khi hỏi nhân viên CNTT của họ, tôi đã học được rằng mục đích của bộ lọc proxy là chặn các trang web như Gmail, Facebook, Twitter, v.v ... Vì vậy, tôi tin rằng họ không có quyền truy cập vào các trang web bên ngoài mạng nơi họ đăng nhập. Ứng dụng này rất có thể là ứng dụng duy nhất có thể được cấp một cookie đăng nhập tự động nằm ngoài mạng. – ixasilent

Trả lời

2

Nó chỉ là một ý tưởng nhưng có/được sử dụng để được (tùy thuộc vào Debian và phiên bản PHP của bạn) một lỗi với phiên PHP.Những gì tôi đề nghị bạn thử:

  1. Kiểm tra this link - điều này có thể không được liên quan đến vấn đề của bạn, nhưng nó có giá trị một thử
  2. Đổi thành tài xế cơ sở dữ liệu - Tôi muốn cung cấp cho 90% cơ hội rằng điều này sẽ sửa chữa tất cả mọi thứ
  3. thử nghiệm trên máy chủ Debian khác nhau sau đó - điều này có thể không dễ dàng để thực hiện mặc dù
+0

Tôi không nghĩ rằng liên kết có thể áp dụng, nhưng được ghi chú hợp lý để tham khảo trong tương lai. Ứng dụng này sử dụng MySQL PDO thông qua cơ sở dữ liệu Kohana 3.0 và Jelly. Bất kỳ trình điều khiển khác trong tâm trí? Có khoảng 15 trang web khác giống hệt nhau (- nội dung cơ sở dữ liệu) trên máy chủ này cho các khách hàng khác không báo cáo vấn đề này, vì vậy tôi khá chắc chắn rằng nó phải làm với trang điểm mạng và cần phải làm tốt điều chỉnh tạo cookie cho trang web này. Liên kết tốt! Tôi sẽ đánh dấu nó, vì nó có thể giải quyết một vấn đề thời gian chờ phiên với một wiki đã được lưu trữ trở lại của tôi trong một tháng. – ixasilent

+0

Tôi có nghĩa là chuyển sang trình điều khiển cơ sở dữ liệu phiên, không từ bỏ PDO/Jelly nếu đó là những gì bạn nghĩ;) – matino

+0

bạn đang lưu trữ đúng phiên trong cơ sở dữ liệu sửa lỗi này. Thành thật mà nói tôi không hài lòng với giải pháp này, nhưng sẽ tận hưởng nó như là một hack cho bây giờ. Tất nhiên khi hàng ngàn người dùng bắt đầu sử dụng lại ứng dụng và cuối cùng tôi sẽ trở thành một kẻ ngốc ... Tôi sẽ quay lại! Để an toàn, tôi sẽ viết lại phương thức set của lớp kohana_cookie thành RFC 2109 tương thích. Đó là ít nhất là trách nhiệm phải làm. Cảm ơn! – ixasilent

2

Wow thats một lỗ hổng khó chịu, nắm bắt tốt!

Cho đến nay cách tốt nhất để tạo cookie theo PHP là để PHP làm điều đó: session_start(). Và đó là tất cả! Nếu bạn đang tạo ra cookie của riêng bạn, sau đó bạn thực sự sai lầm ở đâu đó. Bây giờ bạn có thể sử dụng $_SESSION[] siêu toàn cầu. Cách tốt nhất là gọi session_start() trong một tệp tiêu đề chung trước khi bạn truy cập $ _SESSION trong ứng dụng của mình.

Có thể có các vấn đề khác bạn nên xem xét như owasp a9, csrf và cờ cookie: HTTP_Only và cờ "bảo mật" (buộc cookie quá https).

+0

@Rock cảm ơn! Tôi đã đào thông qua các mã một vài lần và có thể xác minh rằng có tôi đang sử dụng PHP để quản lý phiên (session_start(), session_name(), session_set_cookie_params(), session_destroy(), vv ...). Nhưng chỉ vì bạn đề cập đến nó, tôi sẽ đi đào một lần nữa, kiểm tra lại, và cho tín dụng nơi tín dụng được làm khi tôi đi lên cho không khí. Đây là một trang SSL và các cờ an toàn và HTTP_ONLY được thiết lập. – ixasilent

+0

Xin lỗi @Rook không có nghĩa là bạn sẽ phải đăng ký tên của mình ở đó. – ixasilent

+0

@ixasilent Bạn không bao giờ cần đặt giá trị cookie. Tôi nghĩ bạn đang dựa vào lớp kohana_cookie để xác định người dùng. Điều này là sử dụng setcookie(), đó là điều ác. – rook

0

tôi không chắc chắn nếu tôi hiểu bạn một cách chính xác, nhưng ... tôi hiểu yêu cầu mà đi như thế này:

người dùng (máy trạm) ==> proxy() ==> internet ==> trang web của công ty (và phản hồi theo hướng ngược lại).

Kiểm tra xem proxy có đặt "HTTP_X_FORWARDED_FOR" (trong biến superglobal $ _SERVER) không. Nó có thể là cách duy nhất để xác định địa chỉ IP máy trạm của người dùng. Nếu vậy, bạn đã hoàn tất.

+0

Đóng, nhưng vì proxy cũng đóng vai trò là ISP nên không có HTTP_X_FORWARDED_FOR. – ixasilent

Các vấn đề liên quan