시큐어코딩 (3일차)

세션관리 취약점

 

HTTP 프로토콜은 상태관리를 하지 않는 (Stateless) 프로토콜이다. 서버는 클라이언트의 정보를 유지하기 위해 세션메모리를 할당하여 클라이언트의 인증정보를 관리한다.

 

할당된 세션메모리를 구분하기 위해 서버는 세션ID를 할당하게 되며, 할당된 세션ID는 쿠키, URL파라메터, <form>의 hidden 파라메터값 형식으로 클라이언트에게 전달한다.

 

다른 사용자의 권한을 가로채기 위해서는 사용자의 정보를 저장하고 있는 세션의 정보를 추측하거나, 훔치거나, 공격자가 원하는 세션을 사용하게 하는 방법을 이용할 수 있다.

 

- 세션ID 추측 : 세션ID 생성방법이 부적절한 경우 제 3자가 추측가능하며 세션 하이재킹이 가능하다.

- 세션ID 훔치기 : 네트워크상에서 패킷 스니핑을 통해 세션ID를 훔쳐내거나, XSS(크로스사이트스크립팅) 등 애플리케이션 취약점에 의해 유출되거나, 세션ID를 URL에 가지고 있는 Redirect를 이용하거나, 브라우저의 취약점을 통해 세션ID를 훔쳐내고, 이를 이용하여 세션 가로채기가 가능하다.

- 세션ID 고정 : 공격자가 사용자의 브라우저에 세션ID를 설정하는 것이 가능하다면, 공격자는 이미 사용자의 세션ID를 알고있는 상태가 될 수 있으므로 세션 하이재킹이 가능하게 된다.

 

계정관리 취약점

 

계정관리 정책은 기업의 내부통제 및 보안강화의 필수 요소이다.

 

IAM(Identity & Access Management) : 식별된 사용자가 권한을 가진 IT자원에 접근할 수 있도록 통제

 

계정관리 구성요소

- 운영관리

- 인증

- 인가(Authorization)

- 감사(Audit)

 

인증관리 취약점

인증은 내가 '나'임을 증명하는 것으로, 인증방법에 따라 지식기반, 소유기반, 생체기반의 방식으로 구분할 수 있다. 

- 생성단계 

- 변경단계 : 사용자가 패스워드 변경을 필요로 하거나 요청하였을 때 안전하게 패스워드가 변경될 수 있도록 정책 적용

- 이용단계 : 암호화된 통신채널을 통해 전달되거나 안전하게 일방향 암호화 알고리즘으로 암호화해서 저장한다.

 

인증시도 관리 정책

일반적으로 '로그인','로그아웃' 이라는 프로세스를 이용하여 인증을 처리하게 되는데 이 프로세스에 대한 정책이 잘못 구현되어 있는 경우 침해사고로 이어질 수 있다.

 

- 로그인 요청처리 암호화

- 로그인 시도 횟수 제한 및 반복 로그인 실패에 대한 대응

- 다중 로그인 허용 여부

- 오랫동안 사용하지 않는 세션에 대한 로그아웃

- 사용자 화면 설계 시 로그아웃 접근성

 

파일 업로드/다운로드 취약점

업로드 기능에서 취약점의 발생 원인

- 업로드 되는 파일의 타입을 제한하지 않는 경우

- 업로드 되는 파일의 크기나 갯수를 제한하지 않는 경우

- 업로드 된 파일을 외부에서 직접적으로 접근가능 한 경우

- 업로드 된 파일의 이름과 저장된 파일의 이름이 동일하여 공격자가 파일에 대한 인식이 가능한 경우

- 업로드 된 파일이 실행권한이 있는 경우

 

다운로드 기능에서 취약점의 발생원인

- 파일에 대한 접근권한이 없는 사용자가 직접적인 경로를 이용하여 파일을 다운로드 할 수 있는 경우

- 악성코드에 감염된 파일을 다운로드 허용하는 경우

 

잘못된 기능 접근제어

접근제어는 권한이 있는 사용자에게만 특정 자원이나 기능이 제공되는 것을 보장하는 것

 

잘못된 접근제어는

- 네트워크 접근이 가능한 내/외부 사용자는 모두 공격자가 될 수 있음

- 인증을 통해 시스템에 접근한 사용자가 URL이나 파라미터를 조작하여 권한이 필요한 기능에 접근할 수 있음 

- 이 경우 인가된 사용자에 대한 권한이 제대로 체크되지 않으면 허가되지 않은 기능이 수행되거나, 허가되지 않은 정보가 유출될 수 있음

 

접근제어 취약점 진단은

- URL 조작을 통해 허가되지 않은 리소스나 기능에 접근이 가능한지 점검

- 파라미터 조작을 통해 허가되지 않은 리소스나 기능에 접근이 가능한지 점검

- 헤더나 쿠키값 조작을 통해 허가되지 않은 리소스나 기능에 접근이 가능한지 점검

 

직무 분리

: 단계별로 직무를 분리하여 보안성을 더 높게 유지할 수 있다.

