Bảo mật Spring/JSF/Hibernate Confidental Session Hijacking trên Tomcat?

Question

Có điều gì đó rất lạ lùng và lúng túng xảy ra với tôi vào một ngày khác và tôi không có từ ngữ để mô tả những gì đã xảy ra.

Ứng dụng của tôi chạy Spring 3 được tích hợp với JSF 2.1, Hibernate 4, Spring Security trên Tomcat 7. Tôi đã qua điện thoại với một người quan trọng từ cấp C và cả hai chúng tôi cùng lúc trên môi trường thử nghiệm cùng một lúc cùng một trang. Anh ấy đã điều hướng đến một trang mà tôi đang điều hướng đến cùng một lúc khi trang của anh ấy xuất hiện với các chi tiết tài khoản cá nhân của tôi. Tôi không tin anh ấy, vì vậy tôi đã đi đến văn phòng của anh ấy và chắc chắn, anh ấy đã đăng nhập bằng tài khoản của tôi mà anh ấy không có mật khẩu.

Đơn đăng ký sẽ có thông tin sức khỏe bệnh nhân được bảo vệ vì vậy tôi đã được yêu cầu cung cấp báo cáo đầy đủ về C với những gì đã xảy ra, nhưng tôi không thể tìm thấy điều này. Tôi lùng sục cơ sở mã và không có gì. Tôi đã cố gắng tái tạo kịch bản chính xác trong nhiều dịp và không bao giờ có thể tái tạo nó. Tôi thậm chí không có một giáo dục đoán rằng tôi hài lòng với. Tôi nghĩ có lẽ có thể có một số hoạt động luồng không an toàn trên các phiên được lưu trữ trong triển khai ngữ cảnh ứng dụng Tomcat nhưng tôi không có cách nào để chứng minh điều này nếu nó không thể tái sản xuất được. Tôi cũng nghĩ rằng vì Spring Security hoạt động như một bộ lọc trước các yêu cầu khác và chuyển tiếp mà có lẽ một trong các bộ lọc servlet khác đã can thiệp. Hai loại còn lại là bộ lọc Tải lên tệp Primefaces và bộ lọc SEO Omnifaces mà tôi đã thêm gần đây.

Bộ lọc Omnifaces thực tế đã can thiệp vào bộ lọc Tải lên tệp Primefaces mà tôi phải tin cấu hình của nó để hai người trong số họ chơi tốt với nhau, vì vậy tôi vẫn cảm thấy đó có thể là một khả năng.

Có bất kỳ lỗi nào đã biết với Spring Security đã gây ra sự cố tương tự không? Có những vấn đề đã biết với Tomcat liên quan đến việc tình cờ phục vụ trạng thái phiên sai từ ApplicationContext không? Có ai khác trải qua một vấn đề tương tự hoặc có một số hiểu biết độc đáo về điều này?

EDIT: Không lâu sau khi công bố này, tôi thấy điều này, đăng tải chỉ một vài ngày trước:

Session mix up - apache httpd with mod_jk, tomcat, spring security - serving data of other user

Nó là gần như giống hệt thiết lập tương tự như tôi có Apache httpd + mod_jk cắm ở phía trước Tomcat vì vậy chắc chắn tôi không điên :)

UPDATE:

tôi đã có thể mô phỏng sự cố trong m y môi trường phát triển mà không có mod_jk hoặc Apache ở phía trước, vì vậy tôi có thể tin tưởng điều này một cách đáng tin cậy là thủ phạm.

Answer 1

Tôi đã tìm ra :)

Đó là một lỗi nhà phát triển, nhưng nó cũng là hành vi mặc định vô lý của Spring. Tôi đã có một JSF Managed Bean được gọi là SessionBean mà tôi đã khai báo là @SessionScope. Khi bạn tích hợp JSF và Spring, việc tiêm phụ thuộc JSF xung đột với việc tiêm phụ thuộc Spring, do đó Spring viết lại mô-đun JSF để xử lý nó để chỉ quấn Spring DI. Vì vậy, khi tôi khai báo JSF ManagedBean là Session Scoped, tôi cũng phải cung cấp cho nó một chú thích @Controller để nó cũng được nhận dạng là Spring Bean.

Chỉ ra rằng Spring không hiểu các chú thích JSF @RequestScoped và @SessionScoped.Spring có chú thích riêng được gọi đơn giản là @Scope(value = "request|session|singleton?|etc...").

Vì Spring không nhận ra phạm vi JSF mà tôi đã đặt, nó xử lý bean mới được tạo mặc định cho các bean, như một SINGLETON.

Vì vậy, mỗi khi ai đó đăng nhập, nó đã ghi đè lên thuộc tính mà tôi đã sử dụng để lưu vào bộ nhớ cache người dùng đã đăng nhập mà tôi đã tìm nạp từ Hiệu trưởng xác thực. Sau đó, tất cả mọi người đã làm bất cứ điều gì đã được đăng nhập như là một người dùng khác nhau.

Nice of Spring bằng cách đến cảnh báo bạn rằng bạn đã định cấu hình sai bean chết tiệt của mình.

Cảm ơn sự giúp đỡ của mọi người, tôi hy vọng điều này sẽ mang lại lợi ích cho khách truy cập trong tương lai!