Web Application Hacking

웹 애플리케이션은 데이터에 여러 가지 인코딩 스키마를 사용합니다. HTTP 프로토콜과 HTML 언어 모두 텍스트 기반으로 돼있고, 생소한 문자나 바이너리 데이터가 안전하게 사용하기 위해 여러가지 인코딩 스키마가 개발되었습니다. 때로는 웹 애플리케이션 취약점 분석을 위해서 인코딩 스키마를 사용해 데이터를 변경할 때가 있고 인코등 스키마를 조정해서 원래의 의도와 벗어난 오동작 유발이 가능합니다.



0x01 URL Encoding

URL 인코딩은 ASCII 코드에서 0x20~0x7e의 범위 안의 문자열을 %뒤에 2자리 16진수 붙여서 만든 값으로 표현한다..


URL 인코딩에서 +문자는 띄어 쓰기를 의미하며, %20과 동일하다.


URL 인코딩은 확장된 아스키 문자를 사용시에 문제가 발생하는 문자를 인코딩할때 사용됩니다.



0x02 Unicode Encoding

유니코드는 문자 인코딩의 표준으로 모든 시스템에서 사용이 가능하도록 디자인되어 있다. 유니코드는 다양한 인코딩 스키마를 사용하고 있으며 그 중 일부가 웹 애플리케이션에서 특수문자를 나타낼 때 쓰인다.

16비트 유니코드 인코딩은 URL인코딩과 비슷하게 동작되며 접두어로 %u를 가지고 16진수형태로 표현된다.




0x03 HTML Encoding

HTML 인코딩은 스크립트 내에서 문제를 일으킬 수 있는 문자들을 인코딩하는데 사용 된다.


모든 문자열은 ASCII 코드를 10진수로 표현한 HTML 인코딩 방법을 사용할 수 있다.

또는 ASCII 코드를 16진수(x로 시작)를 이용한 방법도 사용할 수 있다.

XSS 취약점 찾을 때 HTML 인코딩에 유의해야 한다.



0x04 Base64 Encoding

Base54 인코딩은 바이너리 데이터들을 ASCII 문자를 사용하여 테스트로 안적학게 표현하는 방법이다. Base64 인코딩은 이메일 첨부 파일들을 인코딩해서 SMTP를 통해 안전하게 정송하거나 HTTP 인증 승인을 할 경우 사용자 인증서를 인코딩 할 때 사용된다.

Base64는 3Byte(24bit)을 6Bit 크기의 4개의 그룹으로 나눈 후 가각에 대응 되는 64개의 ASCII로 변환을 하고 맨 마지막 부분이 남을 경우 =로 패딩을 한다. Base64 인코딩은 다음과 같이 출력 가능한 ASCII 문자들만을 포함한 문자 세트를 사용한다.


예시 The Web Application Hacker's Handbook



0x05 Hex Encoding

바이너리 데이터 전송할 때 ASCII문자들과 함께 곧 바로 Hex(16진법) 인코딩을 사용한다.

예시 N3015M

Base64와 Hex 인코딩은 데이터 형태로 보아 쉽게 인코딩 타입을 알 수 있기 때문에 잘 살펴보면 식별이 가능하다.


0x06 Encoding Tool

진단을 할때 인코딩 관련해서 유용하게 쓰는 툴입니다. 참고하시기 바랍니다.

웹 애플리케이션 기술 중 웹의 기능에 대한 내용으로 서버 측 기능, 클라이언트 측 기능, 상태와 세션에 대해서 알아본다.



0x01 서버 측 기능

예전에 개발된 WWW는 정적인 내용을 갖고 있었지만 최근에는 정적 자료도 많이 사용되지만 대부분의 자료는 동적인 형태로 사용자 들에게 제공된다. 즉, 사용자가 동적인 자료를 요청하면 서버는 해당 사용자의 요청을 서버 측 기능을 이용해서 처러하고, 각 사용자는 요청에 맞는 컨텐츠를 받는다.

