#03 인증 공격, 경로 탐색 공격, 세션 관리 공격

1. 인증기술

애플리케이션에서 사용 가능한 인증 기술

• HTML Form 기반 인증: 정확한 아이디, 패스워드가 입력되면 로그인이 됨 -> 기본적인 인증 기술.
• Multi-factor 매커니즘: 단순히 패스워드 뿐 아니라 보안 코드같은 물리적인 토큰(장치)들을 같이 섞어서 보안을 강화
• 클라이언트 SSL credentials / 스마트카드
• HTTP basic digest 인증
• 윈도우 기반의 인증

 

2. 인증 공격

• Bad 패스워드
• 무차별 대입 로그인
• Verbose Failure 메시지: 사용자 이름의 유/무효 여부에 따라 에러 메시지가 다르게 나오거나 반응시간이 다를 수 있음.
• 취약한 사용자 credential(사적인 정보) 전송: 암호화되지 않은 HTTP에서 중간에 왔다갔다하는 메시지를 중간에서 탈취해서 얻어냄.
• 패스워드 변경의 필요성
• Forgotten 패스워드 기능 관련 문제점: 패스워드 challenge 질문..
• Remember me 기능
• 패스워드 유효성

 

 

3. 인증 강화

• 안정성 측면에서 강한 credential(패스워드) 사용하기
• Credential(사적인 정보) 안전하게 다루기 (암호화, HTTPS, POST 요청 등)
• 무차별 대입 공격 예방
  • CAPTCHA: 사람인지 프로그램인지 구분하는 질문

 

• 계정 관련 기능의 오용 방지

 

 

4. 경로 탐색 공격

공격자가 query로 조작된 입력을 제출함으로써, 접근하는 파일 시스템에 대해 임의의 내용에 대한 읽기, 쓰기를 수행할 수 있음. (\과 .. 사용)

 

 

5. 경로 탐색 취약점 발견

file=foo/file1.txt와 file=foo/bar/../file1.txt를 제출해보고 두 파라미터에 대한 어플리케이션의 반응이 같으면 경로 탐색 취약점이 존재함.

 

 

6. 경로 탐색 공격에 대한 방어

입력 유효성 검사

1. 사용자 요청에 들어있는 파일 이름이 경로 탐색 sequence(\나 ..)를 포함하면 해당 요청을 처리하지 않고 sequence를 제외함.
2. 어플리케이션이 처리할 수 없는 파일 타입, 시작 디렉토리인 경우 처리하지 않음.
   • 회피하는 공격: 파일이름의 끝에 %00이나 %0a를 추가함.

 

 

7. 상태(state)의 필요성

- 초기의 웹 어플리케이션 HTTP 프로토콜: 웹 사이트에서 정보만 얻는 정도로만 사용(정적으로 사용)했기 때문에 상태를 저장하지 않았음. 서버가 사용자가 누군지 알 필요가 없었기 때문.

- 이제는 웹 사이트 상에서 사용자들이 서버와 동적인 상호작용을 통하여 정보를 주고 받기 때문에 서버가 사용자들을 알아야 할 필요가 생김!(어떤 사용자가 어떤 일을 하는지 알아야하기 때문) -> 이런 이유 때문에 상태 정보를 저장할 필요가 생긴 것!

 

 

8. 세션이란?

- 세션: 사용자와 웹 어플리케이션 사이의 활성화된 연결.. 세션을 통해 상태 정보를 저장함.

- 세션의 사용 이점:

• 어플리케이션이 각각의 사용자를 유일하게 인식하는데 유용함.
• 사용자와 어플리케이션 사이의 interactions과 관련된 상태를 저장, 관리하는데 유용함.

 

 

- 세션의 사용 시나리오:

• One-time 사용자 인증
• 로그인 기능을 사용하지 않는 어플리케이션 (예: 쇼핑몰 웹사이트)

 

 

9. 세션 구현

- 간단하고 보편적인 방법: 각각의 사용자에게 유일한 세션 토큰 또는 ID를 부여

 

- HTTP 쿠키:

