태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

HTTP Session Hijacking

보안, 암호화 2009. 3. 27. 11:21 posted by 무병장수권력자


원문 링크
http://unix.co.kr/bbs/board.php?bo_table=02_06&wr_id=46

주옥같은 강좌이어서 공유 차원에서 퍼담아 봅니다.

HTTP Session Hijacking

앞서 해킹기법에서 스니핑(sniffing)에 대해서 살펴보았다. telnet, ftp, pop3 등의 비암호화 프로토콜 어플리케이션은 스니핑 공격을 통하여 사용자 계정 및 암호 도용에 취약할 수 있음을 알게 되었다. 마찬가지로 우리가 웹 브라우징시 사용하는 HTTP 프로토콜도 이러한 도용에 취약할 수 있다.

HTTP Session Hijacking(혹은 Session ID Hijacking)이라는 공격 기법은 웹 브라우징시 세션 관리를 위해 사용되는 Session ID를 스니핑이나 무작위 추측 공격(brute-force guessing)을 통해서 도용하는 기법이다. 먼저 이러한 공격에 대한 기초적인 배경지식으로 HTTP 프로토콜의 특성 및 Session ID에 대해 이해해보도록 하겠다.

HTTP 프로토콜의 특성

HTTP는 기본적으로 비연결유지(stateless) 프로토콜이다. 반면, telnet과 ftp와 같은 프로토콜은 클라이언트와 서버 사이에 하나의 연결(session)이 성립되어 통신하는 프로토콜이다. 따라서, 우리가 보통 웹 브라우저를 열어 URL을 입력하고 해당 홈페이지에 들어간다는 것은 해당 홈페이지에 포함되어 있는 페이지(html), 그림(jpg, gif 등), 자바스크립트(js) 등을 다운받기 위해 개별적인 여러 개의 80 요청(request)을 발송한 후 서버로부터 각각의 응답(reply)을 받는 것을 의미한다.

이러한 일련의 요청과 응답이 이루어진 후 해당 서버와의 통신은 다시 종료된다. 위와 같은 기본적인 지식을 알고 있다면 다음과 같은 질문을 할 수 있다. HTTP는 비연결유지 프로토콜이라고 하였는데 Session Hijacking 이란 공격은 어떻게 가능한 것인가? 이는 HTTP 세션 관리를 위해 사용되는 Session ID를 통해서 가능하다.


Session ID란 무엇인가?

웹 서버는 다수의 웹 페이지 요청자를 구별하기 위하여 각각의 사용자의 세션에 대해서 임의의 긴 문자열 값인 Session ID를 부여한다. 사용자가 홈페이지 방문시 혹은 인증 로그인시에 생성된다. 이러한 Session ID는 사용자의 계정, 암호, 그 밖의 IP 주소, timestamp 등의 여러 파라미터들을 조합하여 생성할 수 있다.


Session ID는 사용자와 일련의 웹 서핑 동작을 연결시켜줌으로써 웹 사이트 로그인 후 다른 페이지 방문시마다 매번 로그인을 하지 않아도 되는 편리함을 제공해준다.

우리가 신문 홈페이지나 포털 사이트에 들어갈 때 광고 배너가 자동으로 바뀐다던지, 쇼핑몰이나 인터넷 서적몰에서 구매 카트의 목록이 유지되는 것은 모두 이러한 원리이다. 즉, Session ID를 통해 인증과 인가(authentication
& authorization)라는 세션 관리를 수행할 수 있다.


Session ID는 어디에 존재하는가?

Session ID는 우리가 흔히 듣는 쿠키(cookie)라는 곳에 저장되는 것이 일반적이다. 그러나 가끔은 웹 브라우저 주소창 URL이나 HTML 페이지 폼 소스 상의 hidden 필드에 포함되어 드러나기도 한다.

1) 쿠키


2) 웹 브라우저 주소창의 URL


3) 웹 페이지 폼 소스 상의 hidden field



Session ID의 취약성은 무엇인가?