동적인 컨텐츠는 서버에서 실행되는 스크립트나 다른 코드로 작동되며 이런한 스크립트는 컴퓨터 프로그램과 유사한 점을 가지고 잇는데, 예를 들어서 사용자로부터 다양한 입력을 요청받고, 요청에 해당되는 결과를 제공한다.

사용자가 동적인 자료를 요청할 때단순히 자료를의 복사뿐만 아니라 다양한 인자들도 함게 전송하는데 서버측 애플리케이션은 사용자가 전달한 다양한 인자들을 통해 사용자에게 맞는 컨텐츠는 제공한다. HTTP에서 애플리케이션에 파라메터(인자)를 보낼 때 사용하는 세가지 방법이다.



웹 애플리케이션은 다양한 기능을 사용자에게 제공하기 위해 다음과 같은 기술들을 이용한다.


그럼 일반적으로 사용자가 접할 수 있는 웹 애플리케이션 플랫폼과 언어에대해서 알아보자.


JAVA Flatform

자바 플래폼 엔터프라이즈 버전(이전의 J2EE)은 대규모 엔터프라이즈 애플리케이션을 다룰 때 표준으로 사용되었습니다. 자바 플랫폼은 선 마이크로시스템 사에서 개발했으며 멀티계층과 로드 밸런스 아키텍처에 최적화 됐고, 모듈 개발과 코드 재사용에 적합하며 윈도우, 리눅스, 솔라리스 등의 다양한 운영체제에서 사용할 수 있습니다.


주요 용어 설명

○ 엔트프라이즈 자바 빈(EJB)
자바에서 사용하고 있는 중요 소프트웨어 컴포넌트로, 애플리케이션 내에 비즈니스 기능에 대한 로직을 캡슐화 한다.

○ Plain Old Java Object(POJO)
보편적으로 사용하는 자바 객체로, EJB와 같은 특수한 객체와는 다르며, POJO는 EJB보다는 가볍고 간단하여 사용자 정의 객체를 이용하거나 다픈 프레임워크에서 사용된 객체를 나타낼 때 사용한다.

○ 자바 서블릿(Java Servlet)
애플리케이션 서버에 존재하는 객체로, 클라이언트 부터 HTTP 요청을 받고 응답하는 역활을 한다.

○ 자바 웹 컨테이너(Java web container)
자바 기반의 웹 애플리케이션의 실시간 환경을 제공해주는 플랫폼 엔진으로 자바 웹 컨테이너에는 아파치 톰캣, BEA, WebLogic, JBoss 등이 있다.


핵심 애플리케이션 기능에서 사용되는 컴포넌트

○ 권한 : JAAS, ACEGI
○ 표현 계층 : SiteMesh, Tapestry
○ 데이터베이스 객체에 관련한 매핑 : Hibernate
○ 로킹 : Log4J

공격하고 있는 애플리케이션에서사용되고 있는 오픈소스가 무엇인지 안다면 위에서 소개한 컴포넌트를 다운 받아서 코드 리뷰를 하거나 공격하는 곳에 설치할 수 있으며 핵심 애플리케이션에 사용되는 컴포넌트에서 취약점을 찾아 낸다면 더 많은 애플리케이션 공격에 이용될 수 있다.


ASP.NET

ASP.NET은 마이크로 소프트 사의 웹 애플리케이션 프레임워크로 자바 플랫폼의 직접적인 경쟁자이다. ASP.NET은 개발된지 얼마 되지 않았으나 자바로 개발된 애플리케이션 영역에서 점차 비중을 확대하고 있다.

ASP.NET은 가상 머신과 강력한 API 등을 제공하며 마이크로소프트의 닷넷 프레임워크를 사용한다. 따라서 ASP.NET 애플리케이션은 C#이나 VB.NET과 같은 닷넷 언어에서도 사용할 수 있다.

ASP.NET은 비주얼 스튜디오에서 제공하는 강력한 개발 도구와 최소한의 프로그래밍 기술만으로 웹 애플리케이션을 쉽게 개발할 수 있게 고안되어 었으며 또한 최소한의 노력으로도 크로스사이트 스크립팅과 같이 많이 알려진 웹 애플리케이션 취약점으로부터 보호한다. 하지만 소규모의 ASP.NET 애플리케이션은 대부분 보안에 대해 잘 알지 못하는 초보 개발자들에 의해서 만들어진다는 것이다.


