[SWING] Web Hacking 03

웹 리소스 / 웹 구성요소

 

웹 클라이언트 (Web Client)

웹을 사용하는 고객으로 필요한 데이터를 웹 서버에 요청(request)하는 주체이다.

 

HTTP (Hyper Text Transfer Protocol)

웹에서 브라우저와 서버 간에 데이터를 주고 받는 약속, 즉 프로토콜이다.

OSI 7계층에서 7계층인 응용 계층 (Aplication)에 해당한다.

사용자와 가장 밀접하며 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행하는 프로토콜 중 하나이다.

암호화되지 않은 평문을 전송하기 때문에 모니터링만 하면 정보를 탈취할 수 있어 sniffing 공격에 취약하다.

 

웹 브라우저 (Web Browser)

클라이언트의 요청을 받아 request를 웹 서버에 전달하고,

웹 서버로부터 응답받은 response를 해석하여 사용자에게 보여주는 소프트웨어(Tool)이다.

FireFox, Chrome, Safari 등이 그 예이다.

 

웹 서버 (Web Server)

클라이언트의 요청에 따라 HTML 문서를 클라이언트에게 제공해주는 주체로 웹 리소스를 관리하고 제공한다.

 

웹 어플리케이션 (Web Aplication)

브라우저를 통해 접근할 수 있는 응용 프로그램으로 HTTP에서 동작한다.

jsp, php 등이 그 예이다.

 

 텍스트 파일, html 파일, 워드, JPEG 이미지 파일 등의 정적 파일이 될 수도 있고

주식 거래, 인터넷 검색 엔진 등 요청에 따라 콘텐츠를 생산하는 프로그램도 모두 리소스(동적 컨텐츠 리소스)가 될 수 있다.

 

URI는 서버 리소스의 이름이다.

웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다.

정보 리소스를 고유하게 식별하고 위치를 저장할 수 있다.

URL가 URI에 포함되는 개념이다.

 

URL은 리소스 식별자의 가장 흔한 형태로 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다.

가령 https://www.swu.ac.kr/www/futured_1.html 이라는 url이 있다면 의미하는 바는 다음과 같다.

 

https:// -> HTTP 프로토콜 사용

www.swu.ac.kr/ -> 해당 주소로 이동

www/futured_1.html -> 해당 리소스를 가져와라

 

정적 파일	텍스트, HTML, 워드, 아크로벳, 이미지
	서버에 미리 저장된 파일이 그대로 전달되는 웹 페이지
	사용자는 서버에 저장된 데이터가 변경되지 않는 한 고정된 웹 페이지를 보게 됨
동적 파일	리소스 사용자가 누구인지, 어떠한 정보를 요청했는지에 따라 다른 컨텐츠 생성
	라이브 영상을 보여주거나, 주식 거래 등 사용자에게 정보를 제공
	서버는 사용자의 요청을 해석하여 데이터가 웹 페이지로 이동하는 것을 클라이언트에게 보여줌

 

CSRF

 

Cross-Site Request Forgery - 사이트 간 요청 위조
사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격.

 

임의 이용자의 권한으로 임의 주소에 HTTP 요청을 보낼 수 있는 취약점을 의미한다.

특정 웹 페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법이다.

 

CSRF 공격을 시도하기 위해선 아래와 같은 몇 가지 조건이 필요하다.

• 사용자가 보안이 취약한 서버로부터 이미 인증을 받은 상태여야 한다.
• 쿠키 기반으로 서버 세션 정보를 획득할 수 있어야 한다.
• 공격자는 서버를 공격하기 위한 요청 방법에 대해 미리 파악하고 있어야 한다. 예상치 못한 파라미터가 있으면 불가능하다.

조건이 만족되면 다음과 같은 과정을 통해 CSRF 공격이 수행되는데,

공격방식은 다음과 같다.

 

0. CSRF 공격 스크립트를 작성한다. HTML 또는 Javascript로 작성하며 이미지 태그나 폼 태그로 많이 사용한다.

1. 사용자가 웹 사이트 로그인 시 서버에 저장된 세션 정보를 사용할 수 있는 session ID 가 사용자 브라우저 쿠키에 저장된다.

