레이피엘의 블로그

CSRF란?

 CSRF(Cross site request forgery, 사이트간 요청 위조)란 웹 사이트의 취약점을 이용하여 사용자가 의도하지 않는 요청을 송신하도록 하는 공격의 의미합니다. 이는 http프로토콜의 상태없음(stateless) 특성에 기인한 특정 웹 어플리케이션에 대한 일련의 요청들의 상관관계를 특정할 수 없기 때문에 세션 유지등에 일반적으로 사용되는 쿠키 정보 등이 조건만 만족한다면 자동적으로 송신되기 때문에 가능합니다. 여기서 상관관계를 특정할 수 없다는 의미는 예를 들어 카트화면 -> 주문정보 입력 -> 주문완료로 이어지는 주문 프로세스를 가진 웹 어플리케이션에서 각각의 페이지에대한 요청이 연속적으로 이어지는지에 대한 제어를 할 수 없다는 것을 의미합니다. 이 공격수법은 결과적으로 피해자가 의도한 요청과 동일한 과정으로 진행되므로 공격자에 대한 추적이 어려울 수 있으며 피해자에게 인가된 범위안에서만 공격이 이루어진다는 특징이 있습니다.(피해자가 특정 웹 어플리케이션의 관리자 계정으로 인증&인가된 상태라면 피해범위가 커질 수 있습니다.)

대략적인 공격 시나리오

1. 공격자가 공격코드를 가진 웹페이지를 제작하여 공개하거나 특정 웹 사이트에 공격용 코드를 삽입
2. 피해자가 공격자가 준비해둔 페이지에 접속
3. 피해자(피해자의 브라우저)는 공격자가 준비해둔 요청을 서버로 송신

공격방법

 CSRF공격방법에는 정형화된 수법이 있다기 보다는 웹에 요청을 보낼수 있는 모든 방법이 공격방법이 된다고 할 수 있다. javascript와 ajax를 이용한 방법, 전통적인 form방법, img태그를 이용한 방법 등등 요청을 보낼수 있는 방법이라면 그 어떤 것이라도 가능하다.

대책

 일반적으로 가장 널리 이용되는 방법에는 Synchronizer token pattern(동기화된 토큰 패턴)이 있다. 이 패턴은 서버 사이드(세션 스코프 등)에 보관된 토큰을 CSRF방어가 필요한 요청마다 포함(요청할 form에 hidden필드를 이용하여 토큰을 추가)시켜서 요청하고 서버에서 비교하는 방식으로 CSRF를 방어하는 방법이다. 가장 간단한 방식으로 사용자 경험에 영향을 주지 않는 방식으로 방어할 수 있으므로 널리 사용된다. 이 경우 토큰은 세션ID와 동일한 수준의 보호 수단이 필요하다.(SSL이용, URL노출 금지, 출력대상 페이지 캐시 컨트롤, xss취약점 방어 등등) 토큰의 유출이 염려스러운 경우 토큰 갱신 혹은 세션 파기 등등 즉각적인 조치가 필요하다.

 이외에 제한적인 환경에서 이용가능한 방법으로 Referer Header 참조하여 사이트 외부에서의 요청을 배제하는 방법등이 있겠다. 물론 Header영역의 데이터는 기본적으로 조작가능한 데이터 이기는 하지만 일반적인 브라우징 환경에서는 조작하기 힘들기 때문에(불가능하다는 의미는 아님) 폐쇄적인 환경등에서는 유효한 해결책이 될수도 있다. 물론 위와같은 방법으로는 사이트 내부에서의 공격에 취약하다. 게다가 http/https이동간, 최근의 브라우저등에 탑재된 private browsing 옵션에 의해서 Referer헤더가 송신 안되는 제약이 있으므로 제한적으로 이용해야 할 듯하다.

 가장 강력한 대책으로는 CAPCHA라든이 재인증등의 방법이 있겠지만 사용자 경험에 영향을 미치므로 신중하게 생각해서 도입해야 할 듯 하다.

참조

Open Web Application Security Project (OWASP). Cross-Site Request Forgery (CSRF).https://www.owasp.org/index.php/CSRF

※본 포스트의 내용은 해킹을 조장하기위해 쓰여진 글이 아닙니다. 위의 내용을 악용할 경우 처벌받을 수도 있으므로 내용을 이해하고 방어할 목적으로만 이용하시길 당부합니다.