PHP

PHP(Personal Home Page)는 개인적으로 시작한 작은 프로젝트 였으나 지금은 강력하고 거대한 프레임워크가 되었다. PHP는 LAMP라고 일컫는 다른 개방된 기술과 함께 사용되는데, LAMP는 리눅스(Linux), 아파치(Apache), MySQL, PHP를 말한다.

상당히 많은 오픈소스 애플리케이션과 컴포넌트가 PHP를 사용해서 개발되었으며 다음과 같다.

○ 게시판 : PHPBB, PHP-Nuke
○ 관리자 기능 : PHPMyAdmin
○ 웹메일 : squirrelMail, IlohaMail
○ 사진 갤러리 : Gallery
○ 쇼핑 카트 : osCommerce, ECW-Shop
○ 위키 : MediaWiKi, Wakka Wikki

PHP는 무료이고 사용하기도 쉬워 초보자들이 웹 애플리케이션을 만들 때 많이 사용된다. PHP 프레임워크의 설계와 초기화 설정은 뜻하지 않게 프로그래머의 코드에 보안 버그들을 넣기 쉽게 만들었다. 이런 요소들로 인해 PHP로 작성된 애플리케이션은 수많은 보안 취약점을 갖게 되었다. 이러한 취약점은 차후에 설명합니다.



0x02 클라이언트 측 기능

서버 측 애플리케이션은 사용자가 입력한 내용을 전달받고 결과를 사용자에게 전달하려면 클라이언트 측 사용자 인터페이스를 제공할 필요가 있다. 모드 웹 애플리케이션은 브라우져를 통해서 접근하기 때무에 클라이언트 측 사용자 인터페이스는 모두 일반적인 핵심 기술을 공유하고 있다.

클라이언트 측 기능 설명

○ HTML
웹 인터페이스를 마드는 데 중요한 핵심 기술이다. HTML은 태그를 기반으로 한 언어로, 브라우저 안의 문서 구조를 기술할 때 사용된다.

○ Hyperlink
사용자는 Hyperlink를 클릭해서 서버에게 다용한 요청을 보내며 여기에는 미리 만들어진 요청 인자를 포함하고 있다. 요청 인자는 데이터 항목으로 사용자에 의해 만들어지지 않으며 링크 내에 원하는 항목을 놓음으로써 사용자가 클릭할 때 서버로 전송하며 서버는 인자 값을 이용하여 요청한 컨텐츠를 사용자에게 제공한다.

○ Form
HTML 폼(form)은 사용자가 브라우저를 통해 원하는 입력 값을 넣을 수 있게 합니다.

<form action=”/secure/login.php?app=quotations” method=”post”>     username: <input type=”text” name=”username”><br>     password: <input type=”password” name=”password”>   <input type=”hidden” name=”redir” value=”/secure/home.php”>   <input type=”submit” name=”submit” value=”log in”>   </form>

사용자가 폼에 값을 입력한 다음 전송 버튼을 누르면 브라우저는 다음과 같은 요청을 만든다.

POST /secure/login.php?app=quotations HTTP/1.1   Host: wahh-app.com   Content-Type: application/x-www-form-urlencoded   Content-Length: 39   Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd   username=daf&password=foo&redir=/secure/home.php&submit=log+in

파라메터는 이름/값 쌍으로 메시지 body에 담겨 URL 쿼리 스트링과 같은 방법으로 나타난다. 폼 데이터는 보내는 다른 타입은 multipart/form-data가 있습니다. 이 방식은 Content-Type 헤더에 요청에 포함되는 매개변수 값을 나눌 때 사용하는 무작위 문자열도 함께 명시되어 있습니다.

