04장 웹 보안: 웹, 그 무한한 가능성과 함께 성장한 해킹
01. 웹의 이해 02. HTTP의 이해 03. 웹 서비스의 이해 04. 웹 해킹의 이해 05. 웹 취약점의 이해
▶ HTTP 프로토콜의 동작 원리를 이해한다. ▶ 구글과 같은 검색 엔진을 통해 정보를 수집하는 방법을 알아본다. ▶ 웹 해킹에서 파일 접근과 관련된 공격을 살펴본다. ▶ 리버스 텔넷을 이해한다. ▶ 웹에서의 인증 구조와 이를 우회하는 방법을 알아본다. ▶ 패킷 변조를 통해 가능한 공격을 살펴본다. ▶ XSS 공격과 SQL 삽입 공격을 살펴본다.
01. 웹의 이해 네트워크와 웹 인터넷의 시작 프로토콜 1969년 미국 ARPA(Advanced Research Projects Agency)가 전 세계 주요 거점을 연결 하는 네트워크를 처음 만들고 이 네트워크를 알파넷이라 부름. 흔히 알파넷을 인터넷 의 시작이라고 함. 프로토콜 처음에는 대학 내 각 연구실 사이에 데이터를 전송하려고 시스템 간의 통신을 위한 프 로토콜을 만들어 사용. 프로토콜이 늘어나자 하나의 프로토콜을 해석한 후 다른 프로토콜로 바꾸어 다른 시스 템으로 전송하는 게이트웨이(gateway)가 개발되었고 이후에야 원격의 두 지점 간 통신 가능.
01. 웹의 이해 네트워크와 웹 웹 웹의 정식 명칭은 월드 와이드 웹(World Wide Web, WWW), 세계 규모의 거미집 또는 거미집 모양의 망이라는 뜻. 1989년 스위스 제네바 유럽입자물리연구소(CERN)의 팀 버너스 리(Tim Berners Lee)가 연구 목적 프로젝트로 시작. 처음에는 웹을 하이퍼텍스트 프로젝트(Hyper Text Project)라고 부름. 현재 웹 문서로 가장 많이 쓰이는 HTML(Hyper Text Markup Language)은 하이퍼텍스트를 효과적으로 전달하기 위한 스크립트 언어. 하이퍼텍스트: 1960년대 테드 넬슨(Ted Nelson)이 만든 신조어로, 다른 문서와 연관 관계를 가진 텍스트를 의미함. 웹 브라우저 웹에 접근하려면 웹 브라우저가 필요. 마이크로소프트의 인터넷 익스플로러, 구글의 크롬, 애플의 사파리, 모질라재단의 파이 어폭스 등 다양하게 사용. NCSA에서 개발한 최초의 웹 브라우저인 모자이크는 글자 위에서 마우스 버튼을 클릭 할 수 있는 하이퍼링크(hyperlink)가 처음 구현된 웹 브라우저임.
02. HTTP의 이해 HTTP 프로토콜 HTTP(Hyper Text Transfer Protocol): 웹에서 흔히 쓰이는 프로토콜로 다양한 응용 프로 그램에 접근하여 텍스트, 그래픽, 애니메이션을 보거나 사운드 재생 가능. 웹 서버는 HTTP 서비스를 제공. HTTP는 0.9 버전부터 사용되었으며 서버로부터의 단순 읽기 기능만 지원했음. HTTP 0.9는 하나의 웹 페이지 안에서도 텍스트와 그림이 반복적으로 Connect 과정을 거치느라 비효율적이어서 오래 사용되지 못함. 현재 인터넷에서 사용되는 대부분의 HTTP는 1.0과 1.1 버전. 1.1 버전부터 한 번의 Connect 과정 후에 Request와 Response를 반복할 수 있음. [그림 4-2] HTTP 0.9 버전의 기본 연결 [그림 4-3] HTTP 1.0 버전의 기본 연결
02. HTTP의 이해 HTTP Request (정보 요청) Get 방식 POST 방식 가장 일반적인 HTTP Request 형태로, 요청 데이터의 인수를 웹 브라우저의 URL을 통 해 전송함. 데이터가 주소 입력란에 표시되므로 최소한의 보안도 유지되지 않는 취약한 방식. POST 방식 URL에 요청 데이터를 기록하지 않고 HTTP 헤더에 데이터를 전송. 인수값을 URL로 전송하지 않으므로 다른 사용자가 링크로 해당 페이지를 볼 수 없음. 게시판의 경우, 목록이나 글 보기 화면은 접근 자유도를 위해 GET 방식을 사용, 게시글 을 저장·수정·삭제하거나 대용량 데이터를 전송할 때는 POST 방식을 사용. 기타 방식 HEAD 방식: 서버 측 데이터를 검색하고 요청하는 데 사용. OPTIONS 방식: 자원에 대한 요구/응답 관계와 관련된 선택 사항 정보를 요청할 때 사용. PUT 방식: 메시지에 포함된 데이터를 지정된 URI(Uniform Resource Identifier) 장소에 그 이름으로 저장. DELETE 방식: URI에 지정된 자원을 서버에서 지울 수 있게 함. TRACE 방식: 요구 메시지의 최종 수신처까지 루프백을 검사하는 데 사용.
02. HTTP의 이해 Get 방식 Post 방식
02. HTTP의 이해 HTTP Response 클라이언트의 HTTP Request에 대한 응답 패킷 서버에서 쓰이는 프로토콜 버전, Request에 대한 실행 결과 코드, 간략한 실행 결과 설 명문(OK 등) 내용이 담겨 있음. 추가 정보로 전달할 데이터 형식, 길이 등이 MIME 형식으로 표현되어 있으며 헤더 정 보 뒤에는 실제 데이터(HTML 또는 이미지 파일)가 전달됨. 데이터 전달이 끝나면 서버 연결을 끊음. HTTP Response의 주요 실행 결과 코드
HTTP Request HTTP Response
03. 웹 서비스의 이해 HTML 가장 단순한 형태의 웹 언어. 웹 서버에 HTML 문서를 저장하고 있다가 클라이언트가 요청하면 해당 페이지를 전송함. 클라이언트는 웹 페이지 해석 후 웹 브라우저로 나타 내는데, 이를 정적인 웹 페이지라고 함. 정적인 웹 페이지는 변화를 반영하거나 새로운 것을 추가하기에 많은 시간이 걸린다는 것이 단점. 웹 브라우저와 웹 서버 사이에 전달되는 값을 변조하여 웹 서버 설정이나 로직을 바꾸 는 웹 해킹에서 정적인 웹 페이지는 바꿀 수 있는 가능성이 매우 낮다는 것이 보안상 장점. [그림 4-4] 정적인 웹 페이지 접근 시 웹 문서 전송
03. 웹 서비스의 이해 SSS 기능상 한계가 많은 정적인 웹 페이지 대신에 좀 더 동적인 웹 페이지를 제공할 수 있 는 PHP, ASP, JSP 등의 언어 개발. 이처럼 동적인 페이지를 제공하는 스크립트를 SSS(Server Side Script)라고 함. 동적인 웹 페이지에서는 스크립트에 HTML 대신 ASP나 JSP 확장자를 가진 웹 문서를 요청. ASP는 DLL, OCX 등의 파일을 이용, JSP는 서블릿을 이용하여 요청을 처리한 뒤 결과를 HTML 파일로 만들어서 클라이언트로 전송. [그림 4-5] 동적인 웹 페이지 접근 시 웹 문서 전송
03. 웹 서비스의 이해 CSS 웹 서비스에 사용되는 스크립트로, 클라이언트 측의 웹 브라우저에 의해 해석 및 적용 되어 CSS(Client Side Script)라고 함. 서버가 아닌 웹 브라우저에서 해석되어 화면에 적용되므로 웹 서버의 부담을 줄이면서 다양한 기능을 수행할 수 있음. [그림 4-6] CSS로 만든 웹 페이지 접근 시 클라이언트의 동작
SSS(Server Side Script) CSS(Client Side Script)
04. 웹 해킹의 이해 웹 취약점 스캐너를 통한 정보 수집 빠른 시간 내에 다양한 접속 시도를 수행할 수 있다는 것이 장점. 웹 취약점 스캐너로 발견된 취약점은 개별 확인 과정을 거쳐 유효성을 파악하는 것이 필요함. 웹 정보를 수집할 때 사용하는 웹 취약점 스캐너 https://www.acunetix.com/vulnerability-scanner/ [그림 4-7] 웹 취약점 스캐너인 Acunetix
04. 웹 해킹의 이해 OWASP Zed Attack Proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 웹의 구조 파악, 취약점 점검, 웹 해킹에는 웹 프록시(web proxy) 툴을 사용. 웹 해킹에 사용하는 웹 프록시는 클라이언트에 설치하여 클라이언트의 통제를 받으므 로 클라이언트가 웹 서버와 웹 브라우저 간에 전달되는 모든 HTTP 패킷을 웹 프록시 로 확인 및 수정 가능. 웹 프록시 툴로 사용할 Burp Suite는 http://portswigger.net/burp/에서 무료 내려받기 Burp Suite에서 주로 사용할 메뉴는 [Proxy] 탭 [그림 4-9] Burp Suite 실행 창
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 클라이언트의 웹 브라우저 패킷이 웹 프록시로 향하도록 설정해야 함. 윈도우 10은 [시작]-[설정]-[네트워크 및 인터넷]-[프록시]에서 설정. 인터넷 익스플로러 EDGE가 아닌 인터넷 익스플로러를 사용하는 운영체제라면 인터넷 익스플로러의 [도구]-[인터넷 옵션]에서 [LAN 설정] 항목을 선택하여 설정. LAN 설정에서 주소와 포트의 값 설정. 주소 값은 루프백(loopback) 주소로 시스템 자 신을 의미하고 포트 값은 웹 프록시 프로그램의 서비스 포트로 프로그램마다 다름. [그림 4-10] 웹 프록시의 설정
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 설정 후 웹 서버와 클라이언트 간에 전송되는 HTTP 패킷 확인. ‘intercept is on’ 상태에서 패킷을 살펴본 뒤 그대로 전송하거나 화면 아래의 창에서 패킷 내용을 변경 후 전송할 수도 있음. [그림 4-11] 웹 프록시를 통한 HTTP 확인
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 서버에서 클라이언트로 전송되는 패킷 변조 테스트 환경으로 사용하는 웹 페이지 게시판에서 글 하나에 대한 열람 시도 ‘테스트 1입니다.’라는 제목 클릭하여 내용 확인 [그림 4-12] 문서 목록 [그림 4-13] 문서의 열람 내용
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 서버에서 클라이언트로 전송되는 패킷 변조 서버에서 클라이언트로 전송되는 과정의 패킷을 변조하여 다르게 출력되도록 테스트. 인터넷 익스플로러에 프록시 설정, 웹 프록시(Burf Suite) [Proxy]-[Intercept]의 ‘intercept is off ’를 클릭하여 ‘intercept is on’ 상태로 바꿈. 서버에서 클라이언트로 보내는 패킷을 확인하기 위해 [Proxy]-[Options]에서 ‘Intercept responses based on the following rules’에 체크 표시하여 패킷 규칙 설정. 책에서는 URL을 기준으로 서버 응답을 가로채도록 설정. URL이 test인 것은 host 파일에 test 서버의 IP를 등록했기 때문. [그림 4-14] test 서버에서 오는 패킷을 캡처하도록 설정
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 서버에서 클라이언트로 전송되는 패킷 변조 다시 글 내용을 조회하기 위해 해당 글을 클릭하면 서버가 클라이언트로 보내는 응답 패킷에서 해당 글의 본문이 전달되는 것을 확인 [그림 4-15] ‘테스트 1입니다.’ 조회 시 서버에서 전달되는 패킷
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 서버에서 클라이언트로 전송되는 패킷 변조 ‘테스트 1의 본문입니다.’에서 1을 2로 변조 [그림 4-16] 웹 프록시를 통해 본문 내용 변조
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 서버에서 클라이언트로 전송되는 패킷 변조 전송(forward), 변조된 글 확인 [그림 4-16] 변조된 ‘테스트 1입니다.’의 내용
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 서버에서 클라이언트로 전송되는 패킷 변조 이러한 공격이 위력을 가지는 경우 ① 해킹 대상이 클라이언트에 있는 경우에는 다양한 웹 서비스 변조 가능. ② 서버에서 클라이언트에 정보 전송 후 다시 전송받아 처리하는 경우에 변조 가능. [그림 4-18] 클라이언트에 전송한 변수값을 서버가 참조 [그림 4-19] 변조하여 클라이언트에 전송한 변수값을 서버가 참조
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 클라이언트에서 서버로 전송되는 패킷 변조 서버에서 클라이언트로 전송되는 패킷을 변조하는 방법과 클라이언트에서 서버로 전 송되는 패킷을 변조하는 방법은 기본적으로 동일. HTTP 패킷을 웹 프록시에서 확인해보면 해당 글에 대한 인수값(2)이 URL의 형태로 전 달됨. GET을 통해 게시판의 두 번째 글을 보여줄 것을 서버에 요청. ‘/bord/read/2’에서 2를 1로 바꿔 전송 [그림 4-21] 서버에서 클라이언트로 전송되는 패킷
04. 웹 해킹의 이해 웹 프록시를 통한 취약점 분석 클라이언트에서 서버로 전송되는 패킷 변조 패킷을 보내면 1번 글이 다음 그림과 같이 조회되는 것을 확인 클라이언트에서 서버로 전송되는 패킷을 변조하는 것은 일반적인 웹 서비스 메뉴로 접 속할 수 없는 것에 접근하거나, 특정한 값을 넣어 시스템의 오작동을 유도하려는 목적 으로 사용됨. [그림 4-22] 변경된 본문 내용
04. 웹 해킹의 이해 구글 해킹을 통한 정보 수집 구글의 고급 검색 기능
04. 웹 해킹의 이해 구글 해킹을 통한 정보 수집 주요 검색 인자 site 특정 사이트만을 집중적으로 선정해서 검색할 때 유용. 예) ‘wishfree.com’도메인이 있는 페이지에서 ‘admin’ 문자열 찾기 filetype 특정 파일 유형을 검색할 때 사용. 예) 파일 확장자가 txt이고 문자열 password가 들어간 파일 검색하기 intitle 디렉터리 리스팅 취약점이 존재하는 사이트를 쉽게 찾을 수 있어 정보 수집 시 유용. 예) 수많은 사이트의 디렉터리 리스팅 확인하기
04. 웹 해킹의 이해 구글 해킹을 통한 정보 수집 검색 엔진의 검색을 피하는 방법 가장 일반적인 대응법은 웹 서버의 홈 디렉터리에 ‘robots.txt’ 파일을 만들어 검색할 수 없게 만드는 것. robots.txt 파일 형식: 2개의 필드로 구성. User-agent 와 Disallow를 이용. User-agent는 검색 엔진의 검색을 막고, Disallow는 특정 파일이나 디렉터리를 로봇이 검색하지 못하게 함.
05. 웹 취약점의 이해 웹의 주요 취약점 국제웹보안표준기구(The Open Web Application Security Project, OWASP)에서 각 분 야별 상위 열 가지 주요 취약점을 발표 [그림 4-22] OWASP 사이트
05. 웹 취약점의 이해 웹의 주요 취약점 명령 삽입 취약점(A1. Injection) 전송받는 인수에 포함된, 특정 명령을 실행하는 코드를 적절히 필터링하지 못하면 삽 입 공격에 대한 취약점이 발생. 명령 삽입 공격은 SQL, OS, LDAP 등 웹으로 명령을 전달하는 모든 경우에 적용 가능. 웹 서버에서 데이터베이스로 전송되는 SQL 쿼리에는 아이디, 패스워드, 검색어 등 여 러 가지 인수가 사용됨. SQL 삽입 공격은 이 인수에 추가 실행 코드를 넣는 것. 이 책에서는 가장 일반적인 SQL 명령 삽입 공격을 설명하기 위해 데이터베이스로 SQLite, 클라이언트로 DBeaver 툴을 사용함. SQL 삽입 공격을 이해하기 위한 간단한 SQL문: user 테이블의 정보 확인
05. 웹 취약점의 이해 웹의 주요 취약점 명령 삽입 취약점(A1. Injection) 특정 사용자에 대한 아이디 목록을 조회할 때 사용하는 명령어 웹에서 사용자가 아이디(이메일 주소)와 패스워드를 입력하면 다음과 같은 SQL문이 작성되어 데이터베이스로 전송됨. 입력된 아이디, 패스워드와 동일한 계정이 있으면 결과 창에 계정 정보가 출력됨. 잘못된 패스워드를 입력하면 아무 결과도 출력되지 않음.
05. 웹 취약점의 이해 웹의 주요 취약점 명령 삽입 취약점(A1. Injection) 공격자가 로그인에 성공하려면 SQL의 결과 값에 NULL이 나오지 않고 출력 값이 나오 게 하면 됨. SQL문에서 where로 입력되는 조건문을 항상 참으로 만들기 위해 조건 값에 ‘or’‘=’를 입력. 위와 같은 쿼리문이 만들어지면 조건문인 WHERE문에서 password 부분은 or 조건으 로 항상 만족되므로 공격자는 사용자 인증에 성공. SQL 삽입 공격은 웹에서 사용자의 입력 값을 받아 데이터베이스에 SQL문으로 데이터 를 요청하는 모든 곳에 가능하고, 인증뿐만 아니라 다양한 형태의 SQL문을 실행할 수 있음. 게시판, 우편번호 검색처럼 대량의 정보를 검색하는 부분에서 웹 서버와 데이터 베이스 연동이 일어나므로 SQL 삽입 공격을 수행할 수 있음.
05. 웹 취약점의 이해 https://sqlzoo.net/hack/
05. 웹 취약점의 이해 웹의 주요 취약점 인증 및 세션 관리 취약점(A2. Broken Authentication and Session Management) 취약한 패스워드 설정 웹의 경우 대부분 전문 개발자가 개발하고 사용자는 이를 단순하게 이용할 뿐. 관리자 패스워드를 변경하는 인터페이스가 별도로 만들어져 있지 않아 사용자는 개발자가 처 음 설정한 패스워드를 그대로 쓰는 경우가 많음. 웹에서 admin/admin과 같이 취약한 패스워드를 자주 발견할 수 있음.
05. 웹 취약점의 이해 웹의 주요 취약점 인증 및 세션 관리 취약점(A2. Broken Authentication and Session Management) 사용자 데이터를 이용한 인증 이러한 문제점은 최초 인증 후에는 인증과 신분 증명 역할을 클라이언트에 넘겼기 때 문에 발생함. 인증 뿐만 아니라 데이터 신뢰도의 증명 권한을 클라이언트로 넘기면 얼 마든지 악용할 수 있음. 웹의 많은 취약점은 단순히 편리하다는 이유로 서버가 통제할 사항을 클라이언트에 넘 기는 데 있음을 유념해야 함.
05. 웹 취약점의 이해 웹의 주요 취약점 XSS 취약점(A3. Cross-Site Scripting) XSS(Cross-Site Scripting)는 공격자가 작성한 스크립트가 다른 사용자에게 전달되는 것. 다른 사용자의 웹 브라우저 안에서 적절한 검증 없이 실행되므로 사용자 세션 탈취 , 웹 사이트 변조, 악의적인 사이트로 사용자 이동시킬 수 있음. 일반적인 XSS 공격 구조 [그림 4-38] XSS 공격의 구조
XSS 공격 사례
05. 웹 취약점의 이해 웹의 주요 취약점 취약한 접근 제어(A4. Broken Access Control) 인증된 사용자가 수행할 수 있는 것에 대한 제한을 제대로 적용하지 않은 것을 의미. 공격자는 이를 악용하여 사용자 계정 접근, 중요 파일 보기, 사용자 데이터 수정, 접근 권한 변경 등과 같이 권한 없는 기능을 사용하거나 데이터에 접근할 수 있음. 관리자 페이지가 추측하기 쉬운 URL이거나 인증이 필요한 페이지에 인증을 하지 않고 우회하여 접속할 수 있는 취약점. 인증 우회를 막으려면 웹의 중요 페이지에 세션 값(쿠키)을 확인하는 검증 로직을 입력 해 두어야 함. 프로그램 개발시 표준 인증 로직을 만들어 웹에 존재하는 모든 페이지의 앞부분에 입 력해야 함. 디렉터리 탐색(directory traversal) 웹 브라우저에서 확인 가능한 경로의 상위를 탐색하여 특정 시스템 파일을 다운로드하 는 공격 방법. 자료실에 업로드한 파일을 전용 프로그램으로 내려받을 때 파일 이름을 필터링하지 않 아서 생기는 취약점. 파일 다운로드 전용 프로그램을 작성하여 사용할 때는 ..와 / 문자를 필터링해야 함.
05. 웹 취약점의 이해 웹의 주요 취약점 보안 설정 오류(A5. Security Misconfiguration) 디렉터리 리스팅(directory listing) 웹 브라우저에서 웹 서버의 특정 디렉터리를 열면 관련 파일과 목록이 모두 나열되는 취약점. 관리자가 인지하지 못했거나 웹 서버 자체의 취약점으로 인한 것. [그림 4-43] 디렉터리 리스팅의 예
05. 웹 취약점의 이해 웹의 주요 취약점 보안 설정 오류(A5. Security Misconfiguration) 백업 및 임시 파일 존재 웹 사이트 개발시 웹 서버 백업 파일이나 임시 파일을 삭제하지 않고 방치하면 공격자 가 백업 파일을 통해 웹 애플리케이션의 내부 로직, 데이터베이스 접속 정보 등 획득 가능. 예) login.asp의 백업 파일인 login.asp.bak 파일 미흡한 주석 관리 웹 애플리케이션에서 웹 프록시를 이용하면 일반 사용자도 볼 수 있는 주석에는 웹 애 플리케이션 개발 과정, 주요 로직에 대한 설명, 디렉터리 구조, 테스트 소스 정보, 아이 디와 패스워드 등이 기록됨. 웹 애플리케이션 개발시 주석에 정보를 기록할 때는 주의해야 함. 파일 업로드 제한 부재 공격자가 웹 서버에 악의적인 파일을 전송한 뒤 원격지에서 실행하면 웹 서버 장악, 내 부 침투 공격 수행 가능. 웹 해킹의 최종 목표인 웹 서버 통제권을 얻기 위해 반드시 성공해야 하는 공격.
05. 웹 취약점의 이해 웹의 주요 취약점 보안 설정 오류(A5. Security Misconfiguration) 리버스 텔넷 웹 해킹으로 시스템 권한 획득 후 직접 명령을 입력하고 확인할 수 있는 셸(예를 들어 텔넷)을 획득하기 위한 방법으로, 방화벽이 있는 시스템을 공격할 때 자주 사용함. 방화벽 내부에 존재하는 웹 서버는 80번 포트를 이용한 웹 서비스만 제공하면 되므로 외부 인터넷 사용자에게 80번 포트만을 허용함. 웹 서버의 텔넷이 열려 있어도 방화벽 으로 인해 외부 공격자의 접근 불가능. 방화벽의 인바운드 정책에서 80번 포트 외에 필요한 포트만 빼고 다 막아놓지만, 아웃 바운드 정책에서는 별다른 필터링을 수행하지 않는 경우가 많음. 이때 웹 서버에서 공 격자의 PC로 텔넷 연결을 허용하는 상황을 공격자가 이용하는 것이 리버스 텔넷임. 인바운드 정책: 외부에서 방화벽 내부로 들어오는 패킷에 대한 정책 아웃바운드 정책: 내부에서 외부로 나가는 패킷에 대한 정책 [그림 4-45] 내부에서 외부로 접속이 허용된 텔넷 접속
05. 웹 취약점의 이해 웹의 주요 취약점 보안 설정 오류(A5. Security Misconfiguration) 리버스 텔넷 웹 서버에서 공격자 PC로 텔넷 접속을 하기 위한 권한 획득을 위해 파일 업로드 공격 을 이용, 웹 셸 업로드로 시스템에 명령을 입력할 수 있는 명령 창 얻기. ① 명령 창 획득: 파일 업로드 등으로 웹 브라우저에서 실행 가능한 웹 셸을 웹 서버에 업로드, 공격자가 명령을 입력할 수 있 는 명령 창 획득함. ② 리버스 텔넷용 툴 업로드: 서버 게시판의 파일 업로드 기능을 이용하여 nc(net cat)와 같은 리버스 텔넷용 툴 업로드. ③ 공격자 PC의 리버스 텔넷 데몬 활성화: 서버에서 리버스 텔넷을 보내면 이를 받아 텔넷을 열 수 있도록 준비. ④ 획득한 명령 창으로 공격자에게 리버스 텔넷을 보내면 리버스 텔넷 창 획득. 리버스 텔넷 공격을 막으려면 asp뿐만 아니라 exe나 com과 같은 실행 파일의 업로드 를 막아야 하고 내부에서 외부로의 불필요한 접속도 방화벽으로 막아야 함.
05. 웹 취약점의 이해 웹의 주요 취약점 민감한 데이터 노출(A6. Sensitive Data Exposure) 웹 사이트 해킹으로 개인 정보가 유출되는 것은 신용카드 번호, 주민등록번호, 인증 신 뢰 정보와 같은 민감한 데이터를 보호하지 않는 것이 주요한 원인. 민감한 데이터를 보호하려면 데이터 중요도에 따라 암호화 로직을 사용하고 데이터베 이스 테이블 단위에서 암호화를 수행해야 함. 예) 인터넷 뱅킹과 같이 보안성이 중요한 시스템에서는 웹 트래픽을 암호화하는데 사용하는 암호화 알고리즘이 약하거나 구 조에 문제가 있다면 웹 트래픽이 복호화되거나 위조 또는 변조될 수 있음. 공격 방어 취약점(A7. Insufficient Attack Protection) 예전 웹 애플리케이션은 해킹 공격을 탐지(detect), 방지(prevent), 대응(respond)할 수 있는 기능을 갖추고 있지 않았음. APT 공격이 일반화되면서 보안 솔루션으로 탐지가 어렵자 웹 애플리케이션 수준에서 자동으로 탐지, 로깅, 응답 및 공격 시도 차단을 포함하도록 권고함.
05. 웹 취약점의 이해 웹의 주요 취약점 CSRF 취약점(A8. Cross-Site Request Forgery) CSRF(Cross Site Request Forgery)는 불특정 다수를 대상으로, 로그인된 사용자가 공격 자가 의도한 행위(수정, 삭제, 등록, 송금 등)를 하게 만드는 것. 악성 스크립트가 클라이언트에서 실행되는 XSS 공격과 달리 CSRF 공격은 사용자가 악 성 스크립트를 서버에 요청한다는 차이가 있음. CSRF 공격이 성공하려면 수정, 삭제, 등록 과정에서 사용자를 구분하는 인수값이 존재 하지 않아야 함. 특정 사용자를 구분하는 인수가 있으면 한 사용자에게만 적용되거나 인증 과정을 통해 CSRF 공격을 막을 수 있기 때문. 취약점이 있는 컴포넌트 사용(A9. Using Components with Known Vulnerabilities) 컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈이 다양하게 사용되면서 보안에 취약한 컴포넌트가 악용되면 심각한 데이터 손실, 서버 장악이 가능해짐. 사용하려는 컴포넌트, 라이브러리의 보안 취약점을 충분히 검토해야 함. 취약한 API(A10. Underprotected APIs) API를 통해 웹 서비스 상호 간의 연동이 이루어지므로 API 사용시 보안에 취약하지 않 은지 충분한 검토가 필요함.
05. 웹 취약점의 이해 웹의 취약점 보완 특수문자 필터링 웹 해킹의 가장 기본적인 형태 중 하나는 인수 조작으로 예외적인 실행을 유발하기 위 해 특수문자를 포함함. 공격에 사용되는 주요 특수문자를 함수 등을 이용하여 제거할 수 있음.
05. 웹 취약점의 이해 웹의 취약점 보완 서버 통제 작용 지속적인 세션 관리 CSS 기반의 언어로 필터링하는 경우에는 공격자가 로직만 파악하면 필터링이 쉽게 무 력화되므로 ASP, JSP 등과 같은 SSS로 필터링 로직을 수행해야 함. 지속적인 세션 관리 모든 웹 페이지에 일관성 있는 인증 로직을 적용하려면 기업 또는 웹 사이트 단위에서 세션 인증 로직을 표준화하고, 표준을 준수하여 웹 페이지를 개발하도록 해야 함. [그림 4-48] 사용자의 입력을 필터링하여 SQL 삽입 공격에 실패한 경우
웹해킹 실습 WebGoat를 이용한 자체 웹해킹 실습 상용 웹서비스를 웹해킹 실습대상으로 실습하는 것은 불법. WebGoat는 Web Application 보안을 공부할 수 있도록 OWASP에서 일부러 취 약하게 제작한 웹서버임. WebGoat를 내 컴퓨터에 설치하여 웹해킹을 공부할 수 있음. 실습 안내 http://kblab.tistory.com/111 다운로드 https://github.com/WebGoat/WebGoat/releases JDK 설치 http://www.oracle.com/technetwork/java/javase/downloads/jdk8- downloads-2133151.html WebGoat 실행 F:\webgoat>java -jar webgoat-server-8.0.0.M12.jar 브라우저에서 접속 http://127.0.0.1:8080/WebGoat
과제 3. 웹보안 관련 주제 실습해보기 다음의 주제들 중에서 자신이 수행할 수 있는 내용을 수행해보고 보고서 제출하기 1. 웹페이지 작성해보기 (HTML5, CSS3, Javascript등) 2. 구글해킹으로 정보 탐색 3. 웹사이트 취약점 분석하기 – Acunetics, OWASP Zed Attack Proxy 4. WebGoat를 이용한 웹해킹 실습 5. 워게임 사이트를 이용한 웹해킹 실습 6. 기타 인터넷 정보를 활용한 웹해킹 실습