세션 하이재킹 방지

세션 하이재킹 방지

---

여러 클라이언트가 동일한 세션 ID를 사용하는 것을 어떻게 방지합니까? 내 웹 사이트에서 세션 하이재킹을 방지하기 위해 추가 보안 계층을 추가하고 싶기 때문에 이것을 요청합니다. 해커가 다른 사용자의 세션 ID를 알아 내고 해당 SID로 요청하는 경우 서버에서 단일 SID를 공유하는 다른 클라이언트가 있음을 어떻게 감지 한 다음 하이재킹 시도를 거부 할 수 있습니까?

편집하다

나는 Stateless HTTP 프로토콜 의 제한으로 인해 내가 요구하는 것이 불가능하다는 것을 깨달았 기 때문에 신중한 고려 끝에 Gumbo의 답변을 수락했습니다 . HTTP의 가장 기본적인 원칙이 무엇인지 잊어 버렸고 이제이 질문에 대해 생각하는 것은 약간 사소한 것 같습니다.

내가 의미하는 바를 자세히 설명하겠습니다.

사용자 A가 example.com에 로그인하면 임의의 세션 ID가 주어집니다. 단순성을 위해 'abc123'으로 두십시오. 이 세션 ID는 클라이언트 측에 쿠키로 저장되며 로그인 한 사용자가 한 웹 페이지에서 다른 웹 페이지로 이동할 때 로그인 상태를 유지하도록 보장하기 위해 서버 측 세션에서 확인됩니다. 물론이 쿠키는 HTTP가 상태 비 저장이 아닌 경우 존재할 필요가 없습니다. 따라서 사용자 B가 사용자 A의 SID를 훔쳐서 자신의 컴퓨터에 'abc123'값으로 쿠키를 생성하면 사용자 A의 세션을 성공적으로 탈취했을 것입니다. 그러나 서버가 사용자 B의 SID를 합법적으로 인식 할 수있는 방법은 없습니다. 요청은 사용자 A의 요청과 다르므로 서버는 요청을 거부 할 이유가 없습니다. 서버에서 이미 활성화 된 세션을 나열하고 누군가 이미 활성화 된 세션에 액세스하고 있는지 확인하려고하더라도 동일한 사용자가 아닌 불법적으로 세션에 액세스하는 다른 사용자인지 어떻게 확인할 수 있습니까? 세션 ID로 이미 로그인되어 있지만 다른 웹 페이지로 이동하기 만하면 다른 요청을 시도하는 것입니다. 우리는 할 수 없습니다. 사용자 에이전트를 확인하고 있습니까? 스푸핑 될 수 있지만 심층 방어 수단으로는 적합합니다. IP 주소? 합법적 인 이유로 변경 될 수 있습니다. 그러나 IP 주소를 전혀 확인하지 않는 대신 완벽하게 합법적 인 이유로 IP를 지속적으로 변경하는 데이터 플랜 네트워크의 사용자도 IP의 처음 두 옥텟과 같은 것을 확인하는 것이 좋습니다. 일반적으로 IP 변경의 마지막 두 옥텟 만 있습니다.

결론적으로, 세션 하이재킹으로부터 웹 사이트를 완전히 보호 할 수 없다고 비난하는 것은 상태 비 저장 HTTP이지만, Gumbo가 제공 한 것과 같은 모범 사례는 대부분의 세션 공격을 방지하기에 충분할 것입니다. 따라서 동일한 SID의 여러 요청을 거부하여 세션을 하이재킹으로부터 보호하려는 것은 우스꽝스럽고 세션의 전체 목적을 무너 뜨립니다.

---

안타깝게도 실제 요청과는 반대로 공격자가 보낸 요청을 확실하게 식별 할 수있는 효과적인 방법은 없습니다. 카운터 측정이 확인하는 대부분의 속성은 IP 주소 또는 사용자 에이전트 특성과 같이 신뢰할 수 없거나 (IP 주소가 여러 요청 사이에서 변경 될 수 있음) 쉽게 위조 될 수 있으므로 (예 : 사용자 에이전트 요청 헤더) 원치 않는 오탐 (예 : 실제 사용자 전환 IP 주소) 또는 거짓 부정 (즉, 공격자가 동일한 User-Agent로 요청을 성공적으로 위조 할 수 있음 ).