예를 들어 보안, 감사, 개발, 운영, 암호키관리, 암호키변경 등 직무를 나눠놓는다.

 

최소 권한의 원칙

: 허가받은 일을 수행하기 위한 최소한의 권한만을 부여하여, 권한 남용으로 인한 피해를 최소화 해야 한다.

예를 들어 애플리케이션이 DB에 접속할 때 해당 애플리케이션이 사용하는 테이블에 대해서만 데이터를 조작할 수 있는 계정을 사용한다.

최소권한의 원칙을 구현하기 위해 정보등급 분류, 접근통제 리스트와 같은 방법을 사용한다.

 

접근제어 방법

1. 자율적 접근제어(DAC : Discretionary Access Control) : 데이터 소유자가 접근을 요청하는 사용자의 신분(식별자)에 기초하여 객체에 대해 접근을 제한 접근 통제 목록(ACL : Access Control List)를 사용한다.

2. 강제적인 접근제어(MAC : Mandatory Access Control) : 관리자가 정책에 근거해 권한을 할당. 주체와 객체에 보안 등급(레이블)을 부여하고, 접근 제어시 이 등급을 비교하여 접근 허용 여부를 판단. 엄격한 보안이 요구되는 분야에 적합.

3. 역할기반 접근제어(RBAC : Role Based Access Control) 

 

중요 정보 노출

암호화의 법적 기준 : 정보통신망법

 

애플리케이션 자체 암호화 방식 (속도 빠름)

- 암복호화 모듈이 API 라이브러리 형태로 애플리케이션 서버에 설치되고, 애플리케이션에서 해당 암복호화 모듈을 호출한다.

- DB서버에 영향을 주지 않는다.

- 기존 시스템의 경우 애플리케이션의 수정이 요구된다.

- 취약한 권한통제 (국정원 통제요건 일부만 준수)

 

DB 서버 암호화 방식

- 암복호화 모듈이 DB서버에 설치되고, DB서버에서 암복호화 모듈을 호출한다.

- 구축시 애플리케이션의 수정을 최소화할 수 있다.

- DB서버에 부하가 발생하며 DB스키마 추가 작업이 요구된다.

- 기존 Plug-in 방식과 유사하다.

 

DBMS 자체 암호화 방식

- DB서버의 DBMS커널에서 암복호화가 수행된다.

- 구축시 애플리케이션의 수정이 필요하지 않다.

- DBMS에서 DB스키마 지정이 필요하다.

- 기존 TDE 방식과 유사하다.

 

운영체제 암호화 방식

- 운영체제에서 물리적인 입출력을 이용한 암호화 방식이다.

- DBMS의 데이터 파일을 암호화한다.

- DB 성능 저하는 상대적으로 작지만 OS, DBMS, 저장장치의 호환성 검토가 요구된다.

 

대칭키 알고리즘을 이용한 암호화 시 충분하지 않은 키 길이 사용

-> 대칭키 알고리즘 사용시 키 길이를 128비트 이상으로 하는 것이 안전하다.

 

안전하지 않은 대칭키를 이용하는 블록 암호화 알고리즘 사용

-> 안전한 대칭키 알고리즘을 이용한 암호모듈을 이용하여 암호화. AES, ARIA, SEED와 같은 알고리즘을 사용하며, 키 길이는 128,192,256비트를 사용한다.

 

솔트(salt)값을 사용하지 않은 해쉬함수

-> 솔트(salt)값을 사용하여 해쉬문의 안전도를 강화. 난수로 발생시킨 충분히 긴 문장을 솔트(salt)값으로 설정하여 해쉬함수의 입력값으로 추가 설정하여 해쉬문의 안전도를 강화한다.

 

암호키 관리 정책

암호키 관리의 가장 기본적인 고려사항은

1) 암호에 사용되는 모든 키는 불법적으로 변경, 대체되지 않도록 해야하며,

2) 암호키와 개인키는 노출되지 않아야 한다.

 

암호키 사용에 대한 고려사항은

1) 암호방식에 사용되는 키는 하나의 목적(암호화용, 인증용, 키 암호화용, 키분배용 등)으로만 사용되어야 한다.

2) 키의 용도제한으로 외부에 노출되거나 손상되었을 때 피해 범위를 최소화 한다.

 

암호키 사용기간 및 유효기간은

1) 사용자 또는 관리자가 암호키를 사용할 수 있도록 허용된 시간을 사용기간은 최대 2년

2) 사용이 완료된 이후라고 추후 복호화를 위해 해당 암호키를 사용하도록 허용된 기간은 5년이다.

 

암호키 저장 방법

암호키는 서버 또는 하드웨어 토큰에 저장

1) 암호키를 저장하는 서버는 기존 서비스를 하고 있는 웹서버나 DB서버와 물리적으로 분리되어 있는 서버를 사용하는 것을 권고.

2) 하드웨어 토큰은 저장된 정보가 위변조 또는 외부로 노출되기 어려운 장치로 스마트 카드, USB토큰 등의 보안토큰을 의미.

 

HTTP 응답분할

 

정수 오버플로우

 

안전하지 않은 예외처리

 

널포인트 역참조