웹 서버에서의 Session ID 생성 기법 및 관리 기법에 따라서 다음과 같은 취약점이 존재할 수 있다.

  • 강력하지 못한 알고리즘(Weak Algorithm) : session ID 스트링 값을 생성함에 있어서 공격자가 reverse 엔지니어링이 가능한 쉬운 알고리즘으로 생성될 경우 cracking이나 brute-force guessing 공격의 위험이 있다.

  • 길이가 짧은 Session ID : 강력한 암호 알고리즘을 사용하더라도 그 길이가 충분하지 않고 짧은 경우에는 cracking이나 brute-force guessing 공격의 위험이 있다.

  • 계정 잠금 기능 미비 : 로그인 패스워드의 특정 회수 실패에 대해서는 보통 계정잠금 기능이나 해당 IP 차단 기능을 구현하고 있습니다. 그러나 보통 Session ID에 대한 무결성 침해나 특성 회수 실패에 대해서는 이러한 잠금 기능 구현이 미비하다. 따라서, brute-force guessing 공격의 위험이 있다.

  • 무한 만료의 Session ID : 사용자의 로그 아웃 이후에도 서버측에서 해당 세션 ID값을 폐기하지 않고 무한정 유효 인정한다면 cookie sniffing이나 프락시 서버의 로그 취득을 통하여 session ID 공격이 가능하다.

  • 평문으로 전달되는 Session ID : 서버에서 클라이언트로의 session ID 쿠키 전달 방식이 비암호화 방식일 경우에는 sniffing을 통하여 해당 값이 노출되어 공격 받을 수 있다. 특히 Session ID 값 자체가 사용자명이나 암호 등의 평문으로 구성되어 있는 경우에는 직접적인 공격이 가능하다.

    위와 같은 취약성에 대한 Session ID 공격의 유형은 다음과 같다.


    Session ID 공격유형

  • 직접적인 Cookie Sniffing을 통한 Session ID 도용
  • 간접 우회 공격을 통한 Session ID 도용
  • Brute-force guessing을 통한 Session ID 도용

    지금까지 Session ID가 무엇인지, 어떤 형태로 존재하는지, 왜 취약한지에 대해서 알아보았다. 다음에는 실제 공격 유형에 대해 살펴보고, 대응 방안에 대해서도 논의해 보도록 하겠다.

  • Session ID 공격 유형

    Session ID에 대한 공격은 크게 2 단계로 이루어진다. 1단계는 Session ID 취득 단계이고 2단계는 취득한 Session ID 공략 단계이다.

     

    [그림1] HTTP Session Hijacking 공격 흐름도

    공격자는 Session ID를 취득하기 위하여 웹 서버와 웹 클라이언트의 트래픽을 직접적으로 스니핑하거나, 웹 서버 상에 공격 코드를 삽입하여 두고 사용자가 클릭할 때 Cookie, Session ID 값을 전송받을 수 있도록 한다. 웹 서버와 웹 클라이언트 사이의 트래픽을 직접적으로 스니핑하는 방법은 일반적인 네트워크 트래픽 스니핑 기법을 통해 가능하다.
  •  

    POST /xxxxxx HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*Referer: http://xxx.xxx..comAccept-Language: koContent-Type: application/x-www-form-urlencodedAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)Host: ibn.kbstar.comContent-Length: 297Connection: Keep-AliveCache-Control: no-cacheCookie: Session=QJ48621878865

    [그림2] 네트워크 트래픽 스니핑을 통한 HTTP 요청 헤더 안의 쿠키값



    웹 서버 상의 HTML 코드 삽입이 가능한 페이지는 주로 사용자가 글을 게시할 수 있는 게시판이나 자료실 등에 존재한다. 정상적인 글을 게재하는 대신 공격자는 HTML 코드 및 스크립트를 심어 넣는다. 일반 사용자는 해당 게시물을 열람하게 될 때 자신도 모르는 사이 Cookie, Session ID 정보가 제 3 의 공격자 서버나 이메일로 전송되게 된다. (이러한 공격 기법을 Cross-Site Scripting이라고 부른다.)

    <form name=f method=POST action="http//host/hello.php"><input type=hidden name="name"value="<script>alert(document.cookie)</script>"></form><script>f.submit()</script>

    [그림3] 쿠키값 탈취를 위한 HTML 삽입 코드 예


    결과적으로 공격자는 취득한 타인의 Session ID 값을 웹 서버에 요청함으로써 HTTP Session Hijacking 공격을 시도할 수 있다. 물론 이 공격이 성공하려면 Session ID 값이 유효해야 하므로, 사용자가 로그온 한 상태에서 공격이 이루어져야 하거나 Session ID 값의 유지 시간이 긴 경우라는 제한 사항이 필요하다.


    그러나, 기본적으로 잘못 설계된 세션 관리 기법을 사용하고 있는 웹 서버는 이러한 Hijacking 공격에 취약할 수 밖에 없다. 굳이 타인의 Session ID 값을 직.간접적으로 취득하지 않고도 무작위 추측 대입(Brute-force Guessing)함으로써 공격이 가능하다. 공격자는 정상적인 로그인 과정시 분석한 자신의 Cookie 값, 웹 브라우저의 주소창의 URL, 웹 페이지 폼 소스 hidden field 내에 노출된 Session ID 값 자체를 분석한다.

    Session ID 생성 방식의 취약점을 파악한 후, 공격자의 컴퓨터에서 로컬 프록시 툴이나 웹 브라우저 창 URL 주소창에서 직접 Sessioion ID 값 단일 대입을 시도한다. 더 나아가 자동적인 Session ID 대입 스크립트를 작성하여 공격할 수도 있다.

    http://mmail.xxx.co.kr/mletter1/read_mail.asp?id=2266&tableName=musicMail1927&fromEmail=xxx@xxx.co.kr
    http://www.xxx.co.kr/view/UID2305670410000
    http://www.xxx.co.kr/view/UID2305670410341
    http://www.xxx.co.kr/view/UID2305670411302

    [그림4] 정상적인 Session ID 값

    http://mmail.xxx.co.kr/mletter1/read_mail.asp?id=3734&tableName=musicMail1927&fromEmail=xxx@xxx.co.kr
    http://www.xxx.co.kr/view/UID2305670410001
    http://www.xxx.co.kr/view/UID2305670410002
    http://www.xxx.co.kr/view/UID2305670419999

    [그림5] 무작위 추측 대입된 Session ID 값


    대응 방안

    HTTP Session Hijacking 공격에 대하여 웹 어플리케이션 개발자는 다음과 같은 점을 고려하여 세션 관리 기법을 구현하여야 한다.

    1. Session ID 생성 범위값을 사용자 수에 대비하여 충분히 큰 값으로 설정한다.
    2. Session ID는 가능한 한 추측 불가능(random)하게 생성한다. 무작위 추측 대입 공격을 할 때 공격자는 그만큼 더 많은 시간을 투입하여야 하며 현재 연결되어 활성화 되어 있는 유효한 Session ID 값을 찾는 확률은 낮아진다.
    3. Session Timeout 기능과 Session ID 재생성 기능을 사용한다. 일정 시간 동안 활동이 없는 사용자는 새로운 Session ID로 재로그인하도록 하고, 사용자 로그 아웃 시에는 Session ID 값을 폐기한다. 장시간 접속이 필요한 어플리케이션의 경우에는 일정 주기마다 Session ID값을 자동으로 재생성하여 세션을 유지하도록 한다.
    4. 무작위 추측 대입(Brute-force Guessing)에 대비하여 일정 회수 이상의 인증 실패시에는 사용자 잠금 기능을 구현한다.
    5. 로그인 이후에도 중요한 서비스 이용시에는 사용자 인증을 통하여 인가된 사용자만이 해당 서비스를 이용할 수 있도록 통제한다.
    6. Cookie 내용 안의 Session ID와 기타 변수값 자체를 암호화한다.
    7. 웹 서비스 자체의 중요성에 따라 Cookie가 전달되는 방식을 SSL로 구현함으로써 스니핑 공격에 대응할 수도 있다.
    8. 웹 서비스 상에 공격자가 HTML 공격 코드 삽입이 가능한 페이지가 있는지 점검한다. 직접적인 공격 코드 삽입을 차단할 수 있도록 특수 문자 및 스크립트 코드를 필터링하여야 한다.


    지금까지 HTTP Session Hijacking 공격 기법에 대해서 알아보았다. 대부분이라고 말할 수는 없지만 요즘 인터넷에 서비스되고 있는 인기 있는 웹 컨텐츠 서버는 기본적으로 안전한 세션 관리 기법으로 구현되어 있다. 그러나, 웹 컨텐츠의 인지도와는 별도로 이러한 공격 기법에 대한 인지 없이 비보안적으로 구현된 e-메일 카드 서비스, 전자 앨범 서비스 사이트 등이 다수 존재하는 것 또한 현실이다.

    HTTP Session Hijacking공격에 대한 대비는 안전한 웹 어플리케이션 구축을 위한 여러가지 항목 중에 필수적인 한 가지 사항이며, 기획 및 개발구현 단계에서 반드시 고려되어야 한다.

    [출처] 코코넛 시큐레터 2004년 5월호