이것이 세션 하이재킹을 방지하는 가장 좋은 방법은 공격자가 다른 사용자의 세션 ID를 찾을 수 없도록하는 것입니다. 즉, (1) 공격자가 충분한 엔트로피를 사용하여 유효한 세션 ID를 추측 할 수없고 (2) 알려진 공격을 통해 공격자가 유효한 세션 ID를 얻을 수있는 다른 방법이 없도록 응용 프로그램 및 세션 관리를 설계해야합니다. / 네트워크 통신 스니핑 등 vulerabilities, 사이트 간 스크립팅 통해 누설 참조 자 등

즉, 다음을 수행해야합니다.

• 세션 ID를 생성하기 위해 충분한 임의 입력을 사용합니다 ( session.entropy_file , session.entropy_length 및 session.hash_function 참조 ).
• HTTPS를 사용하여 전송 중 세션 ID 보호
• Referer를 통한 유출을 방지하기 위해 URL이 아닌 쿠키에 세션 ID를 저장합니다 ( session.use_only_cookies 참조 ).
• HttpOnly및 Secure속성으로 쿠키를 설정하여 JavaScript를 통한 액세스를 금지하고 (XSS 취약점의 경우) 안전하지 않은 채널을 통한 전송을 금지합니다 ( session.cookie_httponly 및 session.cookie_secure 참조 ).

그 외에도 특정 세션 상태 변경 (예 : 로그인 후 인증 확인 또는 권한 / 권한 변경) 후에 이전 ID를 무효화하면서 ( session_regenerate_idfunction 참조 ) 세션 ID를 재생성해야하며 추가로 주기적으로이를 수행하여 시간 범위를 줄일 수 있습니다. 성공적인 세션 하이재킹 공격을 위해.

---

이런 식으로 할 수 있습니까?

데이터베이스에 세션 ID를 저장합니다. 또한 해당 세션 ID에 대한 IP 주소 및 HTTP_USER_AGENT를 저장하십시오. 이제 일치하는 세션 ID를 포함하는 서버에 요청이 올 때 스크립트에서 어떤 에이전트와 IP에서 오는지 확인하십시오.

모든 요청이 처리되기 전에 확인되도록 세션에 대한 공통 기능 또는 클래스를 만들어이 Funda를 작동시킬 수 있습니다. 몇 마이크로 초도 걸리지 않습니다. 그러나 많은 사용자가 사이트를 방문하고 있고 방대한 세션 데이터베이스가있는 경우 성능 문제가 거의 없을 수 있습니다. 그러나 => 재생성 세션 사용과 같은 다른 방법에 비해 확실히 매우 안전합니다.

세션 ID를 다시 생성 할 때 세션 하이재킹 가능성이 거의 없습니다.

사용자의 세션 ID가 복사되고 해당 사용자가 한동안 작동하지 않거나 활성 상태가 아니고 이전 세션 ID를 가진 서버에 새 세션을 다시 생성하도록 요청하지 않는다고 가정합니다. 세션 ID가 하이재킹되면 해커는 해당 세션 ID를 사용하여 해당 ID로 서버에 요청한 다음 서버가 다시 생성 된 세션 ID로 응답하여 해커가 서비스를 계속 사용할 수 있도록합니다. 실제 사용자는 재생성 된 ID가 무엇인지, 요청에서 전달 될 요청 세션 ID가 무엇인지 알 수 없기 때문에 더 이상 작업을 수행 할 수 없습니다. 완전히 사라졌습니다.

내가 어딘가에 잘못되면 나를 수정하십시오.

---

세션 하이재킹에 대한 많은 표준 방어가 있습니다. 그중 하나는 각 세션을 단일 IP 주소에 일치시키는 것입니다.

다른 체계 는 다음에서 생성 된 HMAC를 사용할 수 있습니다.

• 클라이언트 IP의 네트워크 주소
• 클라이언트가 보낸 사용자 에이전트 헤더
• SID
• 서버에 저장된 비밀 키

IP의 네트워크 주소 만 사용되는 이유는 사용자가 공용 프록시 뒤에있는 경우입니다.이 경우 IP 주소는 각 요청에 따라 변경 될 수 있지만 네트워크 주소는 동일하게 유지됩니다.

물론, 진정으로 보안을 유지하려면 모든 요청에 ​​대해 SSL을 강제 적용하여 SID가 공격자가 될 가능성이있는 공격자가 먼저 가로 챌 수 없도록해야합니다. 그러나 모든 사이트가이 작업을 수행하는 것은 아닙니다 ( :: cough :: Stack Overflow :: cough ::) .

---