• 서버와 클라이언트 사이에 세션 토큰을 전달하는 전송 메커니즘.
• 세션 탈취 공격에 취약함(프록시로 서버와 사용자 사이에서 오가는 세션 토큰과 ID 정보를 모니터링 및 탈취하여 해당 사용자인 척 할 수 있음.)

 

 

- HTTP 쿠키 기반의 방식

• 쿠키값 자체를 만들어서 토큰으로 지정
• 세션 토큰을 쿸키를 통해서 전달

-> 쿠키 기반 방식은 보안 측면에선 좋지 않은 방식... 따라서 보안성이 중요하지 않은 상황에서만 사용해야 함.

 

 

- HTTP 쿠키에 기반하지 않는 방식

• 보안성이 중요시되는 온라인 뱅킹에 사용됨 (외부에 공개되지 않은, 자체적으로 생성된 기법을 사용)

 

 

10. 세션 토큰 생성의 취약점

- 의미 있는 세션 토큰: 사용자의 이름, 이메일 주소 등과 관련된 정보를 변환해서 세션 토큰 생성

-> 공격자는 세션 토큰이 포함하는 정보를 활용해서 다른 어플리케이션 사용자의 현재 세션 토큰 값을 추측할 수 있음.

 

- 예측 가능한 세션 토큰: 특정 sequence, 패턴을 포함한 세션 토큰 생성

-> 공격자가 일정수의 세션 토큰들로부터 토큰 생성 방식을 파악한 후에, 다른 유효한 세션 토큰들을 찾아낼 수 있음. (유추)

• 순차적 생성
• 감춰진 sequence:
  • 세션 토큰의 시퀀스들을 인코드해서 감추는 기법. -> 공격자가 여러 인코딩 방식으로 시도해보다가 패턴을 발견하여 인코딩 방식을 알아내면 다른 사용자들의 세션 토큰도 찾아낼 수 있음.

 

• 시간 의존성:
  • 세션 토큰의 생성 시간을 이용해서 세션 토큰을 생성하는 기법 -> 현재 시간을 대충 알면 언제 어떤 수가 나올지 대충 예측이 가능함.

 

• 예측 가능한 난수 생성:
  • 우리가 사용하는 컴퓨터 프로그램에서의 난수는 완전히 랜덤한 것이 아니라 내부적으로 규정된 패턴에 의한 수(=sudo random)이기 때문에 공격자가 이 패턴을 알게 되면 예측할 수 있다.

 

 

 

11. 세션 토큰 관리의 취약점

- 세션 토큰이 안전하게 생성되더라도 안전하게 관리되지 않으면 공격자에게 유출될 수 있음.

- 취약점

• 네트워크 상에서 세션 토큰 유출: 세션 토큰을 주고 받을 때 암호화가 되지 않으면 문제가 생길 수 있음.
  • 암호화되지 않은 HTTP 사용: 암호화되지 않은 세션 토큰의 값이 그대로 공격자에게 유출됨.
  • 암호화된 HTTPS 사용: 시작부터 로그인을 한 이후까지 쭉 HTTPS를 쓰는 것이 가장 안전!

 

• 로그 상에서 세션 토큰 유출: 기록/저장되어 있는 세션 토큰들이 유출
  • 관리자에 의한 유출
  • URL 쿼리로 인한 유출 -> GET 메소드 말고 POST 메소드 사용하자!

 

• 취약한 세션 토큰 매핑:
  • 한 명의 사용자에게 하나의 토큰이 발급되는 게 정상인데 그 이상을 발급 받는 경우
    • 사용자가 다른 사용자에게 자신의 토큰을 공유한 경우
    • 공격자가 사용자의 토큰을 불법적으로 획득한 경우
  • 세션 토큰이 갱신되지 않는 경우
    • 한법 발급 받고 나서 재발급 될 때 같은 토큰을 재발급 받는 경우..

 

• 취약한 세션 종료: 세션을 종료할 때의 취약점.
  • 세션의 적합한 종료가 중요한 이유 -> 공격자에게 유출되어 악용되는 가능성 ↓
  • 세션 종료를 하지 않는 어플리케이션 -> 로그아웃 기능이 없음.

 

 

 

12. 세션 관리 안정성 강화

앞에서 나온 거 정반대로 행동하면 됨!

- 안전하게 토큰 생성하기

- 세션 토큰을 보호하기