POST /secure/login.php?app=quotations HTTP/1.1   Host: wahh-app.com   Content-Type: multipart/form-data; boundary=------------7d71385d0a1a   Content-Length: 369   Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd   ------------7d71385d0a1a   Content-Disposition: form-data; name=”username”   daf   ------------7d71385d0a1a   Content-Disposition: form-data; name=”password”   foo   ------------7d71385d0a1a   Content-Disposition: form-data; name=”redir”   /secure/home.php   ------------7d71385d0a1a   Content-Disposition: form-data; name=”submit”   log in   ------------7d71385d0a1a--

○ Java Script
자바스크립트는 비교적 간단하지만 HTML만으로는 부족한 웹 인터페이스를 쉽게 확장할 수 있게 도와주는 강력한 프로그래밍 언어이다. 자바스크립트는 다음과 같은 기능들을 수행할 수 있다.


자바스크립트의 눈부신 발전은 AJAX 기술을 사용할 때 기존의 데스크탑 애플리케이션들이 제공했던 것과 유사하게 매끄러운 느낌을 갖게 해준다. AJAX는 HTML페이지 내에서 동적인 HTTP 요청을 보내는 것을 포함하는데, 웹 페이지에 대한 전체적인 내용을 서버로부터 받지 않고 특정 부분에 대해 서버와 데이터를 교환하면서 해당되는 부분만 페이지를 업데이트하는 데 사용된다.

○ Thick Client Component
일부 웹 애플리케이션은 브라우저의 내장된 기능을 확장하기 위해 커스텀 바이너리 코드를 사용하는 다양한 클라이언트 기술을 사용한다. 이러한 컴포넌트들은 브라우저 프러그인 형태로 실행되거나 클라이언트 컴퓨터 자체에 설치돼서 실행될 수 있다. 웹 애플리케이션 취약점 분석할때 흔히 볼 수 있는 클라이언트 기술들은 다음과 같다.


위의 기술들에 대한 자세한 설명은 차후에 알아 보도록 하겠습니다.



0x03 상태와 세션

HTTP 프로토콜은 자체가 상태 기반이 아니기 때문에 대부분의 애플리케이션은 다양한 요청을 하는 각 사용자들을 재확인해서 각 요청에 알맞는 상태 데이터를 사용하게 됩니다. 이것은 일반적으로 사용자의 세션을 확인하는 토큰을 줌으로써 이뤄집니다. 이런 토큰들은 모든 요청 인자를 통해 전송될 수 있지만 대부분의 애플리케이션에서는 HTTP 쿠키를 사용합니다. 

세션에 대한 다양한 취약점이 발생하는데 차후에 알아 보도록 하겠습니다.

HTTP Status Code - 상태 코드 (1xx, 2xx, 3xx, 4xx, 5xx)

상태 코드 

위에서 언급한 서버의 응답에서 요청한 상태를 표시하는 세자리 숫자와 상태를 설명하는 짧은 문구를 포함하는 것을 다음과 같이 나눌 수 있다.

코드 범위	응답의 의미
100 ~ 199 200 ~ 299 300 ~ 399 400 ~ 499 500 ~ 599	정보  클라이언트의 요청이 성공적이다. 다른 동작이 더 필요해 클라이언트의 요청을 리다이렉트 했다. 클라이언트의 요청이 불완전하다. 서버오류

 

100 ~199 정보 응답 

100 Continue

     요청된 초기 부분은 접수되었고 클라이언트는 계속해서 요청할 수 있다.
101 Switching Protocols

     서버는 Upgrade 헤더 필드에 명시된 프로토콜로 교환하기 위한 클라이언트 요청에 따르고 있다.

 

200~299 클라이언트 요청의 성공 응답 

200-299의 범위에 있는 응답은 클라이언트의 요청이 성공적이었다는 것을 의미한다.

200 OK

     클라이언트의요청이성공적이였으며, 서버는요청한데이터를포함하여응답한다.
201 Created

     이 상태 코드는 새로운 URI가 만들어질 때마다 사용된다. 결과 코드와 함께 새로운 데이터가
     위치한 곳을 지정하기 위해 Location 헤더가 서버에 의해 주어진다.
