OWASP Top 10 2013 - A2.Broken Authentication and SessionManagement (인증 및 세션 관리 취약점)

인증 방법

쿠키

- 서버에서 클라이언트쪽에 상태 정보를 저장하고 추출할 수 있는 방법

- 클라이언트쪽에 사용자 정보를 텍스트(.txt) 형태로 저장하며, 클라이언트의 매 요청마다 웹 브라우저로부터 서버에서 전송되는 정보 패킷의 일종

 

* 쿠키를 이용한 인증 순서

1. 클라이언트가 사용자 로그인 정보로 인증 요청

2. 서버가 사용자 정보를 쿠키 값으로 클라이언트에 전송하며, 인증 확인 결과를 반환

3. 클라이언트는 사용자 정보를 Tempory Internet Files (기본 값) 폴더에 저장

4. 클라이언트는 쿠키 값을 이용하여 로그인 상태를 유지

 

 

 

 

세션

- 클라이언트와 서버간에 네트워크 연결이 지속적으로 유지되고 있는 상태

- 클라이언트의 로그인 정보를 서버 내에 저장하여, 유저의 로그인/다른 상태를 지속적으로 유지시키는 것.

- 클라이언트는 서버에서 발급하는 인증키를 쿠키 값으로 저장하여 통신

 

* 세션을 이용한 인증 순서

1. 클라이언트가 사용자 로그인 정보를 인증 요청

2. 서버가 세션 인증 키를 쿠키 값으로 클라이언트에게 전달해주며, 인증 확인 결과를 반환

3. 클라이언트는 세션 인증 키를 쿠키 값으로 저장

4. 클라이언트는 쿠키 값을 이용해 로그인 상태를 유지

 

 

 

 

쿠키/세션 차이

 

	쿠키	세션
클라이언트 저장	User 정보	세션 인증 키
서버 저장	없음	User 정보
유지	쿠키를 지우지 않는 이상 영구	웹 브라우저를 닫거나, 서버에서 설정한 시간 초과시 소멸
자원	클라이언트 자원 사용	서버 자원 사용
속도	빠름	느림
용량 제한	도메인 당 20개,    쿠키 1개 당 최대 4KB	서버에서 허용하는 한 용량 제한 없음

 

 

 

 

세션 관리

 

세션 토큰 생성 과정에서의 취약점

- 추측 가능한 토큰

> 세션 토큰을 일정한 패턴을 가지고 생성, 간단하게 연속적인 숫자 몇 개로만 사용하는 등의 추측이 가능한 세션 토큰일 경우 공격자가 쉽게 토큰 값을

         추측할 수 있게 된다.

 

- 숨겨진 시퀀스

> 어플리케이션이 일반적으로 생성한 세션 토큰을 보면 어떤 내용인지 추측하기가 어려우나, 적절한 디코딩과 언패킹을 하게 되면 원본 메시지를

   볼 수 있는 경우도 있다.

 

- 시간 의존성

> 일부 웹 서버와 웹 어플리케이션은 세션 토큰을 생성할 때 시간과 관련된 알고리즘을 이용하여 토큰 값을 만드는 경우가 있다. 이 때, 세션 토큰이

   생성되는 패턴을 찾게 되면 다른 사용자의 토큰을 예상할 수 있다.

 

- 약한 무작위 번호 생성

> 세션 토큰을 생성하는데 추측 가능한 랜덤 숫자를 사용하면, 공격자가 세션 토큰 생성에 사용되는 랜덤 숫자 생성의 알고리즘을 파악하고,

   파악한 알고리즘으로 생성된 숫자를 알게 된다면 그 다음 생성될 숫자를 추측할 수 있다. 즉, 서버로부터 하나의 세션 토큰을 얻고 알고리즘을 파악하면

   이 후 생성될 모든 세션 토큰을 얻을 수 있다는 것이다.

 

 

 

 

세션 토큰 처리 과정에서의 취약점

- 네트워크 상의 토큰 노출

