'security'에 해당되는 글 2건

  1. 2014.07.14 CSRF(cross site request forgery) 3
  2. 2013.12.20 웹 파일 업로드 보안 취약점 2
Security2014. 7. 14. 23:27
반응형

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




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



'Security' 카테고리의 다른 글

robots.txt와 보안  (0) 2015.03.18
보안에 대한 생각 - 파일 해시 검증하기  (0) 2015.03.04
Session Fixation 취약점  (2) 2014.07.02
웹 파일 업로드 보안 취약점  (2) 2013.12.20
윈도우 Self-Signed SSL증명서 생성  (0) 2013.12.03
Posted by Reiphiel
Security2013. 12. 20. 00:12
반응형

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


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번은 지켜야 안전한 사이트를 만들 수 있을 것같습니다.


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



'Security' 카테고리의 다른 글

robots.txt와 보안  (0) 2015.03.18
보안에 대한 생각 - 파일 해시 검증하기  (0) 2015.03.04
CSRF(cross site request forgery)  (3) 2014.07.14
Session Fixation 취약점  (2) 2014.07.02
윈도우 Self-Signed SSL증명서 생성  (0) 2013.12.03
Posted by Reiphiel