Web Application Hacking

웹 애플리케이션 해킹 개요 2에서는 웹 애플리케이션에서 발생하는 보안 문제점의 원인이 어디에서 기인하는지에 대해서 알아본다.


0x01. 웹 애플리케이션의 보안 문제점

신기술이 늘 그렇듯 웹 애플리케이션도 새로운 영역의 보안 취약점을 함게 가져왔다. 가장 보편적으로 마주치게 되는 보안 결함이라고 하는 것들도 세월에 따라 진화를 거듭해 변모하고 있다.

그 중 일부 문제점은 애플리케이션 개발자들의 보안에 대한 인식이 확산되고 보안 결함을 대비해서 상당히 완화되기도 했으며, 어떤 유형의 보안 결함은 웹브라우져 소프트웨어의 변경을 통해 거의 제거되고도 했다.


○ "이 사이트는 안전합니다."

웹 애플리케이션 보안은 단지 하나의 이슈일 뿐이라는 인식이 광범위하게 퍼져 있다. 흔히 볼 수 있는 예가 사용자를 안심시키기 위해 128Bit 기반의 SSL을 채택하고 있어서 안심해도 좋다고 한다. 실은 대부분의 웹 애플리케이션이 SSL의 채택 여부와 무관하게 안전하지 않다.




0x02. 웹 애플리케이션의 보안 문제점 원인

웹 애플리케이션 공격의 대부분은 개발자들이 예상치 못했거나 의도하지 않은 동작을 유발하는 조작된 값을 서버로 보내는 형태로 이뤄진다.


즉, 보안 문제의 핵심 원인은 아래와 같다고 할 수 있다.



어떤 어플리케이션이든지 사용자로 부터 제공된 데이터를 무조건 신뢰하는 것 자체가 바로 보안 문제점의 원인이 된다.


○ 주요 문제점

웹 애플리케이션에서 발생하는 다양한 취약점의 발생의 주요 원인에 대해서 알아보자.

그림1. 주요 문제점 발생의 원인

→ 미성숙된 보안 의식

네트워크나 운영체제와 관련한 보안 취약점과 달리 웹 애플리케이션 보안 문제에 대한 인식은 미숙한 편이다.  IT보안 담당자들은 일반적으로 네트워크나 시버 보안의 핵심은 어느 정도 잘 숙지하고 있는 반면 웹 애플리케이션 보안에 대해서는 핵심적인 개념에 대해서도 제대로 이해하지 못하는 경우가 많다.


→ 자체 개발

자체 인력이나 비정규직 인력에 의해 개발을 진행하는 것이 대부분이다. 이는 검증된 안전한 소스를 쓰는 경우에도 자기 사이트에 맞게 수정하여 사용하며 이 과정에서 다양한 결함이 생기는 경우가 많다.


→ 개발의 단순함

웹 애플리케이션 플랫폼과 개발 툴 등이 워낙 편리해서 초보 개발자도 단시간에 아주 강력한 애플리케이션 개발이 가능하게 되었다. 하지만 프로그램이 잘 작동되는 것과 보안에 안전한 코드를 만드는 것은 판이하게 다른 일이다.


→ 빠르게 진화하는 위협 프로파일

웹 애플리케이션 공격과 방어는 타분야에 비해 상대적으로 새로운 분야로 새로운 개념과 위협들이 많이 발생한다. 개발팀이 현재의 모든 위협을 고려해도 설치될 무렵에는 이미 모든 위협을 고려했다고 하기 어렵게 되는 경우가 많다.


→ 자원과 시간 제약 요소

대부분의 웹 애플리케이션 개발 프로젝트는 시간과 리소스, 즉 경제적인 제약에 쫓기게 된다. 이러한 현실에서 시스템 설계나 개발에 보안 전문 인력의 참여가 어렵고 보안 전문가에 의한 보안성 테스트는 개발 일정을 지연시키는 요인이 되어 거의 이뤄지지 않는 편이다.

개발 일정에 맞춰 우선순위를 조정하다보면 구체적으로 당면한 보안 위험이 아니면 일정에 맞춰 애플리케이션 기능 구현에 우선시 될 수 밖에 없다.

일정에 쫓겨 프로젝트 막바지에 진행하는 간단한 모의해킹은 손쉽게 도출 가능한 취약점을 탐지할 수 있을지는 몰라도 장시간 동안 정밀 진단을 통해서만 도출 가능한 매우 어렵거나 미묘한 중요 취약점에 대해서는 탐지가 어렵게 된다.


→  급속하게 확장된 기술