202 Accepted

     요청은 받아들여 졌지만 즉시 실행되지는 않는다. 트랜잭션에 대한 심층 정보가 서버 응답의
     엔티티 몸체에서 주어지기도 한다. 주의할 점은 요청이 정당한 것처럼 보였을 수도 있지만
     서버가 요청을 실제로 승인하리라는 보장은 없다는 것이다.
203 Non-Authoritative Information

     엔티티 헤더에 있는 정보는 원래 서버가 아니라 로컬이나 다른 서버로부터 온다.
204 No Content

     이 코드는 응답할 때 주어지는 헤더이다. 그러나 응답된 실제 내용은 없다는 뜻이다.
     이런 응답을 받는 이유는 웹 브라우저가 문서를 보기 위해 갱신을 하지 않았기 때문이다.
     이미지맵에서 클라이언트가 이미지의 영역 중 사용하지 않거나 공백인 부분을 클릭했을 때를
     처리할 때 유용하다.
205 Reset Content

     웹 브라우저가 추가적인 입력을 위해 사용된 트랜잭션을 지우는 것이다. CGI 애플리케이션에서
     데이터를 입력받을 때 적합하다.
206 Partial Content

     서버가 요청된 크기의 부분 데이터를 반환하고 있다. Range 헤더 지정 요청에 응답하는 데
     이용된다. 서버는 반드시 Content-Range 헤더와 응답에 포함된 범위를 지정해야 한다.

 

300~399 리다이렉션 

300~399 범위에 있는 응답 코드는 요청이 수행되지 않았다는 것을 나타내며, 클라이언트는 요청을 성공시키기 위해 다른 행위가 필요하다는 것을 나타낸다.

300 Multiple Choices

     요청된 URI는 하나 이상의 리소스를 참조한다. 예를 들면, URI는 여러 개의 언어로 변환된 문서를
     참조할 수 있다. 서버에 의해 반환된 엔티티 몸체는 올바른 리소스를선택하는 방법에 대한 좀 더
     특정한 데이터의 목록을 가지고 있을수 있다.
301 Moved Permanently

     요청된 URI는 더 이상 사용되지 않으며 요청에서 지정한 연산은 수행되지 않았다.
     요청된 문서를 위한 새로운 위치는 Location 헤더에 명시한다. 앞으로 요청될 모든 문서는
     새로운 URI를 사용할 것이다.
302 Found

     요청된 URI는 일시적으로 새로운 URI를 가진다. Location 헤더는 새로운 장소를 가리킨다.
     만일 이것이 GET이나 HEAD 메소드에 대한 응답이라면 클라이언트는 응답을 받자마자 요청을
     해결하기 위해 새로운 URI를 사용해야 한다.
303 See Other

     요청된 URI는 다른 URI(Location 헤더에 명시한)에서 찾을 수 있으며, 리소스는 GET 메소드로
     구할 수 있다.
304 Not Modified

     이것은 If-Modified-Since 헤더에 대한 응답 코드로써 지정한 날짜 이래로 수정되지 않았다.
     엔티티 몸체는 보내지 않으며, 클라이언트는 자신의 로컬 사본을 사용해야 한다.
305 Use Proxy

     요청된 URI는 Location 헤더에 있는 프록시를 통해서만 접근할 수 있다.
307 Temporary Redirect

     요청된 URI가 일시적으로 옮겨졌다. Location 헤더가 새로운 장소를 가리킨다. 이 상태 코드를
     받는 즉시, 클라이언트는 요청을 해결하기 위해 새로운 URI를 사용해야 하지만, 앞으로 모든
     요청들은 이전의 URI를 사용할 것이다.

 

400~499 클라이언트 요청의 불안전 응답 

400~499 범위에 있는 응답 코드는 클라이언트의 요청이 불안전하며, 클라이언트가 요청을 성공시키려면 다른 정보가 필요하다는 것을 나타낸다.

400 Bad Request

     이 응답 코드는 클라이언트의 요청에 문법적인 오류가 있는 것을 서버가 알아냈다는 것을
     의미한다.