2. 공격자가 CSRF 스크립트가 포함된 게시물을 취약한 웹 사이트에 등록한다. 

3. 사용자가 스크립트가 포함된 게시물을 열람한다.

4. 사용자의 로그인 자격 증명, 쿠키 등의 정보가 공격자에게 전송된다. 브라우저가 쿠키에 담긴 session ID를 서버에 요청하는데 서버는 이 요청이 사용자로부터 온 것으로 판단했기 때문이다.

 

 

방어기법은 다음과 같다.

 

Referrer 체크

HTTP 헤더에 있는 Referrer로 해당 요청이 요청된 페이지의 정보를 확인하는 방법이다.

document.referrer

 

Token 사용

서버에 hash로 암호화된 token을 발급받고,

사용자는 매 요청마다 token을 함께 보내어 서버의 검증을 거친다.

 

Double Submit Cookie 검증

브라우저의 Same Origin 정책을 이용한 것으로 Same Origin이 아닌 경우 쿠키 값을 확인하거나 수정하지 못한다. 클라이언트(브라우저)에서 JavaScript로 임의의 생성한 토큰을 쿠키와 요청 헤더에 각각 담아서 서버에게 전달한다. 서버는 전달받은 쿠키와 요청 헤더에서 각자 토큰 값을 꺼내어 이를 비교한다. 이때, 쿠키에 저장된 토큰 정보는 이후에 재사용하지 못하도록 만료 처리한다.

 

 

XSS와 CSRF는 이용자가 악성 스크립트가 포함된 페이지에 접속하도록 유도한다는 공통점이 있다.

그러나 XSS는 세션 및 쿠키를 탈취하는 것을 목적으로 하여 클라이언트를 공격하고,

CSRF는 임의 페이지에 HTTP 요청을 보낼 목적으로 서버를 공격한다.

 

SSRF

 

Server Side Request Forgery - 서버 측 요청 위조.

 

CSRF가 클라이언트 측에서 위조된 요청을 보내는, 즉 하이재킹을 통해 공격자가 사용자의 웹 브라우저로 무단 작업을 하도록 한다면,

SSRF는 서버(웹 서비스) 측에서 위조된 요청을 보내도록 하는 취약점(서버 공격)이다.

공격자는 악성 HTTP 요청을 서버에 보내는 것만으로 백엔드에 지시해 악성 작업을 수행할 수 있기 때문에 더 위험하다.

공격방법은 다음과 같다.

 

A, B, C 서버가 내부망에 있고 정상적인 경우에 A서버가 B서버로 정상적인 요청을 보내고 결과를 반환받아야 한다면,

공격자가 B서버의 주소를 C서버로 바꿔버렸을 때,

A서버는 C서버로 비정상적인 요청을 보내고,

공격자는 외부망에서 C서버를 통해 A서버에 대한 정보를 얻을 수 있다.

 

 

방문자가 웹 서버에 요청하거나 하이퍼링크를 클릭하면 방문자에게는 공개된 파일, 즉 public_html이나 www 폴더에 있는 파일이 제공된다. 비공개 폴더 또는 데이터베이스에 있는 파일은 일반적으로 서버 관리자와 같이 더 높은 권한이 있는 사람만 접근하도록 제한된다.
그러나 웹을 서핑하는 일반 사용자가 직접 접근할 수 있는 파일과 자산을 서버 자체가 접근할 수 있다. 예를 들어 방문자는 공개 URL을 손쉽게 요청할 수 있지만 '/etc/shadow' 또는 '/etc/passwd'와 같은 CSO 서버의 민감한 시스템 파일은 요청할 수 없다. 웹 서버는 이런 파일에 접근할 수 있을 가능성이 높다.

모든 SSRF 공격의 기본은 공개적으로 접근 가능한 웹 서버가 최종 사용자에게 속아 해당 서버에 있는 민감한 파일, 또는 원래 최종 사용자 접근이 제한되어야 할 시스템이나 작업에 대한 접근 권한을 제공할 수 있다는 데 착안한다.