Session Fixation 공격이란?

 세션 하이재킹 기법의 하나로 유효한 유저 세션을 탈취하여 인증을 우회하는 수법이다. 넓은 의미에서 세션 하이재킹이란 일반적으로 알려진 웹 어플리케이션의 세션ID를 탈취하는 수법 이외에도 TCP레벨에서 일어나는 공격까지 포괄적으로 칭할 수 있겠지만, Session Fixation 공격은 주로 웹 어플리케이션에 존재하는 세션 관리상의 제한이나 취약점을 이용하여 공격하는 수법입니다.

 Session Fixation은 일반적으로 세션 고정 공격으로 번역되는듯 합니다만, 원리나 공격방식에 비추어 볼때 세션 주입 혹은 세션 설치 공격등의 용어가 좀더 이해하기에 쉽지 않을가 생각됩니다. 일반적으로 알려진 웹 어플리케이션의 세션 하이재킹 공격은 세션ID탈취, 사용자 인증 완료 대기등의 과정을 통해 이루어집니다만 이 공격은 세션ID를 탈취하는 과정이 공격에 사용할 세션ID의 확보(발행 혹은 선택)하고 주입하는 과정으로 대체된다는 점에서 차이가 있다고 할 수 있다. 다시말해서 덫을 놓고 기다리는 것과 비슷하다고 할수 있겠습니다.

예상되는 공격 시나리오

1. 주입할 세션을 준비
2. 세션을 주입할 코드를 설치하고 유도한다.
3. 적절한 모니터링을 통해 인증을 통과한 세션을 확인하여 세션 하이재킹을 한다.
   

공격방법

 공격방법에 대해서 알아보려면 왜 공격이 가능한지에 대해서 알아두어야 할 듯합니다. 간략하게 웹 어플리케이션 서버가 클라이언트와 세션ID를 주고 받는 방식을 알아보면 아래와 같습니다.

1. URI상에 혼입되있는 경우(톰캣의 경우 URI상에 ;jsessionid=세션ID)
2. 리퀘스트 파라메터를 이용(이경우에는 URL상에 표기될수도 아닐 수도 있음) 
3. 쿠키를 이용하는 방법.

 별도의 특수한 방법을 배제하고 일반적으로 위와같은 방법을 이용하여 세션ID를 서버에 요청과 함께 전달하게 됩니다. 이처럼 세션ID를 주고 받는 과정에 준비된 별도의 링크를 클릭하게 한다든지 준비된 세션ID를 쿠키에 셋하는 등 세션ID에 개입할 수 있는 여지가 있기때문에 이같은 공격이 가능하다고 할 수 있습니다.

 공격방법1

 공격방법2

<script>document.cookie="jsessionid=함정세션ID";</script>

 공격방법3

<meta http-equiv="Set-Cookie" content="jsessionid=함정세션ID">

 기타

  그외에 서브도메인 쿠키를 이용한 방법이나 물리적인 공격(주변인이 직접 희생자의 PC에 준비한 세션ID주입 - 그럴 여유가 있으면 뭐든지 가능하겠지만... 자리를 비울때는 스크린 락을 이용하여 컴퓨터에 접근할 수 없도록 해둡시다.) 등

대책

 위에서 열거한 것처럼 공격방법에는 여러가지가 있으나 방어하는 방법은 간단하다. 바로 인증절차 후에 인가한 세션은 신규 세션을 발행하여 처리하는 방법이다. 공격자가 주입한 세션으로 인증절차를 통과하였다고 하더라도 인가된 세션은 신규세션이라면 공격자가 가지고 있는 세션ID로는 인증을 우회할 수 없기 때문이다. 다만 운영환경상에 제약으로 신규로 세션을 발행하지 못하거나 하는 경우는 인가시점에 쿠키상에 별도의 토큰을 발행하여 매 리퀘스트별로 세션영역에 보관된 토큰과 매칭을 시키는 방법등으로 접근을 제어할 수 있을 것이다.

 최근에 사이트들에 보이는 IP보안과 같은 IP대역을 이용하여 제어하는 방법, User-Agent를 이용하여 추가적으로 확인하는 방법 등도 어느정도 효과를 볼 수 있겠지만 사실 본질적인 해결책은 아니므로 위의 해결책을 이용하는 편이 좋을듯 하다.(세션 하이재킹에 대한 대비책이므로 본질적의미에서 Session Fixation에 대한 대비책은 아니다.)

 어플리케이션에 따라서는 신규세션 발행시에 기존의 세션스코프의 데이터를 이전해야 할 수도 있다. 그런 경우 이전할 데이터와 버려야할 데이터의 관리에 주의하여야 또다른 보안상 취약점이 생기는 것을 방지할 수 있을 것이다.

※본 포스트의 내용은 해킹을 조장하기위해 쓰여진 글이 아닙니다. 위의 내용을 악용할 경우 처벌받을 수도 있으므로 내용을 이해하고 방어할 목적으로만 이용하시길 당부합니다.

  웹 서버를 통한 파일 업로드 기능을 구현할 일이 있어서 보안 취약점 관련해서 정리해 보았습니다. 

1. Document Root이하에서 직접 접근할 수 있는 경로로 업로드 되지 않도록 구현하기.

 가장 중요한 사항이라고 할 수 있겠습니다. 웹 서버에서 직접 접속할 수 있는 경로에 파일을 업로드 시킬 경우에 실제 링크로 공개하지 않더라도 추측에 의해서 접근할 수 있으므로 주의를 기울여야 합니다.