웹 애플리케이션 기술은 빠르게 발전되고 확장되어 활용되고 있다. 예를 들어 Javascript의 경우 Ajax 기반의 애플리케이션에서 데이터 전송의 수단으로 활용되고 있다.

급속한 발전과 고객의 요구에 따라서 이미 수명이 다한 기술들을 과도하게 변형하고 응용되고 있으며, 이에 따라 예상치 못했던 부작용들이 나타나게 되고, 결국에는 새로운 보안 취약점으로 귀결되고 있다.

■ Web Server

웹서버는 클라이언트/서버 모델과 웹의 HTTP를 사용하여 웹 페이지가 들어 있는 파일을 사용자들에게 제공하는 프로그램이다. 웹사이트가 운영되고 있는 인터넷상의 모든 컴퓨터들에는 모두 웹서버 프로그램이 설치되어 있다. 가장 보편적인 웹서버들로는 32 비트 윈도우와 유닉스 기반의 운영체계에서 모두 쓸 수 있는 아파치와, 윈도우 NT에 딸려 나오는 IIS, 그리고 넷스케이프의 엔터프라이즈 서버 등이 있다. 그밖에 네트웨어 운영체계를 쓰는 사용자들을 위한 노벨의 웹서버, 주로 IBM의 OS/390과 AS/400 고객들을 위한 IBM의 로터스 도미노 서버를 비롯, 다른 웹서버들도 있다.

웹서버들은 흔히 전자우편, FTP 파일의 다운로드, 그리고 웹페이지 구축, 발간 등에 필요한 인터넷 및 인트라넷과 관련된 프로그램들의 커다란 패키지의 일부로서 나온다. 웹서버를 고를 때 고려해야할 사항으로는, 운영체계나 다른 서버들과 얼마나 잘 어울려 동작할 것이냐 하는 것과, 서버 측의 프로그래밍, 퍼블리싱, 검색엔진 등을 처리하는 능력, 그리고 함께 따라오는 구축도구 등이 있다.

■ WAS (Web Application Server)

웹과 기업의 기간 시스템 사이에 위치하면서, 웹 기반 분산 시스템 개발을 쉽게 도와주고 안정적인 트랙잰션 처리를 보장해 주는 일종의 미들웨어 소프트웨어 서버. 3계층 웹 컴퓨팅 환경에서 기존 클라이언트/서버 환경의 애플리케이션 서버와 같은 역할을 하며, 클라이언트와 서버 환경에서 트랜잭션 처리및 다른 기존 시스템 간의 애플리케이션 연동을 등을 주된 기능으로 하고 있다.

요즘들어서는 WAS는 주로 데이터베이스 조회나 일반적인 비즈니스 로직에 대한 처리를 위해 다양한 언어로 개발된 인터넷/인트라넷 환경의 소프트웨어로 많이 불리운다. 자바스크립트나 JSP 등과 같은 스크립트 및 서비스들은 대개 최신의 데이터를 검색하기 위해 데이터베이스에 접근하고, 브라우저 또는 클라이언트 프로그램을 통해 사용자들에게 검색 결과를 제공한다.

WAS를 비롯한 애플리케이션 서버들은, 웹서버 즉 HTTP 서버와 같은 컴퓨터를 공유할 수도 있지만 별개의 컴퓨터를 독립적으로 사용하는 경우도 많다. 대규모 사이트에서는, 오히려 WAS와 웹서버 등을 위해 여러 대의 컴퓨터가 동원되기도 한다.
넷스케이프의 Netscape Application Server, Bea의 Weblogic Enterprise, 볼랜드의 Appserver, 그리고 IBM의 Websphere Application Server 등의 WAS 대표적인 제품들이다.

※Web Server와 WAS와 차이※

- Web Server 의 정의 : Web Client(웹 브라우저)에게 컨텐츠를 제공하는 서버, 정적인 HTML이나 jpeg, gif 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에게 전송하는 역할

- WAS(Web Application Server)의 정의
   ○ Server 단에서 Application을 동작할 수 있도록 지원함 => Jeus
   ○ 기존 웹 서버와 달리 동적인 요구에 대응하기 위해 적합한 형태로 변화,
        Web Client(브라우저)에게는 결과값만 전송함.
   ○ Container(컨테이너)라는 용어로 쓰이며, 초창기는 CGI, 그 후에서는 Servlet, , JSP,
        ASP 등의 프로그램으로 사용됨

