안전한홈페이지운영을위한 웹서버설정및개발보안가이드 (Ver. 1.0) 2007. 10 출처 : CrossWeave 홈페이지개발보안정책가이드 (Ver. 1.3) Pusan National University Information Technology Center 1 / 13
목 차 Ⅰ. 개요 3 Ⅱ. 정보보호를고려한홈페이지구축의필요성 4 Ⅲ. 홈페이지구축및운영기본가이드 5 Ⅳ. 홈페이지개발기본원칙 6 Ⅴ. 홈페이지개발가이드 1. HTTP Method 제어 7 2. 에러페이지차단 7 3. 요청페이지확장자제어 7 4. 업로드파일확장자제어 7 5. 게시판개발형식제한 8 6. 요청 URL의모든문자제어 8 7. 홈페이지경로및사용자계정관리 9 8. 개인정보보호대책 9 9. 인증처리에 Server Side Script를이용한개발 9 10. 예외상황에대한예외처리 ( 버퍼오버플로우 ) 9 11. 취약한쿠키및세션에대한대책 10 12. 관리자페이지에대한강력한접근제어관리 10 13. 백업파일의관리 11 14. 웹서버배너정보의관리 11 15. 업로드파일크기제어 11 16. 웹의디렉토리실행권한제한 12 17. 디렉토리리스팅제어 12 18. 상대경로가아닌절대경로를통한코드연결 12 19. RFC HTTP 표준에맞는홈페이지개발 12 20. 유닉스계열에서심볼릭링크사용제거 12 21. 특정파일의내용보기방지 13 22. 주요파일시스템설정변경 13 23. Script 작성 13 Pusan National University Information Technology Center 2 / 13
Ⅰ. 개요 홈페이지서버는개인들도보유할정도로보급이확산되고있고, 그중요도도나날이증가하고있습니다. 하지만, 최근해외해커그룹에의해수천개의국내홈페이지가해킹당하는등홈페이지서버는해커들의주요공격대상이되고있습니다. 홈페이지해킹으로인한피해도초기화면변조또는파괴, 홈페이지서버를경유한내부시스템으로의침투, 고객정보유출등대단히다양하고심각할수있습니다. 홈페이지해킹사고는개인이나기업의문제만이아니라홈페이지가정보화의기반요소로자리매김해가고있는시점에서국가정보화의진전을저해할수있는걸림돌로작용할수있습니다. 최근의대규모홈페이지변조사고의주요원인이홈페이지개발과정의보안취약점을통해서이루어지고있는것이현실이며, 개발과정의근본적인문제점으로인해서웹방화벽등의대책솔루션을구매설치운영하더라도, 보안정책이많이허술하게적용운영될수있는문제점이존재할수있기때문에개발실무자및홈페이지서버운영자들이안전하게홈페이지를구축할수있도록 를만들게되었습니다. 이가이드는개발과정에서발생될수있는수많은보안정책위배및무분별한개발로인하여향후웹방화벽도입적용 / 운영시그효과를배가시켜서강력한보안정책을적용할수있도록하는근간을이루고자함이며, 보안사고를미연에방지하여안정적인웹서비스를제공할수있는기반을제공하고자함입니다. Pusan National University Information Technology Center 3 / 13
Ⅱ. 정보보호를고려한홈페이지구축의필요성 홈페이지서버를포함한정보시스템의정보보호를제공하는방법은일반적으로추가 (Add-on) 방식과내장 (embedded) 방식의두가지방법이있습니다. 첫째, 추가방식 (Add-on) 은정보시스템의설계또는구축이후에정보보호제품이나정보보호시스템을추가구현하는방식입니다. 홈페이지서버보안을위해서도웹방화벽과같은추가적인보안장비를도입하는것이추가방식이라할수있습니다. 이방식은이미구축되어있는많은웹서버및향후개발될홈페이지에대한다양한보안대책을고려하기위해서현재출시된보안제품들중에서최적의방안으로최근공격대상이웹서버에집중되고있는점을고려한다면추가방식에의한웹보안을도입하는것이좋을것으로생각됩니다. 둘째, 내장방식 (embedded) 은정보시스템계획단계에서부터정보보호요구사항을파악하여정보시스템분석및설계에정보보호기능을구현하는방식으로, 초기에는정보보호요구사항파악및기능구현을위한시간과노력이요구되나다른정보시스템기능과원활한상호운용성을제공할수있어근본적인웹페이지의보안대책방안입니다. 쉽게말하면, 윈도우 OS 를통한수많은웜 / 바이러스 / 해킹시도가이루어지고있는데, 이에대한근본적인대책으로백신소프트웨어설치및주기적인업데이트도있지만, Microsoft 에서제공하는보안패치를적용하는것이근본해결책이듯이웹서버를보안하기위한근본적인접근방식이개발단계에서 Source Code에존재할수있는수많은보안취약점을제거하여개발하는것입니다. 하지만, 완벽한사람은없듯이이와같은개발단계에서의보안적용으로완벽한웹페이지구현은힘들며, 또한내장방식을통해서홈페이지가구축된사이트의경우추가방식에의한웹방화벽도입 / 설치 / 운영시보다강력한보안정책을구현하여개발자의실수로인한보안취약점에대한방어를수행할수있으며, 이를통한안정적인웹서비스를운영할수있을것입니다. 많은웹개발자들은홈페이지를구축할때효율성, 편의성, 비용, 시간성에치중하여설계 / 구축단계에서정보보호를고려하지못하고있습니다. 또한, 홈페이지의특성상외부에공개될수밖에없고, 일반적인침입차단시스템에의해서보호받지못하고있어최근많은해킹사고가발생되고있습니다. 해커에의해서뿐만아니라업체의모의해킹시에주요공격대상이되고많은취약점이발견되는곳이홈페이지서버입니다. Pusan National University Information Technology Center 4 / 13
Ⅲ. 홈페이지구축및운영기본가이드 1. 자체적으로시스템을구축시전문시스템엔지니어를두거나외부업체에위탁한다. ( 정보전산원기관홈페이지시스템이용가능.) 2. 자체적으로시스템구축하는기관에서는웹서버나데이터베이스서버에는불필요한소프트웨어를설치하지않는다. 3. 홈페이지내에존재하는모든컨텐츠는주기적으로백업을하여보관하며, 백업방법은하드디스크백업을 1차로하고, CD 또는 TAPE을이용 2차백업을해서보관한다. 4. 홈페이지구축시 를준해서개발하고, 소스내에포함된모든 DB 쿼리문은 SP(Stored Procedure) 를사용하여만든다. (WINDOWS 기반일경우 ) 5. 홈페이지에서사용하는게시판은가능하면파일업로드를기능을뺀다. 부득히필요할경우는아주제한적으로 ( 용량제한, 파일확장자제한등 ) 기능을두어사용한다. 6. 로그인기능을두어인증된사용자만홈페이지게시판등에글을게시할수있도록한다. Pusan National University Information Technology Center 5 / 13
Ⅳ. 홈페이지개발기본원칙 1. 웹에서발생되는모든사용자입력값은신뢰할수없으며, 모든입력값을점검확인후받아들여서처리하여야합니다. 2. 사용자에게전달된값 (Hidden Form Field, Parameter) 을재사용할경우에도절대로신뢰해서는안되며, 재사용시적합성및정당성, 변조유무를점검확인하여처리하여야합니다. 3. 최종통제메커니즘은모두웹서버에서수행되고종결되어야합니다. 4. 클라이언트에게는중요정보를 (ID, PWD, 개인정보 ) 전달하지않습니다. 5. 클라이언트에서입력되는중요정보는 POST Method 및 SSL 등의암호화방법을사용하여전송하여야합니다. 6. 중요한트렌젝션이일어나는프로세스에사용자의비밀번호를재확인할수있도록합니다. 7. 중요정보를보여주는페이지는캐쉬를사용하지못하도록설정한다. <meta HTTP-EQUIV="Pragma" CONTENT="no-cache"> 8. 적절한방법으로암호화한다. ( 자체개발한암호화알고리즘사용을지양하며, 공인된암호화알고리즘 -3DES, SEED, AES 등- 을사용하는것을고려하여야합니다.) 9. 각언어에서제공하는보안수단을이해한후보안코딩을통한홈페이지개발이이루어질수있도록합니다. 10. 홈페이지디자인 설계 개발 운영각단계에서지속적이고, 반복적으로웹취약점분석을수행하여웹서버 / 어플리케이션자체의취약점을제거하도록합니다. 11. 모든프로그램은가능하면 Client Side Script 방식이아닌 Server Side Script 방식으로개발하여야한다. Pusan National University Information Technology Center 6 / 13
Ⅴ. 홈페이지개발가이드 1. HTTP METHOD 제어 HTTP Method는 GET, POST 만을이용하여개발하여야하며, PUT Method 의경우도해킹에많이사용되고있는 Method 유형으로백도어파일및홈페이지변조파일을업로드하기위해서자주사용되는 Method 로써가능하면개발자제하도록권고하여야합니다. 필요에의해 PUT 을이용하여게시판파일업로드를할경우업로드되는파일의확장자등에대한강력한제어를통해서개발구현되어야합니다. GET, POST Method 는개발자들에의해 Enable 되지만, 이외의 Method 들은웹서버 (Apache, IIS) 의설정을통해서제어되기때문에이부분은시스템관리자의역할입니다. 2. 에러페이지차단 HTTP Response Code 로응답되는코드들에대해보호할수있는프로그램이개발되어야합니다. HTTP 400 Client Error, 500 Server Error 메시지가웹서버의응답으로나갈경우이페이지들에는중요한서버정보들이포함되어있을수있으며, 상당수의 SQL Injection 공격들은이와같은에러페이지를통해서해킹이시작됩니다. 따라서별도의사용자 Page를개발하여 Response Code 400, 500 에러메시지는대체페이지 Redirect 기능을사용하여숨겨줄수있도록개발되어야합니다. Apache 의경우 httpd.conf 파일에서설정을해주면됩니다. 3. 요청페이지확장자제어웹서비스를제공하기위해서사용된개발 Source Code 및웹컨텐츠들은범용적으로사용되는파일의확장자를사용하여개발하여야하며, 절대적으로파일확장자를가변으로사용하여개발하면안됩니다. 고정된확장자를통해개발되어야하며, 특수문자및숫자등을파일확장자로사용하면안됩니다. 이부분은웹개발자뿐만이아니라, 게시판을통해서새로운게시물내용업로드를담당하는홈페이지운영자에대한교육이필수적입니다. 게시판업로드기능을통해 EXE 파일이업로드된다면위의보안정책은위반되는것이기때문입니다. 4. 업로드파일확장자제어웹을통해서일반클라이언트들이업로드할수있는파일의형태에대한강력한제어가수반되어야합니다. 일반적으로압축파일 / 텍스트파일 / 이미지파일등에대한업로드만을허용또는부분허용하여야하며, 나머지모든파일에대해서는강력히제한되어야합니다. 따라서개발코드상에서 TXT, BMP, PDF, ZIP 등 Pusan National University Information Technology Center 7 / 13
의파일업로드만허용되도록코딩이이루어져야합니다. 또한, 향후전체웹페이지가아닌일부페이지내용수정되었을때, 일반적인 HTML 만을이용해서개발하였다가, HTM 등기존에사용안하던 Source 를이용하여개발하는것도제한되어야합니다. 5. 게시판개발형식제한게시판에입력될수있는문자들에대한강력한제어가수반되어야합니다. 특히, 특수문자들은해킹코드로악용될수있기때문에, 입력을제한하거나 Entitiy 형태로변환하여입력처리되도록코딩되어야합니다. 특수문자들의입력을 Entity 형태로자동변환해주는유용한함수들이존재합니다. ASP 의경우 : Server.HTMLEncode( 입력문자열 ) PHP 의경우 : htmlspecialchars( 입력문자열 ) 함수로입력문자를 Entitiy 로변환 Strip_tags(), strip_replace() 함수를이용하여 HTML, PHP 태그를제거 JSP 의경우 : replaceall( <, < ); 함수를이용입력문자를 Entity 로변환 일반적으로쉽게악용될수있는 HTML Tags <APPLET>, <BODY>, <EMBED>, <FRAME>, <FRAMESET>, <HTML>, <IFRAME>, <IMG>, <LAYER>, <ILAYER>, <META>, <OBJECT>, <SCRIPT>, <STYLE> 6. 요청 URL 의모든문자제어게시판을제외하고, 웹페이지에서제공되는모든서비스는가능하면영문자, 숫자, 한글만을사용하여야하며, 나머지문자를통한개발및사용자입력을원천적으로제한하여야합니다. 게시판에개발코드를삽입하는 Cross Site Scripting (XSS) 공격들에대한방어를위해서는특수문자제어는필수적이며, 텍스트형태의게시판으로만들어야합니다. 가능하면 Web Editor 를이용한게시판의개발및운영은배제되어야합니다. 사용자로그인페이지로사용자가입력되는값은영문자와숫자만을사용하여각필드단위의최소 / 최대문자길이를제한하여야하며, 절대로특수문자를사용한비밀번호입력을허용하면안됩니다. ( 특수문자허용으로인한 SQL Injection, Blind SQL Injection공격허용 ) 위의보안정책으로허용이안되는문자에대한웹페이지공지를통하여서비스의불편함을최소화하여사용자가불편함을느끼지않도록하여야하며, 모든사용자입력부분에차단가능한특수문자내역을기재하여야합니다. 특히, 모든페이지에서 Single Qutation ( ) 의입력을절대로허용하면안되며, 이문자입력에대한모든예외처리 Source Coding 부분이이루어져야합니다. Pusan National University Information Technology Center 8 / 13
7. 홈페이지경로및사용자계정관리홈페이지개발시개발자들이등안시하는사항중에하나가가장일반적으로사용하는디렉토리이름과계정을통한관리자페이지및로그인을허용하고설정하는것입니다. 예를들어 http://www.sample.com/admin/ 경로를통해서관리자의 Admin 페이지접속을허용하는경우와 login/master 등의경로및 login.html 등의파일이름을사용하여개발하게되면, 인터넷검색엔진을통해서쉽게검색이가능하며, 이를악용하는해커는이와같은경로및이름들을쉽게유추하여공격시도를할수있기때문에개발시에이와같은방법은배제되어야한다. 또한관리자로그인계정을 admin / master / webmaster/ root 등의쉽게유추하거나많이알려진계정을사용하는데이와같은계정또한가능한사용시배제되어야합니다. 8. 개인정보보호대책최근에문제가되고있는개인정보유출문제로인해서많은회사들이이에대한대응책에고민을하고있는실정입니다. 일부사이트의경우주민번호등으로사용자인증및웹클라이언트와서버간에지속적으로주민번호가전송되는경우가있는데이와같은개발은배제되어야합니다. 즉, 민감한개인정보를통한사용자인증을체크하는홈페이지는근본적으로다시개발되어야합니다. 특정페이지의경우인증된개인정보를 HIDDEN 필드등을이용하여클라이언트에게다시전송하는경우도있는데, 이와같은구조자체는많은문제점을야기시킬수있습니다. 주민번호는회원등록시에만필요한사항으로모든웹페이지에서주민번호는차단되어야합니다. 특히게시판의경우주민번호입력자체를차단하는것이최선의방안입니다. 개인정보를사용자의인증확인등을위해서필히사용하여야한다면특정디렉토리내의개발 Source Code 에서만사용하도록가능한한정하여개발되어야합니다. 9. 인증처리에 SERVER SIDE SCRIPT 를이용한개발인증과정을처리하는부분에 Client Side Script (Javascript, VBScript 등 ) 을사용하면사용자가임의로 Proxy 프로그램을이용하여악용할수있는방법들이존재하여, 이를수정조작하여인증우회시도를할수있습니다. 이와같은취약점을예방하기위해서 Server Side Script (PHP, ASP, JSP 등 ) 을통하여인증및필터링과정이수행되도록개발하여야합니다. 10. 예외상황에대한예외처리 ( 버퍼오버플로우 ) 홈페이지개발자들이홈페이지의개발과웹서비스시작이라는목적하에개발을수행하다보니, 실수하는문제점중의하나가모든 Source Code 상에존재할수있는예외상황에대한예외처리를하지않는것입니다. 예를들어 integer value 라는프로그램변수명을통하여사용자입력및프로그램내부적인처리를 Pusan National University Information Technology Center 9 / 13
수행할경우에정수형변수의크기는 0 =< val <= 65,536 인데, 이값보다크거나작은값이해당변수로입력될때의예외상황처리를위한코딩을하여야합니다. 또한, char id[10], pwd[10] 이라는배열변수를사용할경우정상적인사용자라면정상적인값들을입력하겠지만, 해커는 10 byte 이상의값을입력하거나, 패킷변조를통하여문자가아닌특수문자들을입력하여서버에서응답나오는메시지등의정보를통해서 2, 3 차적인해킹시도를수행할수있습니다. 이와같은예외처리를위한코딩이안된경우프로그램오류로인해서서비스다운및홈페이지변조등많은침해사고를경험할수있습니다. 이와같은예외처리는개발코드상의모든부분에서존재할수있으며, 개발시가장기본이되는유의하여야할사항입니다. 이와같은경계값을체크하지하지않는함수들로는 strcpy(), strcat(), sprintf(), vsprintf(), gets() 와같은함수들로이들함수의사용은자제하여야하며, strncpy(), strncat(), snprintf(), fget() 과같은함수를사용하여야한다. 또한 scanf 계열의함수들은위험하므로최대한입력받을수있는문자열의길이를제한하여야하며, realpath(), getopt() 와같은함수들도최소한의 PATH_MAX 길이를정해주는 getwd() 함수를사용하는것이안전합니다. 11. 취약한쿠키및세션에대한대책사용자의로그인계정을관리하는쿠키의경우해당쿠키값은클라이언트의컴퓨터에저장되기때문에이를통한쿠키변조등의많은해킹공격시도가가능합니다. 이와같은공격에대한방어방법이 Client Side Session 방식인쿠키를사용하는것이아니라, 웹서버에서제공되는 Server Side Session 방식을통하여운영될수있도록개발되어야합니다. Client Side Session의쿠키를사용하는경우해당쿠키를암호화및디지털서명인증을통하여보호되어야하며, 클라이언트의 IP Address 에서만해당쿠키값이유효하도록프로그램이개발되어야하며, 웹개발자에의해서개발된쿠키값이외의변수명 / 변수값입력시에이에대해검증할수있는 Source Coding이이루어져야합니다. 또한최근에는사용자의계정관리가이루어지는쿠키값에 SQL Injection, Cross Site Scripting 등의공격수행을위해서 Single Qutation( ), <script> 등의문자열을입력하여공격성공하는사례들도발생하고있기때문에쿠키의입력값에대한검증하는프로그램코딩도추가되어야합니다. 12. 관리자페이지에대한강력한접근제어관리일반적으로홈페이지관리를위해서 http://www.example.com/admin/login.html 와같은형태로관리자페이지가개발되어운영되고있는경우가대부분입니다. 만약악의적인공격자가이관리자페이지의계정을획득하거나, SQL Injection 등의공격을통해서접근이허용된다면더이상의보안대책이존재하지않게되며, 또한 Pusan National University Information Technology Center 10 / 13
여러명의관리자가많이알려진 admin/webadmin 등의계정과손쉬운비밀번호로동시에로그인하여홈페이지를관리운영하고있는경우가많습니다. 이와같은관리자페이지는별도의도메인및서비스포트 8080, 7000번등으로서비스를하여야하며, 네트워크방화벽등에서관리자페이지접근이가능한 IP Address 에대한강력한접근제어를통해서운영되어야합니다. 또한관리자페이지의경우 SSL 등의암호화된연결을통한접속으로중요정보를암호화하여통신되도록설정되어야합니다. 또한, 접근제어가필요한모든페이지에통제수단 ( 로그인체크및권한체크 ) 을구현해야합니다. 특히, 하나의프로세스가여러개의페이지또는모듈로이루어져있을때권한체크가누락되는경우를방지하기위해서공통모듈을사용하는것을권장합니다. 13. 백업파일의관리홈페이지의유지 / 관리측면에서중요 Source File 이수정된경우기존파일을같은디렉토리위치에 example-1.asp, example.asp.bak 와같은형태로백업파일을만들어서관리되고있는경우가많습니다. 이와같은백업파일에대한유지가안되어이를통한수많은공격들이성공할수있으며, Source File 자체를쉽게다운받아악용할수있는부분들이존재하게된다. HTTP 80 포트를통해서누구나접근할수있는웹컨텐츠데이터들은반드시사용되는파일들만접근되어사용될수있도록하여야하며, 백업파일을홈페이지의 80 포트를통해서접근할수있는경로에저장하면안됩니다. 동일웹서버의웹홈디렉토리가아닌별도의디렉토리에백업파일을보관하거나, 별도의백업장치를이용하여백업파일에대한관리가수행되어야합니다. 14. 웹서버배너정보의관리웹서버의응답헤더에포함되어유출될수있는웹서버 ( 배너 ) 정보는강력하게제한되어야합니다. Apache, IIS, PHP 등설치되어있는어플리케이션의버전정보가유출될시해커들은손쉽게해당버전에서의취약점을검색하고, 해당취약점공격코드를획득하여공격을시도할수있습니다. 이와같은배너정보만제거된다고하더라도, 해커는해킹이그만큼어려워질수있습니다. 15. 업로드파일크기제어게시판등에업로드될수있는파일의경우일반문서파일은크기가얼마안되지만, 동영상등의파일의경우는용량이큰파일업로드를통한웹서비스속도저하등서비스에영향을줄수있는부분이존재합니다. 따라서업로드가허용된모든웹서비스에서는가능하면업로드파일의크기를제한하는것이좋습니다. 이에대한제어는웹방화벽솔루션을통해서손쉽게적용및제어할수있습니다. Pusan National University Information Technology Center 11 / 13
16. 웹의디렉토리실행권한제한웹에서는일반적으로는디렉토리에실행권한및쓰기권한부여가필요없습니다. IIS 등에서부여되는업로드되는디렉토리의경우쓰기권한이부여되어야하지만, 쓰기 + 실행권한이동시에부여되면안됩니다. 17. 디렉토리리스팅제어웹서버에는현재브라우징하는디렉토리의모든파일들을사용자에게보여줄수있는디렉토리리스팅기능이기본적으로존재하지만, 이런기능이활성화되어있으면대부분의공격자가웹어플리케이션의구조를파악할수있는기회를제공하여주며, 민감한정보를포함한설정파일을조회및다운로드받아획득할수있습니다. 이는보안상매우위험하며이기능을중지시켜야합니다. Apache 의경우이와같은취약점을제거하기위해서는 httpd.conf 파일에서 DocumentRoot 항목을수정하여야한다. 18. 상대경로가아닌절대경로를통한코드연결웹개발자들이개발편의상및 Source Coding 을쉽게하기위해서특정 Hyperlink 연결및파일이름이나경로를사용하여코딩이이루어지는경우가많습니다. 이경우웹에존재하는다양한파일및시스템의중요파일을다운로드가가능하도록하는다운로드취약점이존재할수있습니다. 따라서웹 Source Code 내에컨텐츠연결되는모든코딩부분은상대경로가아닌절대경로를통해서개발이이루어지는것이보다보안적인개발방법론입니다. 19. RFC HTTP 표준에맞는홈페이지개발홈페이지의특성상모든사이트에존재하는웹의표준이존재하지않습니다. 이로인해서해당사이트에서만특이하게동작되는서비스형태들이많이존재하며, 이는향후홈페이지재개편및여러가지서비스장애등의문제들을유발할수있습니다. 물론, HTTP 표준이라는것을특정일부항목으로나열하기는힘들지만, 개발자들의머리속에있는특정화된홈페이지가아닌일반적으로통용되는홈페이지를개발하여야하며, 사이트의특정화된부분은웹디자인을통해서얼마든지구현될수있기때문입니다. 20. 유닉스계열에서심볼릭링크사용제거유닉스계열의시스템인경우심볼릭링크기능 (ln.s / system.html) 을사용하여다른위치의파일이나디렉토리와연결하여사용할수있는데, 이런경우웹에서허용하는디렉토리외에다른디렉토리를참조하는링크가존재할수있으며, 이를 Pusan National University Information Technology Center 12 / 13
통한액세스가허용되는위험성이존재합니다. 이위험성을제거하기위해서는 httpd.conf 파일에서 DocumentRoot 항목을수정하여야합니다. 21. 특정파일의내용보기방지임의의사용자가웹브라우저에서특정파일을입력함으로서파일내용을볼수있는데, 이를방지하기위하여환경설정파일을변경하여야합니다. 22. 주요파일시스템설정변경최근해킹유형중, 악성백도어프로그램을 /tmp, /dev/shm 등의디렉토리에업로드하여해당파일을실행시키는경우가발생되며, 이를방지하기위해서 /etc/fstab 의내용을수정하여해당디렉토리의실행권한을제거하도록합니다. 23. SCRIPT 작성위의권고사항으로개발 Code를작성하여웹보안이이루어졌다라는가정하에사용자가특수문자를사용한게시물을올렸을때웹방화벽의차단정책에의해차단이이루어지게됩니다. 그렇게되면사용자의게시물은저장이되지않은상태로차단이되어게시물을다시작성해야하는경우가있습니다. 이것은사용자의편의를위해지양해야할서비스이므로스크립트를이용해서 User-side에서먼저 Special Character를점검함으로써사용자의편의를도모할수있는웹페이지개발이이루어져야합니다. 특히인증과정을처리하는스크립트에 Client Side Script (JavaScript, VBScript 등 ) 을사용하면사용자가임의로수정할수있기때문에 Server Side Script (ASP, PHP, JSP 등 ) 를사용하여인증및필터링과정이수행될수있도록개발되어야합니다. 웹클라이언트에서자체적으로실행되는 JavaScript 등의 Script 코드는보안상많은문제점을도출할수있기때문에반드시필요한곳에만사용을하며, 가능한개발제한되어야합니다. Pusan National University Information Technology Center 13 / 13