내 견해로는 사용자가 로그인 할 때 데이터베이스에 세션 ID를 저장하고 로그인하기 전에 모든 사람이 동일한 지 확인할 수 있습니다. 사용자가 로그 아웃 할 때 데이터베이스에 저장 한 동일한 세션 ID를 삭제합니다. 모든 사용자의 세션 ID를 쉽게 찾을 수 있으며, 제가 도와 드릴 수 있습니다.

---

쉬운 구현 중 하나는 로그 된 사용자로 데이터베이스에 테이블을 만든 다음 로그인 할 때 해당 테이블을 사용자 이름과 그의 SID로 업데이트하여 수행 할 수 있습니다. 이렇게하면 로그 아웃시 동일한 사용자로 다른 로그인이 방지됩니다. 데이터베이스에 로그인 된 데이터를 삭제하는 간단한 쿼리를 실행하기 만하면 웹 사이트에 로그인 한 사용자를 한 번에 추적하는 데 사용할 수도 있습니다.

---

분명히 브라우저에서 세션 쿠키를 설정하면 해당 쿠키가 요청으로 전송됩니다. 이제 요청이 오면 서버는 데이터베이스에서 세션 ID를 확인하고 액세스 권한을 부여합니다. 이를 방지하려면 에이전트와 IP를 저장하는 것이 중요하므로 서버를 확인하기 전에 세션 액세스가 하이재킹 될 수있는 고유 한 세션 ID가 아닌 고유 한 클라이언트에 부여되는지 확인하십시오.

---

세션 하이재킹은 심각한 위협이며 트랜잭션을 포함하는 고급 애플리케이션을위한 보안 소켓 계층을 사용하거나 위에서 설명한대로 쿠키, 세션 시간 초과 및 ID 재생성 등과 같은 간단한 기술을 사용하여 처리해야합니다.
인터넷이 탄생했을 때 HTTP 통신은 상태 비 저장으로 설계되었습니다. 즉, 두 엔티티 간의 연결은 요청이 서버로 전송되고 결과 응답이 클라이언트로 다시 전달되는 데 필요한 짧은 시간 동안 만 존재합니다. 다음은 해커가 세션을 탈취하기 위해 따르는 몇 가지 방법입니다.

• 네트워크 도청
• 무의식적 노출
• 전달, 프록시 및 피싱
• 리버스 프록시

Always recommend SSL Secure Sockets Layer
Use cookies also to following ini_set() directives at the start of your scripts, in order to override any global settings in php.ini:

ini_set( 'session.use_only_cookies', TRUE );                
ini_set( 'session.use_trans_sid', FALSE );

Use Session Timeouts and Session Regenerate ID

<?php
// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )         
{       
 // if authenticated, generate a new random session ID
  session_regenerate_id();

 // set session to authenticated
  $_SESSION['auth'] = TRUE;

 // redirect to make the new session ID live

 header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
}                   
// take some action
?>

---

I don't know about the coding part well. So I can tell u an algorithm to do this. Setting stuffs like SSL, or setting the session cookie to secure and httpOnly wont work if a user sniffs the session id from a LAN network(Provided user and attacker are in the same LAN).

So what you can do is, once the user successfully logs into the application, set unique token to each and every pages of the web application and keep a track of this at the server side. So that if the valid user sends the request to access a particular page, the token of that page will also be sent to the server side. Since the tokens are unique for a user for a particular session, even if the attacker can get the session id, he cannot hijack the users session as he cannot provide the valid token to the server.

---

@Anandu M Das:

I believe what you may be referring to is the use of session tokens with each session ID. This site can explain the use of tokens with sessions:

https://blog.whitehatsec.com/tag/session-token/

Although session tokens are easily compromised by an XSS attack, this doesn't mean that they should never be used. I mean let's face it, if something was compromisable by a security vulnerability on the server, its not the fault of the method, its the fault of the programmer who introduced that vulnerability (to highlight points made by Hesson and Rook).

If you follow proper security conventions and practicies and secure your site from SQL injection, XSS, and require all sessions be managed over HTTPS, then you can easily manage the potential attack from CSRF by use of server-side tokens, stored within the session, and updated everytime the user would cause a manipulation to their session (like a $_POST being submitted). Also, NEVER store sessions or their contents in a url, no matter how well you think they are encoded.

When the security of your users is paramount (which it should be), the use of session tokens will allow better or more advanced functionality to be provided without compromising their session security.

참고URL : https://stackoverflow.com/questions/12233406/preventing-session-hijacking