논블라인드 방식과 블라인드 방식으로 구분할 수 있다.

공격자가 악의적 요청을 하고 그 결과 서버가 반환되는 데이터가 노출되는 기초적인 논블라인드(non-blind) 방식은 기밀 파일 및 자산에서 데이터를 빼내거나 특정 시스템 포트가 열려 있고 서비스를 실행 중인지 여부를 확인하고자 하는 위협 행위자에게 매우 효과적이다.

반면 블라인드(Blind) SSRF 공격은 반드시 데이터를 반환하는 것은 아니며, 그 대신 서버 백엔드에 무단 작업을 수행하는데 초점을 둔다. 블라인드 SSRF 공격에서 공격자는 데이터 유출보다는 예를 들어 서버의 무언가를 변경하거나, 파일을 수정 또는 삭제하거나 권한을 바꾸거나 그 외의 다양한 무단 작업을 실행하는데 초점을 두고 있다.

 

SSRF는 기능별로 서버를 분리하여 구축하거나 데이터를 가공해서 전달하는 경우 많이 발생된다.

 

SSRF에 취약한 대표 서비스의 종류는 다음과 같다.

 

Web Transfer

Image Viewer()

Document Reader

Web Crawler

URL Previewer

 

예방하는 방법은 다음과 같다.

 

- 내부 시스템과 상호 작용하는 변수에 불필요한 값이 입력될 경우 무효처리를 해야 된다.

- 변수에 입력된 주소가 올바른 주소가 맞는지 즉 신뢰하는 주소가 맞는지 재검증을 해야 한다.

- 여러 우회 공격 기법 중에 대상 사이트에 대한 신뢰할 수 있는 도메인과 루프백 주소를 매칭하여 지정해둔 도메인을 요청하는 경우가 존재하기 때문에 요청 시 도메인 이름에 대한 검증도 수행하는 것이 좋다.

 

입력 데이터에 대해 전체 URL을 입력받을 필요가 없다면 사용자로부터 입력을 최소로 받을 수 있도록 한다.

그리고 어쩔 수 없이 URL을 입력받아야 할 경우 입력값에 대한 검증을 철저히 한다.

 

- 입력값을 블랙리스트 방식으로 필터링한다. 서버 내부에서 접근해선 안 되는 값들을 필터링하거나 127.0.0.1, localhost, 사설 IP 대역 등을 필터링할 수 있다. 주의해야 할 점은 필터링할 때 우회 가능한 값들도 같이 필터링을 해야 한다. 대소문자를 구분하지 않는다거나 16진수, 8진수, 123.123.123, 1과 같은 값들을 함께 필터링하는 등 우회 지점들을 신경 써야 한다.
- 입력값을 화이트리스트 방식으로 필터링한다. 허용된 도메인과 URL에 대해서만 허용을 하도록 한다. 가장 안전할 수 있는 방법이지만 서비스에 제약이 생기고 필터링 시 예외처리의 미흡으로 우회가 될 수 있음에 주의한다. 
- URL 검사할 때 단순히 문자열 포함여부를 검사하지 않고 정규식을 활용하며 정확히 host domain을 검사하도록 하고 @나 #기호를 이용해 우회할 수 없도록 기능을 막거나 필터링을 해야한다. 
- 서버 내부 정보나 내부 네트워크의 정보가 빠져나가지 않도록 비록 내부 네트워크에서의 접근이라도 중요한 데이터일 경우 추가 인증을 받도록 해서 SSRF 취약점이 있어도 피해가 발생하지 않도록 한다.
- 요청을 처리하는 서버와 중요 정보가 있는 내부망을 분리시키는 것도 좋은 방법이다. 
- 요청한 URL에 대한 응답 값이 예상한 값인지를(응답이 이미지인지 동영상인지 등) 검사할 수도 있다. 하지만 이 경우 404, 403과 같은 에러코드가 응답되면서 서버 내부 ip 혹은 포트스캔에 이용될 수 있으니 URL에 대한 추가적인 필터링이 필요하다.
- http나 https를 제외하고 사용하지 않는 URI scheme은 비활성화하거나 필터링한다.