> 네트워크 상의 토큰 노출은 암호화 되지 않은 통신(HTTP 등)을 이용하여 세션 토큰을 전송할 때 발생한다. 이를 공격자가 사용자의 네트워크 망 등 스니핑이

   가능한 공간에서 스니핑을 통하여 세션 토큰을 가로챌 수 있다.

   아래의 사진은 HTTP 프로토콜을 이용하여 Set-Cookie가 노출되는 패킷이다. 위의 쿠키를 이용하면 해당 쿠키를 보유한 사용자의 권한 탈취까지 가능하다.

 

   

 

 

- 로그에서의 토큰 노출

> 자주 발생되는 경우는 아니지만, 시스템 로그에서 토큰이 노출되기도 한다. 시스템 로그에서 세션 토큰이 노출 되는 경우는 웹 어플리케이션이 토큰의

   전송으로 HTTP 쿠키, POST 요청이 Body의 사용을 하지 않고 URL 쿼리 문자열을 사용할 때이다.

 

- 세션 종료의 취약점

> 세션을 적당한 시간/방법에 의해 존재하지 않으면 무한에 가까운 유한의 시간동안 유요하다. 따라서 세션의 종류/폐기는 매우 중요하다.

1. 세션의 사용 기간을 짧게 할수록 공격자들이 유요한 세션 토큰을 수집, 추측 및 악용하는 시간을 줄일 수 있다.

2. 사용자들이 웹 어플리케이션을 한동안 사용하지 않으면 세션을 종료(Timeout) 함으로써 존재하는 세션을 무효화 시킨다.

 

 

 

 

 

취약한 인증

  - 사용자 인증 기법

>  사용자 인증 기법에는 다양한 방법들이 있으며, 아래와 같이 일반적으로 사용되는 방법들 이외에도 SSL 인증서, 스마트 카드, HTTP, 해시 인증 등의

    방법들이 존재한다.

 

- HTML 폼 기반 사용자 인증

> 가장 일반적인 인증 방식으로 폼을 이용하여 사용자명(ID)와 비밀번호를 입력 받아 어플리케이션에 보내는 방식이다.

 

- 비밀번호와 OTP 발생기를 이용한 이중 인증

> 인터넷 뱅킹, 개인정보 등이 포함되어 보다 많은 보안이 요구되는 어플리케이션에서는 OTP(일회용 패스워드) 발생기를 이용하여 이중 인증을 사용한다.

   OTP 발생기는 어플리케이션이 제시한 입력 값으로 일회용 비밀번호를 생성하고, 사용자가 인증을 하기 위해서는 자신의 패스워드+일회용 비밀번호를

   정확하게  입력해야 한다. 근래에는 OTP 발생기의 가격이 저렴해지고 S/W를 이용한 방식도 등장하고 있어 보다 대중적으로 알려졌지만 그러나

   아직도 피싱 공격이나   클라이언트쪽에 숨겨진 악성코드를 통한 공격에는 효과적이지 못하다.

 

 

 

 

 

인증 구조의 설계상 취약점

- 사용자 인증 기능은 웹 어플리케이션 설계 자체에서 취약점을 내포하기 쉽다. 사용자명과 비밀번호에 기반한 사용자 인증을 사용하는 경우와 같이 매우 단순한

   경우라도 인증 방식의 설계에 따라 웹 어플리케이션의 보안 수준이 달라진다. 설계상에서 발견되는 취약점들은 주로 아래와 같으며 그 외에도 여러 가지

   취약점들이 존재한다.

 

- 무차별 대입 가능