- Web Server와 WAS의 구성에 따른 분류
   ○ WAS와 WebServer를 분리하지 않는 경우  
        모든 컨텐츠를 한곳에 집중시켜 웹서버와 WAS의 역할을 동시에 수행, 스위치를 통한
        로드 밸러싱, 사용자가 적을 경우 효율적
 
   ○  WAS와 WebServer를 분리한 경우
        웹서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도, 정적인 데이터는 웹서버에서
        처리, 동적인 데이터는 WAS가 처리
 
   ○  WAS 여러개와 WebServer를 분리한 경우
        WAS단을 프리젠테이션 로직와 비즈니스 로직으로 구분하여 구성, 특정 logic의 부하에 따라
        적절한 대응할 수 있지만 설계단계 유지보수 단계가 복잡해 질 수가 있다.

■ WAS 와 Web Server 종류

   ○ WAS 종류
       tomcat, tMax jeus, BEA Web Logic, IBM Webspere, JBOSS,Bluestone, Gemston,
       inprise, PowerTier,Apptivity, silverStream

   ○ Web Server 
       IIS, apache, tMax, WebtoB

   - tomcat
       아파치 소프트웨어 재단의 애플리케이션 서버로서, 자바 서블릿을 실행시키고 JSP 코드가
       포함되어 있는 웹페이지를 만들어준다. 자바 서블릿과 JSP 규격 '참조용 구현'으로 평가되고
       있는 톰캣은, 개발자들의 개방적 협력 작업의 산물로 바이너리 버전과 코어버전 둘 모두를
       아파치 웹사이트에서 얻을 수 있다. 톰캣은 자체적으로 보유하고 있는 내부 웹서버와 함께 독립
       적으로 사용 될 수도 있지만 아파치나 넷스케이프 엔터프라이즈 서버, IIS, 마이크로소프트의
       PWS 등 다른 웹서버와 함께 사용될 수도 있다. 톰캣을 실행시키기 위해서는 jre  1.1  이상에
       부합되는 자바 런타입 환경이  필요하다.

※ 출처 : http://blog.naver.com/skypoohkjs?Redirect=Log&logNo=60078233

lastest update 2009. 03. 01

첫번째로 Web Application hacking 개요에서는 웹 해킹의 의미를 알아보고 주요 공격대상과 공격 범위 그리고 해킹의 트랜드가 웹 해킹으로 전이된 원인 등에 대해서 알아 보도록 하겠습니다.



0x01 웹 해킹이란?




0x02 웹 애플리케이션의 중요성

일상 생활에서 가장  손쉽게 정보를 얻을 수 있는 1순위가 인터넷이 되었다는 것에 모든 사람들이 동의할 것이다. 리포트를 적거나 정보를 검색할대 이전처럼 도서관이나 서점을 가는 것이 아니라 컴퓨터 앞으로 향하고 있으며, 유용한 생활 정보의 대부분을 인터넷을 통해서 얻고 있다.

또한 컴퓨터를 이용한 업무 및 다양한 서비스도 기존의 C/S환경에서 탈피하여 최근에는 대부분이 웹 애플리케이션을 이용하여 개발하고 있는 실정이다.
 



0x03 웹 해킹으로의 전이

최근 대부분의 회사에서는 중요 시스템을 방화벽으로 외부와 격리 시키고 네트워크로 오가는 통신을 침입 탐지 시스템(IDS)등을 통하여 감시하고 있다. 이러한 변화는 원격접속 서비스인 Telnet, FTP 등등의 대부분의 서비스는 외부와 격리되었으며, 웹 서비스인 80번 포트만 외부에 공개하는 형태가 되어 방화벽에 개방되어 있는 웹 해킹의 시대가 도래되었다.
 


0x04 웹해킹 공격 대상

외부에 공개된 웹 서비스는 주요 공격의 대상이 되었으며 그림3과 같이 Web Server ,WAS, Web Application 등등이 주요 공격대상이 된다.



※ 추가자료
- WAS와 WEB Server의 설명과 차이점
   http://webhacking.tistory.com/3



0x05 웹 해킹의 공격 범위

웹 해킹으로 인해서 침해 당할 수 있는 범위는 1차적으로 해당 웹서버와 웹 애플리케이션 서버, 데이터베이스 서버 등으로 볼 수 있다. 2차적으로는 이들과 신뢰성을 맺고 있는 E-Mail 서버, 파일 서버 및 내부망에 연결된 업무용 PC 등이 피해를 입을 수 있다.




※ 참고사항

웹 애플리케이션 해킹 스터디를 위해서 현재 소장하고 있는 여러 도서와 그 동안의 경험과 경력을 바탕으로 가장 기초가되는 부분부터 점진적으로 하나하나 정리를 해가면서 이해하기 쉽도록 진행되니다.

대부분은 웹 해킹&보안 완벽가이드와 웹 해킹 패턴과 대응 도서를 참고해서 작성되며 그 외의 참고된 내용은 기입된 출처를 참고하시기 바랍니다.