클라이언트 측 세션

관련 웹 응용 프로그램의 클라이언트가 자체 인증 상태를 유지하기를 원합니다. 클러스터 노드간에 세션 복제가 필요 없기 때문에 확장 성이 향상됩니다. 또한 Java Servlets 및 PHP와 같은 다양한 서버 기술을보다 쉽게 통합 할 수 있습니다. 다음과 같이클라이언트 측 세션

내 계획은 다음과 같습니다

설정 클라이언트 인증 후 사용자 이름과 세션 만료 시간과 함께 서명 및 암호화 된 쿠키.
클라이언트가 요청을 보내면 서버는 쿠키를 해독하고 유효성을 검사하고 쿠키 값에 따라 액세스를 허용하거나 거부합니다.
세션 만료는 쿠키 재설정을 통해 업데이트됩니다.

세션을 사용하려는 모든 서버는 쿠키 메커니즘과 암호 해독 키를 알고 있어야합니다. 참고 : Session state in the client tier

이 방법이 좋습니까? 서블릿 컨테이너/애플리케이션 서버에 애플리케이션을 투명하게 구현할 수 있습니까? 서블릿은 예를 들어 HttpServletRequest # getRemoteUser()를 사용할 수 있어야합니다. 이것이 가능한가? 아니면 Spring Security와 같은 컨테이너 레벨 이상이 필요합니까? 클라이언트 측 세션 관리를위한 기존 라이브러리가 있습니까?

출처

2010-01-25 deamon

좋은 생각은 아닙니다. 세션 만료 및 사용자 이름과 같은 중요 데이터를 클라이언트 측에 저장하는 것은 암호화 된 것인지 또는 암호화되지 않은 IMO인지를 너무 위험합니다. 개념 자체가 기술적으로 안전하다고하더라도 (나는 깊이 대답 할 수없고 암호화 전문가가 아닙니다.) 암호화 키를 획득하기 만하면 서버를 손상시키지 않고 침입을 촉진 할 수 있습니다. 시간의 길이를 어떤 사용자를 가장, 마음대로 세션 쿠키를 생성 할 수있는 키의 보류를 얻을 수

누군가, 고전 세션 개념을 방지하기 위해 설계되었습니다 뭔가.

이 문제에 대한 더 우수하고 확장 가능한 솔루션이 있습니다. 예를 들어 모든 관련 서버 및 서비스에서 폴링 할 수있는 중앙 세션 확인 인스턴스를 설정하는 것이 어떻습니까? 웹을 둘러보고, 나는 귀하의 요구를 해결할 수있는 기성품 솔루션이 100 % 확신합니다.

출처

2010-01-25 10:29:03

이것은 실제로 세션이 구현되는 방식이 아닙니다. 쿠키 자체는 세션 자체의 데이터를 전달할 필요가 없으며 단지 쿠키에 대한 참조 일뿐입니다.

쿠키가 저장하는 내용은 보통 Session ID이며 서버의 데이터에 연결됩니다.

다른 서버가 액세스 할 수있는 중앙 데이터 세션 서버가없는 경우 다음 중 하나를 얻으십시오.

출처

2010-01-25 10:32:04

이것은 솔루션을 확장 가능하게하기 때문에 그가 원하지 않는 것입니다. 나는 이것이 유일한 방법이라고 생각합니다. –

인증 상태 저장소를 갖고 싶습니다. 그리고 저는이 상태를 서버 측에 저장하고 싶지 않습니다. HTTP 기본 인증과 같은 것을 염두에두고 있지만 (OpenID를 지원하는 등) 더 유연 해지고 싶습니다. – deamon

클러스터의 모든 노드에서 잘 알고 있고 모든 사용자의 세션 데이터를 유지 관리하는 서버 인 상태 서버를 사용하면 클러스터 환경에서 데이터 중복을 피할 수 있습니다. 사용자가 요청을 수행 할 때마다 세션 ID가있는 쿠키를 응용 프로그램 서버로 보냅니다. 이것은 상태 서버에서 세션을 검색해야합니다. 이것은 asp.net 개발이 가능하지만, Java가이 접근법을 얼마나 쉽게 지원하는지 확신 할 수 없습니다.

출처

2010-01-25 10:56:17 lmsasu

Java 세계 *에는 이에 대한 해결책이 있어야합니다. 그것은 가장 오래된 고급 웹 플랫폼이며 같은 시점에 수많은 문제가 발생한 수많은 엔터프라이즈 응용 프로그램에서 사용됩니다. –