401 Unauthorized

     이 결과 코드는 WWW-Authenticate 헤더와 함께 그 요청에 적당한 권한이 부족했다는 것을
     나타내기 위해 주어지며, 이 URI를 다시 요구하면 클라이언트는 적당한 권한으로 접속해야 한다.
402 Payment Required

     이 코드는 아직 HTTP로 구현되지 않았다. 하지만 언젠가는 서버의 문서를 받아 보기 위해
     지불이 필요하다는 것을 나타낸다.
403 Forbidden

     이 요청은 서버가 클라이언트를 가리키고 싶어하지 않아(또는 아무 이유 없이) 거부되었다.
404 Not Found

     지정한 URI에 문서가 존재하지 않는다.
405 Method Not Allowed

     이 코드는 Allow 헤더와 함께 클라이언트가 사용한 메소드가 이 URI에 대해 지원되지 않는다는
     의미이다.
406 Not Acceptable

     클라이언트가 지정한 URI는 존재하지만 클라이언트가 원하는 형식이 아니다. 이 코드와 함께
     서버는 Content-Language, Content-Encoding, 그리고 Content-Type 헤더를 제공한다.
407 Proxy Authentication Required

     프록시 서버는 요청된 문서를 보여주기 전에 권한을 필요로 한다. Proxy-Authenticate헤더와
     함께 사용한다.
408 Request Time-out

     이 응답 코드는 클라이언트의 모든 요청이 지정한 시간(일반적으로 서버의 구성할때 명시한다)
     동안 처리되지 않았음을 뜻하며, 서버는 네트워크 연결을 끊는다.
409 Conflict
     이 코드는 다른 요청이나 서버의 구성과 충돌이 있음을 나타낸다. 충돌에대한 정보는 응답되는
     데이터의 일부로 반환된다.
410 Gone

     이 코드는 요청된 URI가 더 이상 존재하지 않고, 서버에서 완전히 사라졌음을 나타낸다.
411 Length Required

     서버는Content-Length 헤더가 없는 요청을 받아들이지 않는다.
412 Precondition Failed

     하나 이상의 If…헤더에 의해 명시된 조건에 의해 요청을 평가하여 false 값을 가지는 경우이다.
413 Request Entity Too Large
     서버는 실제 본문이 너무 커서 요청을 처리할 수 없다.
414 Request-URI Too Long
     서버는 요청된 URI가 너무 커서 요청을 처리할 수 없다.
415 Unsupported Media Type
     서버는 실제 본문이 지원되는 않는 형식이라 처리할 수 없다.
416 Requested Range Not Satisfiable
     서버는 목표에 대해 어떤 유효한 값도 포함하지 않은 Range 헤더를 찾아냈다.
     추가로 If-Range 헤더는 없어졌다.
417 Expectation Failed
     Expect 헤더에서 명시된 조건은 만족될 수 없다.

 

500~599서버 오류 

500~599 범위에 있는 응답 코드는 서버가 오류를 만나거나, 클라이언트의 요청을 수행할 수 없음을 나타낸다.

500 Internal Server Error
     이 코드는 서버의 일부(예를 들면, CGI 프로그램)가 멈추었거나 설정에서 오류가 났음을
     나타낸다.
501 Not Implemented
     이 코드는 클라이언트의 요청된 행위가 서버에서 수행할 수 없음을 나타낸다.
502 Bad Gateway
     이 코드는 서버(또는 프록시)가 다른 서버(또는 프록시)로부터의 응답이 적절하지 않음을
     나타낸다.
503 Service Unavailable
     이 코드는 서비스를 일시적으로 제공할 수 없으나, 앞으로 복구된다는 의미이다.
     만일 서버가 복구될 때를 알기 위해서는 Retry-After 헤더도 함께 제공해야 한다.

504 Gateway Time-out
     이 응답은 게이트웨이나 프록시의 시간이 경과했다는 것만 빼고는 408(Request Time-out)과
     같다.
505 HTTP Version not supported
     서버가 요청에 사용된HTTP 프로토콜 버전을 지원하지 않는다.

※ 출처 URL : http://r00tdj.tistory.com/1