※웹 개발에 있어 가장 명심해야 할 점은 Document Root이하의 경로는 명시적 링크가 없더라도 접근 가능하므로 업로드 된 시점부터는 공개된 리소스 취급을 해야한다는 점입니다.

※업로드된 파일의 다운로드는 구현된 어플리케이션을 통해 충분한 접근제어가 이루어질 수 있도록 합시다.

2. 의미없는(실행 불가능한) 확장자를 부여(혹은 삭제 혹은 제한)할 필요가 있습니다.

 위1번에서 말한 취약점 혹은 다른 취약점이 존재할 경우 실행가능한 확장자로 올리는 것은 매우 취약합니다. 예를 들어 파일을 삭제하는 기능이 담긴 웹 어플리케이션(ASP,JSP,PHP)을 업로드 후 접근하여 실행한다면 바로 서비스가 중단될 수 있습니다. 따라서 취약점이 존재하더라도 확장자만 바꾸어 주어도 어느정도 방어가 가능합니다.

※다운로드 하는 클라이언트에게 영향을 미칠수 있으므로 실행가능한 파일, 스크립트 파일등은 가능한한 제한하는 편이 좋습니다.

※허용가능한 확장자라 하더라도 특수한 의미의 파일 [예)robots.txt, crossdomain.xml 등]은 제한하는 편이 좋을 수 있습니다.

※업로드할 확장자 필터링은 블랙리스트 보단 화이트리스트 방식으로 제어하는 것이 보다 안전합니다.

3. 업로더가 제공한 파일명을 그대로 사용하지 않기

 클라이언트가 업로드시 파일의 메타정보로 함께 보내온 파일명, 사이즈 등등 그대로 활용할 경우 업로드 경로에 따라 덮어 써져 버릴 가능성이 존재합니다. 그로인해 실제로 열람이 불가능한 유저의 파일이 다운로드 가능한 상태로 되버릴 수 있습니다.

※중복되지 않을만한 충분히 랜덤한 파일명으로 치환하고 클라이언트가 제공한 파일명은 별도로 보관하는 것이 좋습니다.

4. 파일 사이즈 체크

 업로드 되는 파일 사이즈는 실제 서비스에 필요한 용량을 잘 예측해서 제한해야 합니다. 무제한으로 한다던지 예측후 서버의 저장장치 용량을 가용할 정도로 배정하지 않음으로 인하여 저장장치가 가득차서 서버가 뻗을수도 있습니다.

※임시 업로드를 통한 업로드 방식의 구현의 경우 임시 파일만 잘 삭제해 줘도 되겠지요

5. 인가된 사용자에게만 업로드 허용

 익명의 파일 업로드를 허용했을 경우엔 의도적으로 대량의 파일 업로드를 발생시켜 서비스를 무력화 시키는 공격도 대비해야 할지 모릅니다.

6. 한번에 올릴 수 있는 파일 수 제한

 한번에 다수의 파일을 올릴수 있는 경우 대량의 파일 전송에 의한 특정 디렉토리의 파일 과다 저장으로 인해 파일 시스템 자체가 매우 느려지는 경우가 있을수 있으므로 수를 제한하거나 충분히 분산할 수 있는 구현을 택하도록 해야 합니다.

7. 퍼미션 제한

 퍼미션을 제어할 수 있다면 실행 퍼미션을 제거 한다든지 하는것도 좋겠습니다만 어플리케이션상에서 제어에는 한계가 있는 경우도 있도 복사나 이동시마다 다시 체크가 필요하므로 자동적인 제어가 가능할 경우에는 하는것도 좋지만 너무 집착할 필요는 없겠습니다.

8. 바이러스 스캔

 가능하다면 주기적으로 업로드된 파일을 대상으로 바이러스 검사를 하는 것도 나쁘지 않겠습니다. 취약점을 잘 제거해서 서버상에서 실행되지 않아서 서버의 피해가 없는 경우라해도 다운받는 사람에게 영향을 미칠수 있으므로 검토하는 것이 좋겠습니다.

9. 실체 확인

 예를들어 이미지 파일이 맞는지 검증등 가능한 범위내에서 드러난 확장자외에 파일의 실체를 검증하는 것도 좋겠습니다.

10.헤더 지정

'Content-disposition: attachment'헤더를 지정하여 브라우저로 하여금 실행외에 파일 저장이 실행되도록 유도할 수 있습니다.

'Content-type'을 제대로 지정함으로서 다운로드후 의도하지 않는 연결프로그램이 실행되는 것을 방지 할수 있습니다.

이상 파일 업로드 취약점에 관하여 알아보았습니다. 최소한 위의 내용중 1, 2, 3번은 지켜야 안전한 사이트를 만들 수 있을 것같습니다.

※위의 내용은 개인적으로 찾아본 내용을 정리한 것입니다. 위의 내용만으로 안전을 '보증'할 수 없습니다. 또한 잘못 기술된 내용이 있을 수 있으므로 취사선택은 각자의 영역에 맞기도록 하겠습니다.