> 인증 구조가 로그인 시도를 번복적으로 할 수 있게 허용하는 구조의 경우 무차별 대입(Brute Force), 사전 공격(Dictionary Attack) 등의 기능을 제공하는

  도구에 의해 로그인 시도가 가능하다. 비밀번호의 안정성이 높더라도 이러한 공격을 통하면 결국 비밀번호를 알아낼 수 있다.

  아이러니하게도 몇몇의 웹 어플리케이션은 이러한 취약점을 클라이언트를 통제하여 비밀번호 추측 공격을 막으려고 하는데,

  예를 들면 쿠키에 "failedlogin" 이라는 값을 넣어 로그인이 실패할 때 마다 해당 값을 증가시켜 임계칩 값 이상이 되면 로그인을 거부하게 만드는 방법을

 사용한다. 문제는 쿠키 값은 사용자 측에서  손쉽게 변조되기 때문에 위와 같은 통제 방법은 있으나 없으나 그저 그런 방안이 된다.

 

 FTP 서버에서 확인되는 무차별 대입 공격 모습 (192.168.0.111 공격 중)

 

공격 툴에서 사용되는 무차별 대입 공격 모습 (user:admin, pwd:test 로그인 성공)

 

 

 

 

- 상세한 로그인 실패 메시지

> 웹 어플리케이션은 사용자가 로그인 할 때, 사용자명과 비밀번호 입력만을 요구하는 경우가 대부분이다. 로그인이 실패하면 최소한 이들 정보 중에

   한 가지 정보가 틀렷다는 것을 추론할 수 잇다. 그러나 웹 어플리케이션에서 어느 정보가 틀리다고 알려준다면 이를 이용하여 사용자 인증 제어를

   약화시킬 수 있다.

 

     위와 같이 어느 정보가 틀렸는지를 알려주는 실패 메시지는 부적절한 경우이다. (공격에 걸리는 시간/노력을 50% 감소시켜 준다)

 

 

 

       

    실패 메시지에서 "아이디 또는 비밀번호 오류" 라는 메시지를 출력시켜 어느 정보가 틀렸는지 알 수 없게 만들어 추론이 불가능하다

 

 

 

 

 

 

대응 방안

  - 클라이언 사이드에 저장되는 쿠키가 쉽게 변조되는 것과 달리 서버 사이드에 저장되는 세션의 변조는 쿠키가 비하여 까다롭기 때문에 쿠키 보다는 세션(토큰)을 

     사용하는 방식이 권장된다. 그러나 서버 환경에 따라 무턱되고 모든 인증을 세션으로 처리하게 되면 서버의 과부화가 유발되어 일종의 DoS 상태에 빠질 수 있기  

      때문에  부분적으로는 쿠키를 사용할 수 있는데, 이런 때에는 인증 부분을 넣지 않거나, 암호화 처리를 해야한다.

 

- 쿠기 사용 대응 방안

1. http only 옵션 사용

    http only 옵션 사용시 XST(Cross Site Tracing) 공격에 취약할 수 있기 때문에, XSS/CSRF 취약점 대응 방안을 통해 XST 공격에 대한 대비가 필요하다

 

2. 암호화 쿠키 생성

   사용자 인증, 권한 부여 등 중요 기능을 쿠키로 구현 시 쿠키를 SEED, 3DES, AES 등 안전한 암호화 알고리즘을 사용해야 한다.

   * 쿠키는 대부분 복호화가 필요하기 때문에 양방향 암호화가 권장된다.

 

- 세션(토큰) 사용 대응 방안

1. 강력한 토큰 생성

    가능한 많은 집합으로 이루어진 값을 사용해야 하며, 그 값의 집합에 랜덤한 값 / 예상하기 어려운 세션을 생성해야 한다.

    * 아무리 길이가 길고 복잡한 토큰이여도 공격자가 충분한 시간, 자원이 있으면 크랙이 가능하다.

       강력한 토큰을 생성하는 이유는 크래킹의 불가능이 아니라, 크래킹에 걸리는 시간을 최대한 오래 만드는것이 목적이다.

 

2. 토큰 생명 주기

   토큰이 생성되고 해당 사용자 이외의 사람들은 사용하지 못하게 해야 하며, 토큰이 폐기 될때까지 안전하게 보호해야 한다.

   *토큰은 반드시 https(http with ssl)을 통하여 전송해야 하고, 동시 로그인을 제한, 사용자의 세션 값이 만료되거나 삭제 되면 즉시 폐기 해야 한다