2011-08-03 1 views
3

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

추론 : 사용자가 로그 아웃 한 후 떠나기 전에 사이트에서 한 페이지 만 더 방문하면 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; 
} 

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

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

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

답변

6

(성명이 불분명 한) 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

+0

좋아, 감사, 내가 그 들여다 것이다 - 당신은 내가 이런 일이 발생 방지에 대한 갈 것이라고 어떻게 알 수 있습니까? 어쩌면 모든 페이지 뷰에서 또는 최소한 로그인 한 직후에 SID를 변경합니까? – Muuse

+0

1, 3, 4, 5를 이해합니다. 이제 읽은 후에는 분명해 보입니다. 그러나 나는 서버 측에서 모든 데이터가 삭제되는 한 쿠키의 설정을 해제하는 것이 얼마나 많은 차이를 만들지는 모르겠다. 쿠키를 설정 해제하지 않으면 session_destroy()로 인해 모든 데이터가 서버 측에서 여전히 파괴됩니다. 사용자는 브라우저에서 SID를 쿠키로 남겨 두지 만 서버는 로그인으로 인식하지 못합니다. 그로 인한 피해는 무엇입니까? 내가 제공 한 링크를 살펴 보겠습니다. 고마워요 !! – Muuse

+0

@laph : # 2는 중고 휴대 전화를 사는 것으로 생각하십시오. SIM을 넣더라도 휴대 전화의 IMEI는 일정하게 유지되며 휴대 전화 트래픽을 IMEI를 아는 사람 (예 : 휴대 전화를 판매 한 사람)이 캡처 할 수 있습니다. 세션을 도용 할 수 없도록 보장하려면 ID와 함께 세션과 관련된 모든 것을 변경해야합니다. –

관련 문제