PHP 세션에서 로그 아웃하는 동안 쿠키를 설정 해제하는 시점은 무엇입니까?

Question

사용자가 자신의 계정을 가질 수있는 PHP로 웹 응용 프로그램을 개발 중이며 사용자를 추적하는 세션이 MySQL 데이터베이스에 저장됩니다. 자, 이것을 구현하는 방법에 대한 답을 찾은 후에 많은 사람들이 session_destroy()을 사용하고 쿠키를 설정 해제하는 것을 좋아한다는 것을 알았습니다. 왜 - session_destroy()만으로 충분하지 않습니까? the PHP manual도 "세션을 모두 종료하려면 사용자를 로그 아웃하는 것처럼 세션 ID도 설정 해제해야합니다."라고 말합니다.

추론 : 사용자가 로그 아웃 한 후 떠나기 전에 사이트에서 한 페이지 만 더 방문하면 PHP 스크립트는 사용자가 로그인했는지 여부를 확인하여 session_start()를 호출하고 새 세션을 설정합니다 어쨌든 사용자를위한 쿠키. 여기처럼 보일 수 있습니다 방법은 다음과 같습니다

// here we include some scripts and make some instances we'll need 
require_once("database.php"); 
require_once("session.php"); 
$database_connection = new DB_Connection(); 
$session = new Session($database_connection); 

// here a session cookie is sent to a user, even if he or she isn't logged in 
session_start(); 

// finally we check if the user is logged in 
$log_isLogged = false; 
if(isset($_SESSION['member_id'], $_SESSION['username'])){ 
    $log_member_id = $_SESSION['member_id']; 
    $log_username = $_SESSION['username']; 
    $log_isLogged = true; 
} 

물론, 그것은 사용자가이 사실을 알고, 새로운 쿠키가 설정 될 수 있습니다 전에 사이트를 떠날 때에 좋다. 그러나 일부 사이트는 로그 아웃 후 바로 새 페이지로 리디렉션되어 새로운 세션 쿠키를 생성하여 방금 수행 한 작업을 취소합니다.

내 논리가 결함이 있습니까? 아니면 세션 쿠키를 설정 해제했는지 여부는 중요하지 않습니까? 아마 대부분의 개발자는 적어도 그것을 설정 해제 할 수는 없다는 라인을 따라 생각하고 있을까요?

나는 원어민이 아니기 때문에, 오타 나 문법 오류에 대해 미리 사과드립니다.

Answer 1

(성명이 불분명 한) session_destroy() 기능은 세션에서 데이터 만 삭제합니다. 이 아닌 경우 브라우저에서 세션 쿠키를 제거하고 세션과 연결된 session_id를 유지합니다. session_start()은 클라이언트의 요청에 아직 제공되지 않은 경우에만 새 session_id를 클라이언트에 보냅니다. 코드는 session fixation이라는 공격에 취약합니다. 악의적 인 공격자가 사이트에서 세션을 시작하여 유효한 session_id를 얻은 다음 의심하지 않는 사용자를 속여 공격자가 알고있는 session_id로 로그인하도록합니다. 이것은 victim에게 URL의 session_id와 링크를 보내거나 (사이트가 그렇게 받아 들일 경우) 또는 다른 여러 가지 방법으로 수행 할 수 있습니다. 피해자가 로그인하면 공격자는 동일한 사용자로 효과적으로 로그인됩니다. session_regenerate_id()를 호출하여

1. 로그인에 성공, 문제 클라이언트에 새로운 SESSION_ID에 : 당신이해야 세션 고정 공격을 방지하기 위해

   .

2. 로그 아웃 할 때 서버와 클라이언트 모두에서 세션의 모든 아티팩트를 완전히 파괴하십시오. 즉, session_destroy()및은 클라이언트 쿠키를 setcookie()으로 설정 해제합니다.

3. 사이트에서 URL에 session_id가 노출되지 않았는지 확인하거나 URL에 제공된 session_id를 허용하십시오.

4. session_ids가 길고 랜덤한지 확인하여 공격자가 실제로 추측 할 수 없도록하십시오.

5. 사이트가 cross site scripting 공격에 취약하지 않은지 확인하십시오. 공격자가 이미 로그인 한 사용자의 유효한 session_id를 도용 할 수 있습니다.

6. https를 통해 로그인이 이루어지고 세션 쿠키가 안전하다고 표시되어 있는지 확인하십시오. 세션과 관련된 모든 통신은 https를 통해 이루어져야합니다. 전송 중에 클라이언트의 session_id가 노출되므로 http를 통해 클라이언트의 session_id를 전송해서는 안됩니다.

또한 참조 : OWASP Top Ten page on session management