이렇게하면 클러스터 노드간에 세션 복제가 필요 없으므로 확장 성이 향상됩니다.

첫째, 정말 심지어 HTTP 세션 상태 복제를 사용하는 경우, 확장에 방해가되지 않는 HTTP 세션을 사용 (일부 메커니즘은 예를 들어 웹 로직의 in-memory replication 큰 오버 헤드가없는, 그런데 다른 사람보다 더 똑똑하다) . 둘째, 정말로 필요합니까? 대부분의 응용 프로그램 (대다수)은 세션 복제가 필요하지 않습니다. 셋째, 나는 올바르게 이해하고있다. HTTP 세션을 전혀 사용하지 않을 계획인가?

(...) 클라이언트 인증 후 사용자 이름과 세션 만료 시간을 사용하여 서명되고 암호화 된 쿠키를 설정하십시오.

Do not do this! 서버에서 사용하는 사용자 이름 및 기타 유용한 데이터를 쿠키에 저장하지 마십시오. 이것은 매우 나쁜 생각입니다! 실제로 시스템이 작동하는 방식을 알아 내고 쿠키를 해독하기 전에 (특히 쿠키가 crib 공격의 후보 인 경우) 시간이 걸린다는 사실을 인정해야합니다. Sor, 실제로 서버 측의 세션에 데이터를 저장하고 실제로 작동하는 것처럼 쿠키의 ID 만 저장해야합니다. 이것은 훨씬 더 안전합니다.

이 접근 방법은 괜찮습니까?

번호 그리고 (이것은 당신이 만들려고하는 것입니다 경우)는 상호 운용 single-sign on이 필요하지 않습니다. 다양한 기술을위한 라이브러리가있는 ~~CAS~~ Jasig과 같은 중앙 인증 솔루션을 사용하십시오.

출처

2010-01-25 11:31:07

질문이 있습니다. 쿠키에 sessionID를 저장하고 클라이언트가 서버를 식별 할 수 있도록 매번 서버에 보내면 누군가가이 sessionID를 훔쳐서이 사용자를 막을 수 있습니까? 악의적 인 사람이 쿠키에서 중요한 ID 데이터를 훔칠 수 있다면 sessionID는 실제로 민감합니다. 내가 잘못? 고맙습니다! – Jaskey

Pekka가 말했듯이, 좋은 생각은 아닙니다. 민감한 세션 데이터로 쿠키를 차단할 수 있습니다. SSL을 사용해도 피들러 2를 사용하여 decrypt 트래픽을 보낼 수 있습니다.

출처

2010-01-25 16:06:57 lmsasu

A는 전송 계층 보안을 의미하는 것이 아니라 쿠키 데이터 자체의 암호화입니다 (예 : GnuPG). – deamon

fiddler2 SSL 트래픽 암호 해독 문제가 잘못되었습니다. SSL/TLS 설계의 구멍이 아니라는 점에서, fiddler2는 단순히 프록시로 작동하여 클라이언트와 통신하여 요청을 전달하고 의도 한 서버로 전달할 수 있도록 자동 생성 된 (신뢰할 수없는!) 인증서를 사용하여 신뢰할 수있는 웹 서버 대신 자체를 배치합니다. HTTPS 클라이언트로 위장하는 목적지. 이것은 fiddler2가 SSL 트래픽을 해독 할 수 있다는 것과 매우 다릅니다. 그렇다면 범죄자들이 어제 우리 은행 계좌를 비 웠을 것입니다. – amn

@ amn : true; 당신은 단지 교통을 가로 채고, 그것을 얻었습니다. 이상한 점은 주어진 링크에서 제목이 "HTTPS로 보호 된 트래픽 암호 해독"이라고 말하는 것입니다. 오해의 소지가 있습니다. 그것은 "가로 채기"해야합니다.피들러 페이지에서 말한 것처럼 "HTTPS 보안 트래픽 수정"을 허용하여 실제 암호화 된 쿠키를 변경할 수 있으므로 암호화 된 쿠키를 유지 관리하는 것은 여전히 안전하지 않습니다. – lmsasu

포스터에서이 방법이 안전하지 않다는 의견에 동의하지 않습니다. 그것의 변종은 당신이 윤곽을 그리는 이유 때문에 Rails와 Play!와 같은 여러 존경받는 프레임 워크에서 사용되며 올바르게 구현되면 완벽하게 안전합니다.

출처

2015-07-09 14:10:12

클라이언트 측 세션

답변

관련 문제