목차 OWASP 의장제프윌리엄스서문... 5 OWASP 코리아챕터서문... 7 OWASP 코드리뷰가이드 1.1 환영사... 8 OWASP 소개 코드리뷰가이드역사 소개 준비 SDLC 에서보안코드리뷰 보안코드리뷰범위..

Transcription

1 에서배포 코리아챕터 OWASP 코드리뷰가이드 영문판 2008 V1.1 한글판 2015 V1.1 프로젝트후원사 : 엔시큐어 OWASP 재단 /OWASP 코리아챕터 이문서는 Creative Commons Attribution Share Alike 3.0 라이선스에따라승인되었습니다. 본한글문서를 활용시에는반드시 OWASP 코드리뷰가이드또는 OWASP 코리아챕터결과물인것을밝혀야합니다.

2 목차 OWASP 의장제프윌리엄스서문... 5 OWASP 코리아챕터서문... 7 OWASP 코드리뷰가이드 1.1 환영사... 8 OWASP 소개 코드리뷰가이드역사 소개 준비 SDLC 에서보안코드리뷰 보안코드리뷰범위 애플리케이션위협모델링 코드리뷰메트릭스 코드크롤링 J2EE/Java 에서코드검색 클래식 ASP 에서코드검색 자바스트립트 / Web 2.0 키워드와포인터 코드리뷰와 PCI DSS 기술통제검토 : 인증 기술통제검토 : 인가 기술적인통제사항검토 : 세션관리 기술통제검토 : 입력값검증

3 기술통제검토 : 오류처리 기술통제검토 : 안전한애플리케이션배치 기술통제검토 : 암호제어 버퍼오퍼런과오버플로우를위한코드리뷰 OS 인젝션을위한코드리뷰 SQL 인젝션을위한코드리뷰 데이터유효성검증을위한코드리뷰 크로스사이트스크립팅을위한코드리뷰 CSRF 를위한코드리뷰 로깅을위한코드리뷰 세션무결성을위한코드리뷰 경쟁상태를위한코드리뷰 추가적인보안고려사항 자바의지저분한것들 자바개발시주요보안사례 클래식 ASP 개발시주요보안사례 PHP 개발시주요보안사례 문자열과정수 MYSQL 개발시주요보안사례 플래쉬개발시보안사례 웹서비스개발보안 코드리뷰결과보고서작성법

4 자동화코드리뷰 도구적용모델 OWASP 의 ORIZON 프레임워크 OWASP 코드리뷰 TOP 참고문헌

5 OWASP 의장제프윌리엄스서문 많은조직에서개발된코드가자신들이생각하는것만큼안전하지않다는것을깨닫게되었다. 이제조직에서는애플리케이션의보안성을확인해야하는힘든일을시작하고있다. 소프트웨어, 응용프로그램의보안을분석하기위해자동스캔, 수동침투시험, 정적분석및수동코드리뷰등기본적인 4 가지기법이있다. OWASP 가이드는 4 가지기법에대해서최신내용에중점을두고있다. 물론이러한기법들은모두나름의강점, 약점, 최적의접점및사각지대를가지고있다. 가장적합한기술이무엇인지논쟁하는것은집을지을때톱과망치가더중요한지논쟁하는것과같다. 만약당신이망치로만집을지으려한다면, 당신은끔찍한일을하는것이다. 아마도도구보다더중요한것은망치를들고있는사람일것이다. OWASP 가이드는이기술들을사용하는방법을교육하기위해만들어졌다. 그러나각각의기법이분리되어있지만, 반드시분리되어사용되는것은아니다. 개발가이드는프로젝트에대해서안전한응용을설계하고, 개발하는방법을가르쳐주고, 코드리뷰가이드는소스코드가안전한지검증하는방법을알려주며, 테스팅가이드는애플리케이션이안전성에대해검증하는방법을보여준다. 보안공격기법은급변하고있어전통적인책이유용하지않을수있다. 그러나 OWASP 는협업환경으로인해최신의상태를유지할수있다. OWASP 가이드는수백명의공헌자들이있으며, 매월이러한자료에대한수천개이상의새로운업데이트결과물을만들어내고있다. OWASP 는모든사람들이사용할수있는수준높은애플리케이션보안자료를만들어내고있다. 이방법은 OWASP 가소프트웨어커뮤니티로서애플리케이션보안에대한실질적인발전을할수있는유일한방법이다. 왜코드리뷰가중요한가? 필자는타업무를병행하며보안코드리뷰를 1998 년부터진행해왔으며, 수천개의심각한취약점을찾았다. 경험적으로봤을때, 문서디자인, 코드주석, 그리고심지어개발자들스스로가가끔실수하는경우도있다. 코드는거짓말을하지않는다. 실제로코드는해커로부터방어할수있는오직개발자만이가지는이점이다. 이러한이점을포기하지말고외부에서하는침투시험을이용해야한다. 코드를사용하라. 코드리뷰는비용이너무많이발생하거나시간이소요된다는주장이많음에도불구하고, 코드리뷰는많은보안문제를발견하고진단할수있는가장빠르고정확한방법이라는것에는이의가없다. 코드리뷰이외의다른방법으로는쉽게찾을수없는심각한보안취약점도많이있다. 보안코드리뷰의비용대비효과성에대해서강조하지않을수없다. 애플리케이션에서중요한보안문제를식별할수있는접근방법을고려해야하는데, 코드를검토하는것이가장빠르고정확한선택이다. 모든애플리케이션은다르기때문에개개인에게가장비용효과적인기법을사용하여보안성을검증하도록하는것이매우중요하다. 한가지일반적인방법은보안코드리뷰를사용하여문제점을찾고, 침투시험을통해악용이가능한지증명하는것이다. 다른방법은침투시험으로잠재적인문제를찾고, 코드를검사하여문제를확인하는것이다. 애플리케이션보안을위해서는 통합적인 " 접근법이최선의선택이다. 5

6 시작하기 코드가어떤것을만드는데사용할수있는풍부하게표현할수있는언어라는것을인식하는것은중요하다. 임의의코드를분석하는것은여러가지문맥적일것을요구하는어려운일이다. 그것은법적인계약에허점이있는지검색하는것과같다. 그래서자동화된도구로간단히보안취약점을찾는것이매력적으로보이지만이러한도구는맞춤법검사기또는문법검사기와같다는것을아는것이중요하다. 중요한것은, 그도구들은문맥을이해하지못하고, 여러중요한보안문제를놓칠수도있다. 하지만도구를실행하면코드리뷰를위해데이터를수집하는데사용할수있는좋은방법이다. 작업을시작하기위해서는, 모든소프트웨어기준선, 현대적인 IDE( 통합개발환경 ) 및보안취약점들이만들어지는것에대해생각하는능력이다. 당신이어떤코드를보기전에당신은가장중요한것이무엇인지를심사숙고할것을강력히권장한다. 그렇게한다면보안메커니즘이존재하는지, 결함이없는지, 정상적으로사용되었는지확인하게된다. 당신은무엇이잘못진행되고있는지를애플리케이션의제어및데이터흐름을통해추적할수있다. 실행요구 소프트웨어를개발하고있다면, 먼저이문서의보안지침에대해잘알아야한다. 오류를발견하면토론문서에메모를추가하거나직접수정해서작성하기를바란다. 이가이드를사용하는다른수천명을도울수있다. 우리가이코드리뷰가이드등의자료와 OWASP 의다른프로젝트를계속지속할수있도록개인또는기업회원으로참여하기를바란다. 이가이드의모든과거와미래의기부자에게감사하고, 당신의작업이전세계응용을좀더안전하게만드는데도움이될것이다. -- OWASP 의장제프윌리엄스, 2007 년 10 월 17 일 6

7 OWASP 코리아챕터서문 소프트웨어가인터넷과결합되면서혁신적인서비스가계속출시되고있다. 혁신적인 IT 서비스개발자들은인터넷과소프트웨어를결합하여그동안경험하지못한새로운비즈니스모델, 서비스및새로운플랫폼을제공하고있다. 이런방향은앞으로사물인터넷 (IoT) 에까지확대되면서더큰영향을미칠것으로기대한다. 하지만동시에해커들은소프프웨어개발자들이간과한실수를놓치지않고, 취약점을공격하여국가인프라, 개별조직과개인에게피해를입히는뿐만아니라해커그룹으로금전적인이익을챙기는사례도증가하고있다. 최근에는항공기제어소프트웨어결함으로인해항공기가추락하고조종사사망하는사건까지발생하면서소프트웨어안전성의더욱더중요성이커지고있다. 이러한소프트웨어중요성및기술발전추세에맞춰우리나라관련정부부처, 연구소, 기업및민간단체등에서도다양한방법으로소프트웨어취약점과보안에대한대책과도구를제시하고있다. 하지만현장에서는개발자들과보안코드검토자들이쉽게참고할수있는가이드가부족한실정이어서, 그동안웹애플리케이션취약점을방어하는데현장의어려움이존재하였다. OWASP 코드리뷰 (Code Review) 는이러한문제를해결하기위해 2008 년에버전 1.1 이출간되어, 애플리케이션취약점을방어할수있는표준가이드를제공하였다. OWASP 코리아커뮤니티에서는현장의요구에따라코드리뷰를 2013 년부터전문가 10 여명이회사일을하면서약 2 년간의연구, 번역및감수를통해서 2015 년 6 월에마무리가되었다 ( 이작업을하는동안에 OWASP 코드리뷰 2.0 버전이출간되기도하였다. 2.0 문서는모바일기기플랫폼및새로운프로그램언어사례가포함되는등개발자들이더많이사용할수있도록업그레이드되었으며, 코리아챕터커뮤니티의차기중요과제가될것으로예상한다.) 본문서는국내에서웹애플리케이션취약점및위험으로많이알려진 OWASP Top 10 취약점을효과적으로방어할수있는실질적인대책을담고있다..NET, 자바, ASP 등다양한개발언어에대해서 SQL 인젝션, 크로스사이트스크립팅 (XSS) 등 OWASP 애플리케이션취약점에대한상세코드리뷰방법뿐만아니라, 로그기록관리, 플래쉬, 버퍼오버플러우와같은다른중요취약점에제거하기위한상세샘플코드도포함하고있다. 애플리케이션을개발하는개발자또는조직의품질관리부서에서는애플리케이션을개발시활용도가클것으로기대한다. 소프트웨어개발자및검토자들은만려무실 ( 萬慮無失 ) 의자세로본문서를참고하면서안전하게또한새로운서비스를사용할수있는환경을개발해줄것을권고드린다. 마지막으로본문서를번역하고감수에참여한 OWASP 한국회원여러분께감사을말을전한다. 기타본문서의내용에오류가있으면, 언제든지연락주시기바랍니다. -- OWASP 코리아챕터리더성윤기, 2015 년 6 월 30 일 7

8 OWASP 코드리뷰가이드 1.1 환영사 아들아! 인터넷에문제가생기면우리가해결할수있을까? ( My Children, the internet is broken, can we fix this mess?) -- Eoin Keary, OWASP 코드리뷰가이드주저자 & 편집자 OWASP 는오늘날이가이드가있게한저자, 검토자, 그리고편집자들의노력에감사드린다. 당신에게코드리뷰 가이드에대한의견이나제안이있으면코드리뷰가이드메일링리스트에이메일을보내주기바란다. 저작권및라이선스 영문판저작권 (c) 2008 The OWASP Foundation. 한글판저작권 (c) 2015 The OWASP 코리아챕터. 이문서는 Creative Commons Attribution Share Alike 3.0 라이선스에따라배포되었다. 라이선스와저작권 약관을참고하시기바란다. 영문판개정내역 코드리뷰가이드는 2006 년시작되었고, 테스팅가이드에서파생된프로젝트이다 년 Eoin Keary 에의해 제안되고, 위키로변환되었다 년 9 월 30 일 "OWASP Code Review Guide", Version 1.0 (RC1) 2007 년 12 월 22 일 "OWASP Code Review Guide", Version 1.0 (RC2) 2008 년 11 월 1 일 "OWASP Code Review Guide", Version 1.1 (Release) 편집자 Eoin Keary: OWASP Code Review Guide Present 8

9 저자 Andrew van der Stock David Lowery David Rook Dinis Cruz Eoin Keary Jeff Williams Jenelle Chapman Marco M. Morana Paulo Prego 검토자 Jeff Williams P.Satish Kumar Rahim Jina 한글본편집자 성윤기최용식이효상 한글본번역자 김태균 김휘영 이상신 이진영 서완석 이숙정 장상민 전영재 정진 진수희 최훈진 최만균 한글본감수자 박양환서영덕송보영이인상임성현 트레이드마크 Java 자바, Java EE 자바 EE, Java Web Server, and JSP 는 SUN 마이크로시스템의등록된 트레이드마크이다. 마이크로소프트 Microsoft 는마이크로소프트사의등록된트레이드마크이다. OWASP 는 OWASP 재단의등록된트레이드마크입니다. 다른모든제품및회사이름은각소유자의트레이드마크이다. 이문서에서사용하는용어는어떤 트레이드마크나서비스마크의유효성에영향을주지않는다. SUMMER OF CODE 2008 OWASP Summer of code (SoC) 2008 은코드리뷰가이드를후원한다. 자세한내용은 를참조하기바란다. 9

10 프로젝트공헌자 OWASP 코드리뷰프로젝트는 OWASP 아일랜드챕터설립자인 Eoin Keary 와챕터에의해시작되었다. OWASP 는새로운웹기술등장에따라신규분야를늘려나갈인재를적극적으로찾고있다. 여러분이프로젝트를위한자원봉사에관심이있거나, 또는의견, 질문또는제안이있다면, 이메일을보내기바란다. OWASP 코리아챕터의다양한프로젝트에참여하고자하는분은아래로연락주시기바랍니다. mailto: mailto: 코드리뷰팀에참여해주십시오 모든 OWASP 가이드는지속적으로변경하는위협과보안환경의변화들속에서살아있는문서이다. 우리는코드리뷰가이드프로젝트에참여하여이문서를향상시키도록도움을주는모든분들을환영한다. 이러한일을시작하는가장좋은방법은아래의링크를따라메일링리스트에가입하는것이다. 자신을소개하고, 함께하는데도움이될만한뭔가가있는지문의하기바란다. 우리는항상새로운공헌자를찾고있다. 당신이기여하고자하는주제나연구가있다면, 우리에게알려주기바란다! 10

11 OWASP 소개 오픈웹애플리케이션보안프로젝트 (OWASP) 는공개커뮤니티로기관이신뢰할수있는애플리케이션개발, 구입, 유지할수있도록공헌하고있다. OWASP 의도구, 문서, 포럼, 지부에관련된모든정보는애플리케이션보안성향상에관심있는모든사람에게무료로제공된다. 애플리케이션보안을위한가장효과적인접근방법은사람, 프로세스, 기술적사항을개선하는것이기때문에 OWASP 는위 3 가지접근법을강력히권장한다. OWASP 는 에서찾을수있다. OWASP 는새로운형태의조직이다. OWASP 는영리적압력으로부터자유롭기때문에애플리케이션보안에대한공정하고, 실질적이고, 비용효과적인정보를제공할수있다. OWASP 는잘알려진상업적보안기술을사용도록지원하지만, 어떠한기술기업과도연계되어있지않다. 많은오픈소스소프트웨어프로젝트와마찬가지로, OWASP 도협업과공개된방식으로여러가지자료를만든다. OWASP 재단은프로젝트의장기적인성공을보장하기위한비영리기구이다. 더많은정보에대해서는페이지아래의목록을참조하기바란다. 연락처 OWASP 와의연락정보 공헌 OWASP 에기여하기위한자세한방법 광고 OWASP 사이트에광고를원하는경우 OWASP 업무방법 OWASP 프로젝트및관리에대한자세한정보 OWASP 브랜드사용규칙 OWASP 브랜드사용관련한정보 OWASP 한국챕터에대한정보는 을방문하길바란다. 체계 OWASP 재단은 OWASP 커뮤니티를위해인프라를제공하는비영리 (501c3) 기구이다. 재단에서는전세계 프로젝트, 지부및컨퍼런스를지원하고, 서버와대역폭을관리한다. 라이선스 OWASP 코드리뷰가이드는 Creative Commons Share-Alike 3.0 Attribution 라이선스에따라사용된다. 이라이선스는공헌과저작권을명시하고자유롭게이용하고공개할수있도록허용한다. 모든 OWASP 자료는승인된오픈소스라이선스에따라사용된다. 여러분이 OWASP 회원기관이될경우, 여러분은또한상용라이선스를사용하여, 단일라이선스에따라모든 OWASP 자료를사용, 수정및배포할수있다. 더많은정보는 OWASP 라이선스페이지를참조하기바란다. 11

12 참여및회원 OWASP 는누구나포럼, 프로젝트, 챕터, 컨퍼런스등에참여하는것을환영한다. OWASP 는애플리케이션보안을배우거나, 네트워킹, 심지어당신의전문가로서평판을세울수있는최고의장소이다. 만약당신이 OWASP 문서가소중하다는것을알게된다면, OWASP 회원이되어서 OWASP 지원을고려해주기바란다. 추가적인정보는, Membership 페이지를참고하기바란다. 프로젝트 OWASP 의프로젝트에는애플리케이션보안의다양한측면을포함하고있다. 우리는기관들이보안코드능력을 향상하는데도움이되는문서, 도구, 교육환경, 가이드라인, 체크리스트및다른자료를제작한다. 모든 OWASP 프로젝트들에대한자세한정보는 OWASP 프로젝트페이지를참고하기바란다. OWASP 프라이버시정책 애플리케이션보안을통해조직을돕는것이 OWASP 의미션이기때문에, 우리의회원들에관해수집된개인정보를보호할권리가있다. 일반적으로우리는우리사이트를방문한방문자들의개인정보를묻거나인증을요구하지않는다. 우리는웹사이트방문자통계를계산하기위해서오직방문자인터넷주소를수집하고이메일주소는수집하지않는다. 우리는 OWASP 결과물을다운로드받을때개인으로부터이름과이메일정보를포함한확실한개인정보를요구할것이다. 이정보는어떠한서드파티에게도공개되지않으며, 다음의목적으로만사용된다. OWASP 결과물에대한긴급한수정에대한통보 OWASP 내용에대하여조언을구하거나피드백을구하기위함 OWASP 의합의과정이나 AppSec 컨퍼런스초청시 OWASP 는회원조직목록과개개인의회원목록을발간하고있다. 목록화는순전히자발적으로이루어지며선택적으로목록에서제외하도록요청할수있다. 팩스나메일을통해보내주신여러분과여러분의기관에대한모든정보는물리적으로보호된다. 만약우리개인보호정책에대하여문의사항이나우려사항이있을경우 로연락주기바란다. 12

13 코드리뷰가이드역사 코드리뷰가이드는초기테스팅가이드노력의산물이다. 초기에는코드리뷰와테스팅을하나의동일한가이드로만들기로하였다. 당시에는이방법이좋은생각으로보였지만, 보안코드리뷰라는주제는너무커져버렸고그래서하나의독립된가이드로점차발전되었다. 코드리뷰가이드는 2006 년에시작되었다. 코드리뷰팀은구성원은적었지만, 재능있고자주참여하는지원자그룹으로구성되었다. 코드리뷰팀은소프트웨어개발생명주기 (SDLC) 에통합된적절한코드리뷰기능을가진조직이보안관점에서훨신더좋은코드를만들어냈다는것을알았다. 이러한생각으로인해많은보안취약점들이다른기술을사용하는것보다코드에서더쉽게찾아지는것과같이시행착오끝에탄생되었다. 불가피하게도, 이가이드는모든언어를포괄하고있지않다. 본문서는주로.NET 과 Java, 그리고약간의 C/C++ 와 PHP 에관점을두고있다. 그러나, 책속의기법은쉽게거의모든코드환경에적용될수있다. 다행이도웹응용의보안결함은여러프로그램언어들과확실하게일치한다. 13

14 소개 코드리뷰는아마보안결점을찾아내는가장효과적인한방법일것이다. 자동화된도구와수동침투시험과함께사용한다면코드리뷰를통해애플리케이션보안을보증하기위한상당한비용효과를누릴수있다. 이문서는보안코드리뷰를수행하는프로세스를다루기보다특정한취약점에대응하는코드를살펴보는메커니즘에초점을맞추고어떻게구조화시켜처리해야하는지에대해제한적인가이드를제공한다. 수동적인보안코드리뷰는안전하지않은코드와관련된 실제위험 에대한통찰력을제공한다. 수동적인접근방식으로얻는가장가치있는일이다. 코딩점검을사람이직접하면특정한코딩관습의컨텍스트를이해하고공격가능성과사업영향도를설명할수있는심각한위험을추정할수있다. 코드에취약점이있는이유는? MITRE 는 CWE 프로젝트에서대략 700 여가지종류의소프트웨어결함을분류했다. 여기에는개발자가보안위협을야기하는실수를모두포함한것이다. 모든결함은미묘하고대부분아주교묘하다. 소프트웨어개발자는학교에서이런결함에대해배우지않으며대다수직장에서도관련문제에관해훈련을받지않는다. 보안문제는최근장비간의연결성이엄청난속도로증가하고여러기술과프로토콜을추가하면서매우중요해졌다. 새로운기술을만들어내는능력은안전하게만드는능력을훨씬능가한다. 오늘날사용되는많은기술들은대부분간단한보안점검조차받지않고있다. 사업측면에서보안에적절한시간을소요하지않는이유는다양하다. 결국이런이유가소프트웨어시장의잠재되어있는문제의근원이다. 소프트웨어는최종적으로블랙박스이기때문에안전한코드와그렇지못한코드사이의차이점에대해말하기란극히어렵다. 코드리뷰는비가시성이있기때문에구매자는안전한코드에더지불하지않으려할것이고, 벤더역시안전한코드를작성하는데추가적인노력을하지않으려할것이다. 이프로젝트의목표는소프트웨어구매자가소프트웨어보안을볼수있는안목을가지고소프트웨어시장에서변화를모색하자는데있다. 보안코드리뷰를지지하고있지만그럼에도불구하고다시제자리로돌아온다. 보안에노력을하지않으면서도듣게되는 ( 별로정당성이없는 ) 몇가지변명을보자. 우리는 ( 내가알고있는한 ) 해킹을당한적이없기때문에보안이필요없다. 우리는애플리케이션을보호하는방화벽을가지고있다 우리는애플리케이션을공격하지않을것이라고직원들을믿는다. 14

15 지난 10 년간 OWASP 코드리뷰프로젝트를진행한팀은수천개의애플리케이션을점검했고개별애플리케이션에심각한취약점이있다는것을발견했다. 보안결함을찾기위하여코드리뷰를하지않는다면, 애플리케이션에문제가생길가능성은실제로 100% 다. 여전히많은조직은코드보안성을외면하고있다. 이런사람들에게우리가실제로알고있는럼스펠드 (Rumsfeld) 의숨겨진사실을설명해줄수있다. 회사에서위험을감수하는결정을해야한다면우리는당신을완전히지지한다. 하지만위험감수가무엇인지모른다면주주나고객모두에게책임을지지않고있는것이다. "... 우리는알려져있는사실들이있다는것을알고있다. 우리가알고있는것이있다. 우리는알려져있지만모르는것이있다는것을알고있다. 다시말해우리가모르는무언가가존재한고있다는것을알고있다. 하지만알려지지않은모르는것이존재한다. 우리가알지못한다는사실도모르는것이다. " - 도널드럼스펠드보안코드리뷰란? 보안코드리뷰는애플리케이션에적절한보안통제가존재하고, 원하는방식대로동작하며, 적절한곳에서처리되는것을보증하는감사프로세스다. 코드리뷰는애플리케이션이주어진환경에서 자체방어 를할수있도록개발되었는지보증하는방식이다. 보안코드리뷰는안전한애플리케이션개발자가안전한개발기법을따르는지보증하는방법이다. 가장최우선일반규칙은애플리케이션이적절한보안코드리뷰를받은후개발된코드에관련해침투테스트에서추가적인애플리케이션취약성이발견되지않는것이다. 모든보안코드리뷰는사람의노력과기술지원이함께진행된다. 한쪽범위는능숙하지못한사람이문자편집기를사용할때이며다른반대쪽범위는보안전문가가고급정적분석도구를사용할때라고볼수있다. 불행히도애플리케이션보안도구를효율적으로사용하려면상당히전문적인수준의지식을요구한다. 이작업을수행할수있는도구를사용할수있지만항상사람의검증이필요하다. 도구는문맥을이해하지못하는데이것이바로보안코드리뷰의핵심이다. 도구는많은양의코드를평가하여가능한문제점을찾아내는데능하지만, 사람은그게진짜문제인지실제공격가능한지모든결과에대해검증하고조직에위험으로작용하는지산출할필요가있다. 직접점검을통해자동화된도구가간단히알아낼수없는주요사각지대도확인해야한다. 15

16 준비 기본점검사항 코드리뷰기준을효과적으로점검하기위해서점검팀이애플리케이션의사업적용도와주요사업영향을이해하는것이매우중요하다. 이를통해심각한취약점을찾아내는방법을안내할것이다. 팀은서로다른위협에이전트, 동기, 그리고애플리케이션에잠재적으로어떻게공격할수있는지식별해야만한다. 모든정보는애플리케이션보안에관련된모든정보를나타내는상위수준의위협모델로합쳐질수있다. 점검자의목표는주요위험이적절히동작하는보안통제에의해적절히명시되어적절한장소에서사용되는지검증하는일이다. 점검자는애플리케이션설계단계에개입하는것이이상적이지만이런경우는거의없다. 대부분점검팀은거대한코드를보고잘정리해가용한시간내가장잘이용해야한다. 코드리뷰를수행하는것을감사하는것과같은같은느낌일수있는데개발자는감사받는일을싫어한다. 한가지접근방법은점검자, 개발팀, 사업대표, 그리고기존이해관계자사이에서협력하는분위기를만들어내는것이다. 개발팀에서잘협조받고싶다면경찰이아닌조언자이미지로비춰지는것이매우중요하다. 개발팀과성공적으로신뢰를구축한보안코드리뷰팀이신뢰받는조언자가될수있다. 대부분의경우보안인력이라이프사이클초기에개입되어이끌어야보안비용을현저히낮출수있다. 시작하기전 : 검토자는다음사항에익숙해야한다. 1. 코드 : 사용한개발언어, 기능과보안관점에서언어의이슈사항, 경계해야할문제점과보안및성능관점에서모범사례 2. 컨텍스트 : 애플리케이션의동작여부및환경을검토해야한다. 모든보안은보호하려는컨텍스트안에있다. 사과판매용애플리케이션에군사기준의보안메커니즘을추천하는건과하다고볼수있으며목적을벗어난것이다. 어떤유형의데이터를조작하고처리하며해당데이터가유출될경우회사의피해가어느정도인지확인해야한다. 컨텍스트는안전한코드리뷰와위험평가의 성배 (Holy Grail) 다. 추후좀더살펴보자. 3. 사용자 : 애플리케이션의의도된사용자, 외부에노출되는지 신뢰된 사용자내부에서사용되는가? 애플리케이션이다른시스템 ( 장비 / 서비스 ) 와연결되는가? 사람이애플리케이션을이용하는가? 4. 중요성 : 애플리케이션의이용성또한중요하다. 애플리케이션이 정상작동하지않거나 상당한또는짧은시간동안중지된다면조직에얼마나큰영향을미치는지? 16

17 발견 : 정보수집 점검팀은효율성을높이기위해애플리케이션에관한정보를수집해야한다. 정보는점검순위에사용해위협모델로통합해야한다. 이정보는빈번히설계문서, 사업요구사항, 기능명세, 테스트결과와같은문서에서알수있다. 하지만대부분실제프로젝트에서문서는유효기간이없고변경이되지않기때문에거의대부분의보안정보는적합하지않다. 따라서정확한최신정보를얻기위해서는개발자와애플리케이션설계담당자와얘기하는일이다. 개발팀입장에서주요보안고려사항과통제수단에대한기본정보를공유하는것으로충분하므로긴시간의회의를가질필요가없다. 실제동작중인애플리케이션을살펴볼수있으면애플리케이션이의도한대로작동중인지알수있으므로점검팀에매우도움이될것이다. 또한사용하는코드와라이브러리구조에대한개괄적인내용을파악하면점검팀이시작하는데도움이된다. 애플리케이션에관한정보를어떤형태로든얻지못한다면팀은코드를시험해애플리케이션이어떻게동작하는지에대해확인하고정보를공유하는데시간을할애해야할것이다. 컨텍스트, 컨텍스트, 컨텍스트 보안코드리뷰는코드를단순히검토하는일이아니다. 중요한사실은코드리뷰를하는이유가정확히돈, 지적자산, 영업비밀, 생명또는데이터와같은위탁정보와자산을보호하고있는지보증하는데있다는사실을기억하는것이다. 애플리케이션이의도한대로동작하는컨텍스트는잠재위험을설정하는데매우중요한문제이다. 점검자가비즈니스상의컨텍스트를이해하지못하면가장중요한위험을발견하지못할수도있고업무에별로중요치않은문제에만초점을맞출수도있다. 보안코드리뷰준비시에관련정보를포함한상위수준의위협모델을준비해야한다. 이후장에서전체적으로 설명하겠으나여기서주요영역을간단히살펴보자. 위협요소 공격접점 ( 외부및백엔드인터페이스 ) 가능한공격 보안통제필수요구사항 ( 공격가능성을막고회사정책준수 ) 잠재적인기술영향 주요사업영향 컨텍스트를정의하면다음정보를알수있다. 애플리케이션의사업중요성수립 애플리케이션컨텍스트범위설정 개체간신뢰관계수립 17

18 잠재적인위협과가능한통제수립 점검팀은다음과같이개발팀에서정보를얻기위한간단한질문을이용할수있다. 애플리케이션에어떤유형의 / 얼마나민감한정보 / 자산이있습니까? 애플리케이션에서보안과위험을평가하는핵심이다. 정보가얼만큼중요한가? 어떤방식이든정보를유실할경우사업에어떤영향을받게되는가? 애플리케이션이내부용입니까아니면외부로통합니까?, 누가애플리케이션을이용하며그들은신뢰하는사용자입니까? 내부 / 신뢰된사용자에의한공격은알려진것보다보안상잘못된인식을가질수있다. 이말은애플리케이션이식별된사용자숫자에제한되어사용하는지여부이지이사용자가모두적절한방식으로행위를한다는의미는아니다. 애플리케이션호스트위치가어디입니까? 사용자는인증없이 DMZ 를통해 LAN 구간으로진입하지못하게되어있다. 내부사용자역시인증이필요하다. 비인증은비추적성과같은말이며감사추적에약점이생긴다. 내외부사용자가있다면보안관점에서차이점은무엇인가? 내부사용자를외부사용자와어떻게구별할것인가? 인가는어떤방식으로운영되고있는가? 이애플리케이션이사업에얼마만큼중요합니까? 18

19 애플리케이션중요도가낮은지, 기업에핵심적인 A 계층 / 매우중요한애플리케이션인가? 좋은웹애플리케이션개발정책에따라추가적인요구사항이있으며또한다른사업의다른애플리케이션에 추가적인요구사항이있다. 코드관점에서도해당정책을따르고있는지판단하는건분석가의몫이다. 유용한 접근방식은팀이체크리스트를가지고임의의웹애플리케이션과관련된문항을점검하는것이다. 체크리스트 체크리스트가컨텍스트를제공하기위해올바른문항을가지고있다면개발팀이작성하는일반적인체크리스트 정의는매우가치가크다. 체크리스트는개발자가시도하거나생각하는보안수준의좋은척도다. 체크리스트는 다음과같은가장중요한보안통제와취약점분야를포함해야한다. 데이터유효성인증세션관리인가암호오류처리로깅보안구성네트워크아키텍쳐 19

20 SDLC 에서보안코드리뷰 보안코드리뷰는정형화수준에따라매우다양하다. 검토방법은동료를초대하여취약점을발견하도록것과같이비정형적일수도있고, 역할과책임, 그리고정형적인수치와품질측정프로그램을정의하여훈련된팀과함께하는정형적으로소프트웨어를점검할수도있다. 칼위그너 (Karl Wiegers) 는소프트웨어상호점검에가장비정형적인방식에서가장정형적인방식까지다음과같이 7 개점검프로세스항목을만들었다. 1. 애드혹 (Ad hoc) 리뷰 2. 패스어라운드 (Passaround) 3. 페어프로그래밍 (Pair programming) 4. 워크스루 (Walkthrough) 5. 팀리뷰 6. 인스펙션 (Inspection) SDLC 전과정에서애플리케이션보안컨설턴트가개입해야한다. 생명주기전체에서보안을수행하는일은 설계우선 보안노력이나단일화된사전소프트웨어보안검토보다훨씬더효과적이다. 일정간격으로개입하는이유는잠재적인문제점이개발생명주기에서일찍탐지되어비용이적게들기때문이다. 시스템개발생명주기 (SDLC) 와보안코드리뷰를결합하면전반적으로개발되는코드품질은굉장히향샹되는결과를가져온다. 보안코드리뷰는특효약은아니지만건전한애플리케이션개발습관의일부다. 애플리케이션프로그램보안에대한다층방어 (defense-in-depth) 접근방식의한단계로서고려해야한다. 보안코드리뷰는안전한소프트웨어개발접근의초석이기도하다. SDLC 에이단계를통합하면복잡하고비용이추가되는것으로보이지만, 장기적인시각으로보면오늘날사이버공간에서효과적이고신뢰를쌓으면서비즈니스를할수있는최고의방법이다. 폭포수 SDLC 예제 1. 요구사항정의 1. 애플리케이션보안요구사항 2. 아키텍쳐와설계 1. 애플리케이션보안아키텍쳐와위협모델 3. 개발 1. 보안코딩사례 2. 보안테스팅 3. 보안코딩점검 20

21 4. 테스트 1. 침투테스팅 5. 구현 1. 안전한설정관리 2. 안전한구현 6. 유지보수 애자일보안방법론예제 1. 계획 1. 보안이해관계자내용파악 2. 보안통제파악 3. 보안테스트사례파악 2. 스프린트 1. 안전한코딩 2. 보안테스트사례 3. 상호보안점검 3. 개발 1. 보안성입증 ( 침투시험과보안코드리뷰 ) 21

22 보안코드리뷰범위 공격접점의이해 모든입력값은그반대편에서동등한 ( 잘정렬된 ) 출력값을갖는다 보안코드리뷰의주된부분은공격접점을분석하는것이다. 애플리케이션은입력값을받아서어떤종류의출력값을만들어낸다. 애플리케이션을공격하는것은입력값흐름을이용하는것이고, 애플리케이션이예상치못한방향으로실행되면서발생한다. 따라서우선적으로코드의모든입력값을검증하는것이필요하다. 입력값의예는다음과같다. 브라우저입력값쿠키속성파일외부프로세스데이터입력서비스응답플랫파일 (Flat files) 커맨드라인파라미터환경변수 22

23 공격접점조사시동적및정적데이터흐름을분석한다. 매개변수, 메소드호출및데이터교환매커니즘에요구되는보안을수행한다면, 워크플로우전체를통틀어언제어디에변수가설정되고그변수가어떻게사용되는지, 객체와매개변수의속성이프로그램내의다른데이터에어떻게영향을미치는지를정의한다. 애플리케이션내의모든트랜잭션들은각각을호출하는적절한보안기능에따라식별되고분석되어야한다. 트랜잭션분석이수행되는동안분석되는대상영역은다음과같다. 모든신뢰되지않은출처로부터의데이터 / 입력값검증 인증 세션관리 인가 암호 ( 미사용데이터및전송데이터 ) 오류처리 / 정보누출 감사기록 보안코드환경 리뷰대상에대한이해 : 현재대부분의애플리케이션은프레임워크를이용해서개발된다. 이러한프레임워크는잡다한많은일을대신할수있어개발자의일을줄여준다. 따라서개발팀에서개발한객체는프레임워크의기능을확장시킨것이다. 여기서무엇보다도중요한것은주어진프레임워크와애플리케이션에대한지식으로해당프레임워크와애플리케이션이실행된다는것이다. 많은트랜잭션기능은개발자코드에서는잘보이지않고부모클래스에서다뤄질것이다. 분석가는눈앞에놓인프레임워크를인지하고해당프레임워크에대해능숙해야한다. 예제 : 자바 : 스트럿츠에서 struts-config.xml 파일과 web.xml 파일은애플리케이션의트랜잭션기능을검토하기위한 핵심포인트이다. <?xml version="1.0" encoding="iso "?> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" " <struts-config> 23

24 <form-beans> <form-bean name="login" type="test.struts.loginform" /> </form-beans> <global-forwards> </global-forwards> <action-mappings> <action path="/login" type="test.struts.loginaction" > <forward name="valid" path="/jsp/mainmenu.jsp" /> <forward name="invalid" path="/jsp/loginview.jsp" /> </action> </action-mappings> <plug-in classname="org.apache.struts.validator.validatorplugin"> <set-property property="pathnames" value="/test/web-inf/validator-rules.xml, /WEB-INF/validation.xml"/> </plug-in> </struts-config> struts-config.xml 파일은각각 HTTP 요청에대한행위매핑 (action mapping) 이있는반면, web.xml 파일은 배치설명서 (DD, deployment descriptor) 를포함하고있다. 예 : 스트럿츠프레임워크는입력데이터를검증하기위하여정규표현식을이용하는검증엔진을보유하고있다. 검증엔진의장점은코드에서각각의폼빈 (form bean) 에입력될필요가없다는것이다. ( 폼빈은 HTTP 요청으로부터데이터를받는자바객체이다.) 검증엔진은스트럿츠내에서기본으로활성화되어있지않다. 활성화하려면, struts-config.xml 의빨간색으로표시된 <plug-in> 절에반드시 plug-in 이정의되어야한다. 정의된속성 (property) 은스트럿츠프레임워크는사용자정의검증규측이정의되었으며 (validation.xml), 이에해당하는실제규칙이정의되었다는것을 (validation-rules.xml) 알려준다. 스트럿츠프레임워크를이해하지못해도자바코드에대한간단한감사를통해어떤검증절차도없는경우와 정의된규칙과자바기능사이의관계가없는경우를걸러낼수있다. 위코드에서파란색으로표시된부분의행위매핑은요청을받아들이는애플리케이션이취하는행위를 정의한다. 여기서 URL 이 /login 을포함할때 LoginAction 쉘이호출되는것을확인할수있다. 행위 매핑으로부터외부입력값을받았을때해당애플리케이션이실행할트랜잭션을볼수있다..NET: 24

25 ASP.NET/ IIS 애플리케이션은애플리케이션설정상태를유지하기위하여 web.config 라는이름의 XML기반설정파일을갖고있다. 이는인증, 인가, 오류페이지, HTTP 설정, 디버그설정, 웹서비스설정등의문제를설정할수있다. 이러한파일에대한지식없이트랜잭션분석은어렵고, 부정확할수있다. web.config 파일을웹애플리케이션가상디렉토리의최상위경로에위치시킬수있다. 설정파일이없다면, 기본설정은 machine.config 파일이설정에사용된다. 설정파일이있으면, web.config 파일의어떤설정에 관계없이기본설정을오버라이드할것이다. web.config 파일예시 : <authentication mode="forms"> <forms name="name" loginurl="url" protection="encryption" timeout="30" path="/" > requiressl="true " slidingexpiration="false"> <credentials passwordformat="clear"> <user name="username" password="password"/> </credentials> </forms> <passport redirecturl="internal"/> </authentication> 이설정파일예제의내용은다음과같다 : authentication mode: 기본인증모드는 ASP.NET 폼기반의인증을사용한다. loginurl: 유효한인증쿠키가없을때, 로그온을위해 HTTP요청이리다이렉트되는 URL을지정한다. protection: 쿠키가 3DES 혹은 DES를사용해암호화되도록지정한다. 하지만쿠키에서 DV가수행되지는않는다. 평문공격에주의해야한다. timeout: 쿠키가만료되는시간 ( 분 ) 여기에서중요한점은대부분의중요보안설정이코드에는없으며, 프레임워크설정파일내에서가능하다. 그래서프레임워크기반의애플리케이션을리뷰할때프레임워크에대한지식은무엇보다도중요하다. 25

26 애플리케이션위협모델링 소개 위협모델링은애플리케이션보안분석을위한하나의방법이다. 이는애플리케이션과관련보안위헙을식별, 정량화가가능한가능한구조화된접근법이다. 위협모델링은코드리뷰를위한방법이아니라보안코드리뷰절차를보완한다. SDLC 내위협모델링을포함하면애플리케이션이초기부터보안을고려해서개발되었는지확인할수있다. 이는위협모델링과정의일부분으로써생성된문서로검토자에게해당시스템을전반적으로이해할수있도록도와준다. 이는검토자가애플리케이션의입력지점이어디해위치해있는지, 또각입력지점과관련된위협들은어떤것이있는지알수있도록한다. 위협모델링은이제는새로운개념이아니지만수년간에걸쳐위협모델리에대한인식이변하였다. 현재위협모델링은시스템을방어하는입장과반대로, 잠재적공격자의관점에서시스템을바라보고있다. 마이크로소프트는지난몇년간이프로세스에대해강력하게지지해왔다. 마이크로소프트는위협모델링을자사제품의보안성향상을위한 SDLC 의핵심요소로만들어왔다. 기존의애플리케이션과같은 SDLC 외부에서소스코드를분석할때, 위협모델링을통해깊이있는분석과폭 넓은분석을수행하여소스코드분석의복잡도를줄일수있다. 동등한관점으로모든소스코드를리뷰하는 대신에, 고위험군에속한위협모델링의구성요소에대해서는우선적으로보안코드리뷰를할수있다. 위협모델링절차는 3 단계로나뉜다. 1 단계 : 애플리케이션분리. 위협모델링의첫단계는애플리케이션이외부개체와어떻게반응하는지및애플리케이션에대한이해를얻는것과관련이있다. 이는잠재적인공격자관점에서애플리케이션과어떻게상호작용하는지를확인하기위한입력지점을확인하는것과, 공격자가관심있게볼만한항목이나영역, 애플리케이션이외부개체에대해접근을허용할신뢰도수준을확인하는것에대해해당애플리케이션이어떻게사용되는지이해하기위한사용자케이스생성을포함한다. 이정보는위협모델 (Threat Model) 문서에명세되어있으며, 해당애플리케이션에대한데이터플로우다이어그램 (Data Flow Diagrams, DFDs) 을제작하는데에도사용된다. DFD 는시스템전체의다양한경로를우선순위영역을하이라이트하여보여준다. 2 단계 : 위협결정및순위화. 위협범주화방법론을이용하여위협을확인하는것이중요하다. STRIDE 와같은위협범주가사용될수있고, 혹은감사, 인증, 인가, 설정관리, 통신및스토리지내의데이터보호, 데이터검증, 에외관리와같이위협을정의하는애플리케이션보안프레임 (Application Security Frame; ASF) 를사용할수있다. 위협범주화의목표는공격자로부터의위협과 (STRIDE) 방어하는관점모두에서위협을확인할수있다. 1 단계에서도출된 DFD 는데이터소스, 프로세스, 데이터플로우, 사용자와의상호작용과같은공격자의관점에서의잠재적인위협대상을확인하는데도움이된다. 이러한위협은위협대상에대한위협트리의최상위에서확인할수있다. 위협을목표로하는하나의트리가있다. 방어하는관점에서, ASF 범주화는각종 26

27 위협과같은보안관제의취약성을확인하는데도움이된다. 예시로제시된공통적인위협목록은이러한위협을확인하는데도움이된다. 적절한사용과오용사례들은현존하는보안장치들이어떻게우회될수있는지, 또는이러한보안이적용되었을때결함이어디에존재하는지분명히보여줄수있다. 각위협에대한보안위험도측정은 DREAD 와같은값기반의위험도모델이나발생가능성이나영향도와같이일반적위험요소들을기반으로하는비교적덜주관적인질적위험모델을이용해측정할수있다. 3 단계 : 대응방안과완화방안을강구하라. 특정위협에대한보안결함은바로대응해야할정도로위협에노출된취약점을내포하고있다. 이러한대응책은위협대응매핑목록을사용해인증될수있다. 일단어떤보안위협이위험도순위에올라가면위협의최상위부터최하위까지정렬이가능하며, 인증된대응방안을적용함으로써위와같은위협의대응을위한완화작업에대해우선순위를매길수있다. 위험완화전략에는위험을제거하고감소시키는사업적효과로인한위협을평가하는것도포함시켜야한다. 다른옵션에는보상을통제하고해당위협의대상이되는사용자에게이를알리며, 위협을제거하거나최소한더나은옵션을취하기위해, 위험을감수했을때의사업적효과가적합한지추정하는것을포함시켜야한다. 위의각단계를수행한후에는문서화된다. 결과문서는해당애플리케이션에대한위협모델이다. 이가이드는위협모델링의개념을설명하기위한예시로사용될것이다. 본예제는대학도서관웹사이트로, 이를이용해위의 3 단계각각을학습하게될것이다. 본가이드의마지막에서여러분들은대학도서관웹사이트의위협모델을만들게된다. 위협모델링과정의각단계는아래에자세히서술하겠다. 애플리케이션분리 이단계의목표는해당애플리케이션을이해하고, 어떻게애플리케이션이외부개체와상호작용하는지이해하는것이다. 정보수집하고문서화를통해목표를달성할수있다. 올바른정보가수집되었는지확인하도록명확하게정의된구조를이용해정보를수집하는프로세스를수행한다. 이구조는물론어떻게정보가문서화되어야하고위협모델을산출할지도정의한다. 위협모델정보 위협모델의첫번째항목은해당위협모델에관련된정보이다. 다음과같은것들이포함되어있어야한다. 1. Application Name 애플리케이션이름 2. Application Version 애플리케이션버전 3. Description 해당애플리케이션의상위레벨설명 4. Document Owner 본위협모델링문서의소유자 5. Participants 본애플리케이션위협모델링프로세스참여자 6. Reviewer 위협모델검토자 27

28 예 : < 애플리케이션이름 > 위협모델정보 애플리케이션 버전 1.0 설명 : 대학도서관웹사이트는사서및도서관이용자 ( 학생및교직원 ) 에게온라인서비스를제공하는최초로구현된웹사이트이다. 웹사이트의첫번째구현이므로, 기능은제한된다. 애플리케이션의 3 종류의사용자가있다. 1. 학생 2. 교직원 3. 사서교직원과학생은로그인하고도서검색을할수있으며, 교직원은도서요청을할수있다. 사서는로그인하고, 도서추가, 사용자추가및도서검색을할수있다. 문서작성자 : 참가자 : 검토자 : David Lowry David Rook Eoin Keary 외부종속성 외부종속성은애플리케이션에위협을야기할수있는외부코드에서가져온요소들을의미한다. 이런요소들은일반적으로어떤조직의통제하에있겠지만, 개발팀이통제할수있는것은아니다. 외부종속성을조사할때첫번째로살펴볼것은해당애플리케이션이제품환경에서어떻게사용될것이고무엇을필요로할것인가이다. 이는애플리케이션이의도대로실행되는지혹은그렇지않은지확인하는것도해당된다. 예를들면해당기관의표준을강화시키고방화벽의뒤에서동작시킬목적으로서버상에서동작하는애플리케이션의경우, 이러한정보는외부종속성절에문서화되어야한다. 외부종속성은다음과같이문서화한다. 1. ID 외부종속성에인가된고유 ID 2. 설명 외부종속성의텍스트설명 28

29 예 : 외부종속성 ID 설명 1 대학도서관웹사이트는아파치를실행하는리눅스서버에서실행된다. 서버는대학의서버보안강화 기준에따라보안성이강화된다. 즉최신의운영체제의애플리케이션과애플리케이션보안패치를 포함한다. 2 데이터베이스서버는 MySQL 이며리눅스서버에서실행된다. 서버는대학의서버보안강화기준에따라 보안성이강화된다. 즉최신운영체제의애플리케이션과애플리케이션보안패치를포함한다. 3 웹서버와데이터베이스서버는사설네트워크상에서연결된다. 4 웹서버는방화벽뒤에있으며, TLS 를통해서만통신이가능하다. 입력지점 입력지점은잠재적으로공격자가애플리케이션과상호작용하거나데이터를삽입할수있는인터페이스를의미한다. 잠재적인공격자가공격하기위해서는반드시입력지점이존재한다. 애플리케이션내의입력지점은계층화될수있는데, 예를들면웹애플리케이션의각웹페이지는다수의입력지점을갖고있다. 입력지점은다음과같이문서화되어야한다 : 1. ID 입력지점에허용된고유 ID. 이 ID 를이용해서식별된어떤위협또는취약점을가지고있는입력 지점은상호참조한다. 계층입력지점의경우 major.minor 표기법이사용되어야함. 2. 이름 입력지점과그목적을확인할서술명. 3. 설명 입력지점에서발생하는인터랙션이나프로세싱을자세하게글로묘사. 4. 신뢰수준 입력지점에요구되는접근수준은여기에문서화된다. 이는나중에문서에정의되는신뢰 수준과상호참조되어야한다. 예 : 입력지점 ID 이름설명신뢰수준 29

30 1 HTTPS 포트 대학도서관웹사이트는 TLS 를통해서만접근 가능하다. 대학도서관웹사이트에있는모든 페이지는이입력지점에계층화되어있다. (1) 익명웹사용자 (2) 정상로그인사용자 (3) 비정상로그인사용자 (4) 사서 (1) 익명웹사용자 1.1 도서관메인 페이지 대학도서관웹사이트의시작페이지는모든 사용자의입력지점이다. (2) 정상로그인사용자 (3) 비정상로그인사용자 (4) 사서 (1) 익명웹사용자 1.2 로그인 페이지 학생, 교직원및사서는유스케이스하나를 실행하기전에반드시대학도서관웹사이트에 로그인해야한다. (2) 정상로그인사용자 (3) 비정상로그인사용자 (4) 사서 로그인기능 로그인기능은데이터베이스와비교하여, 사용자를인증한다. (2) 정상로그인사용자 (3) 비정상로그인사용자 (4) 사서 1.3 검색엔트리 페이지 검색어를입력하는데사용되는페이지. (2) 정상로그인사용자 (4) 사서 자산 시스템에는해커가관심을가질만한무언가를반드시갖고있다. 이런흥미로운아이템들과영역을자산이라고정의한다. 자산은본질적으로위협목표가되는데, 즉이런것들이위협이존재하는이유이다. 자산은물리적자산과추상적자산모두가될수있다. 예를들면, 애플리케이션자산은클라이언트목록및클라이언트의개인정보가될것이다. 이런것들이물리적자산이다. 추상적자산은조직의평판이될수있다. 자산은다음과같이위협모델에서문서화된다. 30

31 1. ID - 유일한 ID는각자산을식별하기위해사용된다. ID는위협이존재하는자산또는정의된취약점을상호참조하는데사용 2. 이름 - 자산을식별하도록설명한이름 3. 설명 - 어떤자산을왜보호해야하는지를설명 4. 신뢰수준 입력지점에접근하기위해필요한접근레벨은문서화되어있다. 이것들은다음단계에서정의된신뢰수준과함께상호참조 31

32 예 : 자산 ID 이름설명신뢰수준 1 도서관 사용자및 사서 학생, 교수진및사서와관련된자산 (2) 정상로그인 사용자 1.1 상세 사용자 로그인 대학도서관웹사이트에로그인하기위해학생또는 교수진들이사용하는로그인자격인증 (4) 사서 (5) DB 서버관리자 (7) 웹서버사용자프로세스 (8) DB 읽는사용자 (9) DB R/W 사용자 (4) 사서 (5) DB 서버관리자 1.2 상세사서 로그인 대학도서관웹사이트에로그인하기위해사서들이 사용하는로그인자격인증 (7) 웹서버사용자프로세스 (8) DB Read 사용자 (9) DB R/W 사용자 1.3 개인정보 대학도서관웹사이트는학생, 교직원, 사서와관련된 개인정보를저장할것이다 (4) 사서 (5) DB 서버관리자 (6) 웹사이트관리자 (7) 웹서버사용자프로세스 (8) DB Read 사용자 (9) DB R/W 사용자 2 시스템하부시스템과관련된자산 32

33 대학도서관 웹사이트 2.1 가용성대학도서관 대학도서관웹사이트는학생들, 교수진, 사서들이 하루 24 시간언제든지접근할수있어야한다. (5) DB 서버관리자 (6) 웹사이트관리자 웹사이트의 가용성 2.2 웹서버사용자로코드실행권한 웹서버사용자로서웹서버에서소스코드를실행할 수있다. (6) 웹사이트관리자 (7) 웹서버사용자 프로세스 DB 열람 / 등록 SQL 을실행하는능력. 데이터베이스에서 Select (5) DB 서버관리자 2.3 사용자로서 쿼리를수행하여, 대학도서관에저장된정보를 (8) DB Read 사용자 SQL 실행 검색한다. (9) DB R/W 사용자 권한 DB R/W SQL 을실행하는능력. 데이터베이스에대한열람, 2.4 사용자로서 SQL 실행 등록및수정쿼리를실행하여, 대학도서관데이터베이스에저장된정보에읽기및쓰기접근 (5) DB 서버관리자 (9) DB R/W 사용자 권한 권한이있다. 3 웹사이트대학도서관웹사이트와관련된자산 3.1 로그인 세션 대학도서관웹사이트에대한사용자로그인세션이다. 사용자는학생, 교직원또는사서이다. (2) 정상로그인 사용자 (4) 사서 3.2 DB 서버 접근 데이터베이스운영을위한접근권한을갖고, 모든 사용자에대한접근권한과데이터베이스내의모든 데이터에대한접근권한을갖는다. (5) DB 서버관리자 3.3 사용자 생성권한 학생, 교수진, 사서들개개인이시스템에신규계정을 생성할수있도록한다 (4) 사서 (6) 웹사이트관리자 3.3 감사 데이터 감사데이터는대학도서관애플리케이션내에서 사용자들로부터발생한모든감사가능한이벤트들을 (6) 웹사이트관리자 33

34 접근보여준다. 신뢰수준 신뢰수준은애플리케이션이외부객체들에게허용하는접근권한을나타낸다. 신뢰수준은입력지점과 자산을상호참조한다. 이를통해각각의입력지점에서요구되는접근권한과각각의자산과상호작용하는 접근권한을정의한다. 신뢰수준은위협모델에아래와같이문서화되어있다 : 1. ID - 각신뢰수준에부여된유일한식별자. 입력지점, 자산과함께상호참조된다. 2. 이름 - 신뢰수준을가진외부객체를식별하기위한이름 3. 설명 - 신뢰수준을가진외부객체에대해자세히설명된본문 예 : 신뢰수준 ID 이름설명 1 익명웹사용자 정당한자격증명을제공하지않고대학도서관웹사이트에접속된 사용자 2 정상로그인사용자정상적인로그인을통해대학도서관웹사이트에접속한사용자 3 비정상로그인 사용자 비정상로그인을시도하여대학도서관웹사이트에접속한사용자 4 사서 사서는도서관웹사이트에신규사용자를생성할수있으며 그들의개인정보를열람할수있다. 5 DB 서버관리자 DB 서버관리자는대학도서관웹사이트 DB 에읽기또는쓰기가 가능하다 6 웹사이트관리자웹사이트관리자는대학도서관웹사이트설정을할수있다 7 웹서버사용자웹서버에서코드를실행하고데이터베이스서버에대해하고 34

35 프로세스데이터베이스서버를대상으로자신을인증하는프로세스 / 사용자이다. 8 DB Read 사용자 DB 사용자계정은 DB 읽기접근을위해사용된다. 9 DB R/W 사용자 DB 사용자계정은 DB 읽기및쓰기접근을위해사용된다. 데이터흐름도 데이터흐름도 (DFD:Data Flow Diagram) 를이용해서수집된모든정보를통해애플리케이션에대해정확하게모델링할수있다. DFD는애플리케이션프로세스데이터에대한시각적인표현을제공하여애플리케이션에대해더쉽게이해할수있도록한다. DFD의장점은애플리케이션을통해데이터가이동하는방법과데이터가이동할때발생하는점에대해서초점을두고있다. DFD는계층구조이기때문에애플리케이션을서브시스템과낮은수준의서브시스템으로분해하는데사용될수있다. 높은수준의 DFD를통해애플리케이션모델링범위를명확하게할수있다. 낮은수준의반복은특정데이터를프로세싱할때해당프로세스에초점을맞추도록해준다. DFD에서는위협모델링을위해사용되는기호들이있다. 이들은다음과같다. 외부개체 외부엔터티모양은입력지점을통해연동되는애플리케이션외부의개체를표현하는데사용된다. 되어진다 프로세스 프로세스모양은애플리케이션내의데이터를처리하는일을표현한다. 해당태스크는데이터를처리하거나 데이터에기반한동작을수행할것이다. 35

36 다중프로세스 다중프로세스모양은서브프로세스집합을보여준다. 다중프로세스는다른 DFD 에서서브프로세스로나뉠수 있다. 데이터저장소 데이터저장소모양은데이터가저장된위치를나타내는데사용된다. 데이터저장소는데이터를수정할수 없으며오직데이터를저장한다. 데이터흐름 데이터흐름모양은애플리케이션내의데이터이동을나타낸다. 데이터이동의방향은화살표에의해표현된다. 권한범위 권한범위모양은데이터가응용프로그램을통해이동할때권한수준이변경되는것을나타낸다. 36

37 예 : 대학도서관웹사이트에대한데이터흐름다이어그램 37

38 대학도서관웹사이트에대한사용자로그인데이터흐름다이어그램 위협결정기준및순위화 위협분류 위협을결정하기위한첫번째단계는위협을분류하는것이다. 위협분류를통해해당하는예와함께위협분류 집합을제공하며, 이를통해구조적및반복적으로위협이체계적으로애플리케이션에서식별될수있다. STRIDE STRIDE 와같은위협분류는아래와같이공격목적을분류하여위협식별하는데유용하다. 스푸핑 (Spoofing) 조작 (Tampering) 부인 (Repudiation) 38

39 정보공개 (Information Disclosure) 서비스거부 (Denial of Service) 권한상승 (Elevation of Privilege) 이분류의일반적으로위협목록과보안통제목록에대한예는아래와같다. STRIDE 위협목록 타입예시보안통제 스푸핑불법적인접근과다른사용자의 ID, 패스워드와같은인증정보를사용한다인증 조작 데이터를악의적인목적으로예를들어데이터베이스에저장된지속적인데이터를 변경및수정하고, 인터넷과같은공개된네트워크를통해두컴퓨터사이에서 통신하는데이터를변경한다. 무결성 부인보안에취약한시스템내에서불법적인행위를수행한다. 부인방지 정보공개허가되지않은파일을열람하거나전송되는데이터를열람한다. 기밀성 서비스거부웹서비스를일시적으로중단시켜정상적인사용자의접근을거부한다. 가용성 권한상승정보에대한비인가된접근을위해권한획득을시도하거나시스템을손상시킨다. 인가 보안통제사항 기본위협원과비즈니스영향이분석되면, 코드검토팀은비즈니스영향을주는위협원을막기위한대응방안을 식별해야한다. 코드리뷰의주안점은보안통제사항들이필요한부분에서알맞게동작하는것을보장하는 것이다. 아래점검항목은모든발생가능한위험을식별하는데도움이된다. 인증 : 모든내부, 외부연결 ( 사용자와객체 ) 이적절하고충분한인증절차를통해이루어지도록확인한다. 또한인증절차가우회되지않도록확인한다. 모든페이지가인증을수행하는지확인한다. 인증관련정보또는민감정보가전달될때마다, HTTP "POST" 메소드를통한정보들만처리되며, HTTP "GET" 메소드는허용되지않도록확인한다. 39

40 어떤페이지는비즈니스또는개발팀에의해인증을우회하여외부에서접근이가능한것으로간주하며, 이에대한리뷰및보안취약점평가를수행한다. 인증정보가평문으로전송되지않도록확인한다. 개발및디버그관련백도어가제품코드에포함되어있지않는지확인한다. 인가 : 인가절차가존재한다. 애플리케이션이정확하게사용자유형과권한을정의한다. 운영에필요한최소한의권한이사용된다. 인가절차적절하게수행되고, 장애안전성을보장하고, 우회되지않는다. 모든요청에대해서인가절차가수행된다. 개발및디버그관련백도어가제품코드에포함되어있지않다. 쿠키관리 : 민감한정보를포함하지않는다. 쿠키조작을통한비인가활동이수행되지않는다. 적절한암호화가수행된다. 보안플래그 (secure flag) 를사용하여안전하지않은방법으로쿠키가전송되지않는다. 만약애플리케이션코드의변경이발생하면쿠키에대한부분을적절하게검사하고사용한다. 세션데이터의유효성을검증한다. 가능한최소한의개인정보만사용한다.. 민감한정보가쿠키에존재할경우전체쿠키에대한암호화를수행한다. 모든쿠키들이사용하는애플리케이션의이름과필요한사유를정의한다. 데이터 / 입력값검증 : 데이터검증절차가존재한다. http 헤더, 입력폼, 히든필드, 드롭다운리스트와기타웹컴포넌트들처럼악의적인사용자에의해수정될수있는모든입력값에대해적절한확인을수행한다. 모든입력값의길이를검사한다. 모든필드, 쿠키, http 헤더 / 바디, 폼필드를검증한다. 데이터가형식에맞고, 안전한문자만포함되어있다. 서버측에서데이터검증이수행된다. 중앙집중형구성또는분산형구성을사용할경우, 데이터검증이어느곳에서수행되는지확인한다. 40

41 데이터검증모델에는백도어가없는지확인한다. 황금규칙 : 종류에상관없이모든외부입력값을검사하고확인한다. OWASP 코드리뷰가이드 1.1 한글본 2015 오류처리 / 정보누출 : 값을리턴하는모든메소드 / 함수가적절한오류처리및리턴값을검사한다. 예외및오류조건이적절하게처리되고있는지확인한다. 시스템오류가사용자에게전달되지않도록한다. 안전한방법으로애플리케이션장애가처리된다. 오류발생시할당된자원이해제된다. 로그 / 감사 : 오류발생시민감정보를기록하지않는다. 정의된최고길이값또는기록절차에서요구하는길이값에대한페이로드가기록된다.. 민감한데이터, 예를들면, 쿠키, HTTP "GET" 메소드, 인증정보들이기록되지않는지확인한다. 애플리케이션에대한감사를수행하게되면, 데이터조작 / 생성, 갱신, 삭제행위에대한기록을검사한다. 성공또는실패한인증을기록한다. 애플리케이션오류를기록한다. 민감한정보에대한애플리케이션의디버그기록을검사한다. 암호 : 내부또는외부에서민감한데이터는평문으로전송하지않는다. 애플리케이션은검증된암호화알고리즘을사용한다. 시큐어코딩환경 : 사용자가직접접근할수있는컴포넌트가있는지파일구조를검사한다. 모든메모리할당 / 해제를검사한다. 애플리케이션의동적 SQL을검사하고인젝션취약점이있는지확인한다. 애플리케이션의 main() 을실행하는함수또는백도어를검사한다. 민감한정보를포함할코멘트아웃코드및테스트코드 ( 디버그를위해일시적으로주석처리한코드 ) 를찾는다. 조건로직에는디폴트값이있어야한다. 빌드디렉토리에개발환경도구를포함하지않는다. OS 호출및파일생성호출을검색하고, 오류가능성을검사한다. 41

42 세션관리 : 언제, 어떻게인증된사용자또는인증되지않은사용자에대한세션이생성되는지검사한다. 세션 ID의강도가요구사항을충족시키는지세션 ID를검사한다. 세션이 DB, 메모리등에저장되는방법을검사한다. 애플리케이션이어떻게세션을추적하는지검사한다. 유효하지않은세션 ID가발생할경우애플리케이션에서취할조치를결정한다. 세션무효화를조사한다. 멀티쓰레드 / 멀티사용자세션관리를수행방법을확인한다. HTTP 타임아웃세션을확인한다. 로그아웃기능을확인한다. 위협분석 위협분석을위한기본조건은위협원이애플리케이션을공격할수있는취약점을이용하여애플리케이션에 영향을미치는가능성, 즉위험을정의하는것이다. 위험관리측면에서, 위협모델링은위험을최소화하고 애플리케이션환경에대한위협을식별하고열거하기위해체계적이고전략적으로접근해야한다. 위협분석은애플리케이션의위험을식별하고, 애플리케이션기능성과구조적인측면과관련있다. 또한잠재적 인취약점을식별및분류하기위한설계가필요하다. 위협모델링의첫번째단계로서, 우리는데이터흐름, 신뢰영역, 프로세스구성요소, 입력지점 - 출력지점에 대한시스템을모델링했다. 예 : 대학도서관웹사이트에대한 DFD 가해당예제로서사용되었다. 데이터흐름은데이터가종단간논리적으로흐르는방법을보여주고있어, 임계점을통해컴포넌트에미치게되는컴포넌트와이러한컴포넌트를통한제어흐름을알수있다. 프로세스구성요소는웹서버, 애플리케이션서버그리고데이터베이스서버의데이터가처리되고있는위치를보여준다. 입력지점은데이터가입력되는위치를보여주며출력지점은시스템을종료하는지점이다. 입력, 출력지점은신뢰의경계선을정의한다. STRIDE 모델기반위협목록은해킹과관련된위협을식별하는데있어서유용하다. 예를들어, 로그인공격시나리오의경우, 해커가패스워드를알아내기위해무차별대입공격을한다면? 또는권한상승을위해다른사용자의권한을얻으려고강제브라우징 (forceful browsing) 공격을시도한다면? 위협의종류를인식하고모든가능한공격요소를해커의관점에서평가하는것과, 입력-출력지점을고려하는것은매우중요하고필수적이다. 예를들어, 로그인페이지는로그인데이터를입력받는데, 이런경우악의적인목적을가진 SQL 인젝션, 크로스사이트스크립팅그리고버퍼오버플로우가발생할가능성이있다. 추가로, 해당 42

43 데이터는데이터흐름에따라다음단계에있는진입지점에서위협을확인하기위해사용되어진다. 만약다음컴포넌트가민감한데이터를가지고있다면, 해당지점이좀더중요할수있다. 종단간데이터흐름에서, 예를들면, 로그인페이지로부터받은 ID와패스워드같은입력데이터가검증되지않고전달될경우, 인증을우회할수있는 SQL 인젝션공격을통해 DB 테이블변경이발생할수있다. 출력지점은 XSS 공격같이클라이언트에대한공격지점으로활용될수있다. 예를들면, 컴포넌트출력지점에서 인증데이터를처리하는경우, 기밀성및무결성에대한보안통제가부족한종료지점은비인가사용자에게 인증정보정보를유출될수있다. 출력지점에서의위협은대부분입력지점이가진위협과관련되어있다. 로그인을예로들면, 입력지점이 취약한출력지점을통해계정정보및 SQL 예외에관한오류메시지가사용자에게리턴된다. 방어하는입장에서, 위협식별은 ASF 와같은보안통제분류에의해수행되며, 위협분석가는보안통제사항에 있는취약점과관련된이슈에초점을맞출수있다. 일반적으로위협식별프로세스는각컴포넌트에서평가되는 위협리스트에서발생가능한위협이반복되는사이클과관련되어있다 다음에는위협이공격되기위한공격경로, 근본원인 ( 취약점 : 오렌지색깔로된부분 ) 및필요한통제 조치 ( 대응방안 : 초록색으로된부분 ) 사항을조사하여좀더상세히위협을분석한다. 그림 2 에서보여주는위협 트리는위협분석에유용하다. 일반적인위협, 취약점그리고해커에대한확인이되면, 오남용사례에대해좀더집중적으로위협을분석해야한다. 철저한실제시나리오분석을통해, 보안약점이식별될수있다. 악용사례는보안요구엔지니어링활동의일부로서식별되어야한다. 이런사례는어떻게보호장치를우회할수있었는지, 또는어느곳에보호대책이부족한지묘사할수있다. 오남용사례를아래그림을통해보여준다. 43

44 결국시스템내에각컴포넌트에대한위협의종류를알아냄으로써이모든게동시에가능하다. 이것은 STRIDE 또는 ASF 같은위협분류화를이용하면가능하다. 어떻게취약점을이용해위협이노출되는지알아내기위해 위협구조를사용하고, 오남용사례는위협을줄이기에부족한대응책을알수있다. DFD 아이템에 STRIDE 를적용하여아래테이블을사용할수있다. 44

45 위협순위화 위협은위험요소의관점에서순위화할수있다. 다양한식별된위협으로부터위험요소를확인할수있고, 위험완화전략에도움이되는위협우선순위를만들수있다. 다른위험요소들은어떤위협이높음, 중간, 낮음위험에랭크되었는지알아내기위해사용된다. 일반적으로, 위협-위험모델은아래표와같이서로다른요소들을사용한다. DREAD 마이크로소프트 DREAD 위협위험순위모델에서는영향도에대한기술적인위험요소는피해수준및해킹된사용자수이며, 공격난이도요소는재현가능성, 악용가능성그리고발견가능성이다. 위험을분해하면위협에영향을줄수있는서로다른요인에값을할당할수있다. 순위를알아보기위해위헙분석가들은각위험요소에대한기본적인질문에답해야한다. 예를들면아래와같다. 피해수준 (Damage) : 얼마나피해가날수있는가? 재현가능성 (Reproducibility) : 얼마나쉽게공격을재현할수있는가? 악용가능성 (Exploitability) : 해당위협을악용되기위해어느정도의시간과노력이필요한가? 사용자영향도 (Affected Users) : 위협이노출된다면, 얼마나많은사용자에게영향을미치는가? 발견가능성 (Discoverability) : 얼마나쉽게해커가위협을찾아낼수있는가? 45

46 대학도서관웹사이트를참조하여아래샘플처럼사용할수있다. 위협 : 악의적인사용자가학생, 교직원그리고사서들의기밀정보를열람할수있다. 1. 피해가능성 : 재정적, 법적책임및평판에대한위협 : 8 2. 재현가능성 : 완벽히재현가능함 : 악용가능성 : 같은서브넷또는취약한라우터가요구됨 : 7 4. 사용자영향도 : 모든사용자에영향을미침 : 발견가능성 : 쉽게발견가능함 : 10 전체적인 DREAD 점수 : ( )/5 = 9 이경우, 10 점만점에 9 점이며대단히높은위험을갖는다. 일반적위험모델 보다일반적인위험모델은발생가능성 ( 즉, 공격가능성 ) 과영향도 ( 즉잠재적손상 ) 을고려한다. 위험 = 발생가능성 x 영향도 발생가능성과확률은악용되기쉬운정도로정의되며, 주로위협의종류와시스템특성, 그리고적절한대응책에 따른위협에대한인식정도에좌우된다. 아래는취약점악용가능성을확인하기위해고려해야할내용들이다. 1. 해당취약점이원격에서실행가능한가? 2. 인증을필요로하는가? 3. 취약점에대한자동화가가능한가? 해당영향은주로잠재적인손상가능성과영향의규모, 위협에의해영향을받는컴포넌트숫자에좌우된다. 피해가능성을확인하기위한예제는아래와같다. 1. 해커는완전하게시스템을장악할수있는가? 2. 해커는관리자권한으로시스템에접근할수있는가? 3. 해커는시스템장애를일으킬수있는가? 4. 해커는민감한정보를획득할수있는가? 46

47 위협을받은컴포넌트숫자를확인하기위한예제는다음과같다. 1. 얼마나많은데이터소스와시스템들에영향을주었는가? 2. 위협원이얼마나깊이깊숙히인프라에영향을주었는가? 해당예제들은정성적인값들 ( 높음, 중간, 낮음 ) 을할당하여전체적인위험수준을계산하는데도움이된다. 이 경우 DREAD 모델과같은경우질적인값보다는양적인값을사용하면객관적인순위를정할수있다. 대응책확인 대응책을확인하는목적은위협분석을통해확인된각위협에대해몇가지보호대책 ( 예 : 보안관리, 정책방안 ) 으로 실제발생을사전에예방하기위해서이다. 대응책이없는위협은취약점이된다. 이러한위협은각각 STRIDE 나 ASF 로분류되어있기때문에, 주어진범주내에서응용프로그램에서적절한대응책을찾을수있습니다. 아래간략하고제한적인점검표가제공되며특정위협에대한대응책확인을위해완벽한목록은아니다. 예를들어 ASF 위협유형에대한대응책은다음의표와같다 : ASF 위협및대응책항목 위협유형 대응책 인증 1. 자격증명과인증토큰을통해전송및저장시보호한다. 2. 무차별대입공격, 사전공격및재생공격에내성이있는프로토콜을사용한다. 3. 강력한암호정책을사용한다. 4. 신뢰할수있는인증서버로 SQL 인증을대신한다. 5. 패스워드는해쉬화하여저장한다. 6. 패스워드재설정시패스워드힌트와계정의유효여부를제공하지않는다. 7. 서비스거부공격으로계정이 47

48 잠기지않도록한다. 인가 1. 자원에대한접근권한에강력한접근통제목록들을사용한다. 2. 역할기반접근통제를통해특정작업에대한접근을통제한다. 3. 시스템사용자와서비스계정에대해최소권한의원칙을따른다 4. 프리젠테이션, 비즈니스와데이터접근계층간정확하게권한분리를구성한다. 구성관리 1. 최소권한프로세스는관리기능이없는서비스계정을사용한다. 2. 모든관리및활동에감사및로깅이활성화되야한다. 3. 환경구성파일과관리자인터페이스에대한접근권한은관리자로제한한다. 데이터저장및전송시보호 1. 표준암호화알고리즘과적절한크기의키를사용한다. 2. 해쉬메시지인증코드 (HMAC) 를통해데이터무결성을보호한다. 3. 비밀데이터 ( 예 : 키, 기밀데이터 ) 를전송및저장시암호화하여보호한다. 4. 보안을제공하는저장소는보호키를사용한다. 5. 자격증명없이민감한데이터를 48

49 평문으로전송하지않는다. 데이터확인 / 매개변수확인 1. 데이터유형, 형식, 길이와범위의확인을강화한다. 2. 클라이언트에서보내온모든데이터를검증한다. 3. 매개변수 ( 예 : URL 매개변수 ) 를기반으로보안정책을적용하지않는다. 4. 화이트리스트로입력값필터링을검증한다. 5. 출력값을인코딩한다. 오류처리및예외관리 1. 모든예외는구조화된방식으로처리한다. 2. 오류나예외의경우적절한권한으로복원한다. 3. 오류메시지민감하지않은정보가담긴하찮은오류메시지라도공격자에게공개되지않도록한다. 사용자및세션관리 1. 쿠키에일반텍스트로중요한 정보를저장하지않는다. 2. 인증된쿠키의내용은 암호화한다. 3. 쿠키는만료되도록구성한다. 4. 재생공격에강한세션사용 5. 안전한통신채널을통해인증 쿠키를보호한다. 6. 중요기능수행전강제로 사용자재인증을수행한다. 7. 로그아웃시세션을만료한다. 49

50 STRIDE 위협 & 완화기술목록 위협유형 완화기법 접근권한획득 1. 적절한권한부여 2. 비밀데이터보호 3. 비밀저장금지 데이터변조 부인 정보유출 1. 적절한권한부여 2. 해쉬 3. MAC 4. 전자서명 5. 변조방지프로토콜 1. 전자서명 2. 타임스탬프 3. 감사추적기록 1. 권한부여 2. 프라이버시개선프로토콜 3. 암호화 4. 비밀데이터보호 5. 비밀저장금지 1. 민감한정보 ( 패스워드등 ) 는기록하지않는다. 2. 로그파일에무단접근을막기위해접근통제목록 (ACL) 을적용한다. 3. 로그파일부인방지를위해무결성제어 ( 서명 ) 를적용한다. 4. 로그파일은민감한작업과주요이벤트에대한감사추적을제공한다. 5. 여러서버와계층간에감사와로깅이가능하게한다. 서비스거부 1. 적절한권한부여 2. 적절한승인 3. 필터링 4. 제한 5. 서비스품질 권한상승 1. 최소권한으로실행 50

51 STRIDE 를사용할경우다음과같은위협완화테이블을통해위협을완화하기위해사용할수있는기술을 확인할수있다. 위협및대응책이확인되면, 다음과같은프로필을도출할수있다. 1. 완화되지않은위협 : 위협에대한대응책이없으며취약점이전체적으로악용되여영향을일으킬수있다. 2. 부분적으로완화된위협 : 위협에대해하나이상의부분적인대응책으로취약점일부가악용되어제한적인영향을일으킬수있다. 3. 완벽히완화된위협 : 이위협은적절한대응책을가지고있고취약점이악용되지않으며영향을미치지않는다. 완화대책 위험관리의목적은응용프로그램개발에서있을수있는위협의영향을줄이는것이다. 이것은위협완화대책을 통해해결할수있다. 일반적으로위협을완화하는데는 4 가지방법이있다. 1. 아무것도하지않는다 : 예 ) 최선을희망 2. 위험에대해알린다 : 예 ) 위험에대해사용자에게경고 3. 위험을완화시킨다 : 예를들면, 적절한대책을통해완화 4. 위험을수락한다 : 예 ) 개발효과 ( 사업효과 ) 를평가한후 5. 위험을전환 : 예 ) 계약및보험계약을통해 위협이발생하여미치는영향즉전환비용 ( 보험료 ), 피해수준 ( 피해복구비용 ) 에따라전략이적절한지여부는달라진다. 위대책은시스템에대한위협의위험을기초로하고있다. 따라서전략을선택한자체만으로시스템의위협은완화되지않는다. 궁극적으로비지니스위험관리전략의중요한요인으로전반적인위험에대해사업적영향을고려한다. 한전략이수정되기위해서는취약점이잠재적으로비지니스에미치는영향보다적을경우전략을수정할수있다. 또다른전략은일부보안통제 ( 예 : 기밀성, 무결성, 가용성 ) 기능이상실되었을경우서비스나중요비즈니스의손실이적을때는위험을감수한다. 또다른예로다른서비스제공자에게위험을전가하는방법이있다. 51

52 코드리뷰메트릭스 코드리뷰는소프트웨어개발프로세스를향상시킬수있는훌륭한지표이다. 여기에는상대적지표와절대적 지표등두가지유형이있다. 절대적지표는응용프로그램에서특정변수또는코드라인 (LOC) 의개수에대한참조의숫자로코드의특성을설명하는수치다. 절대측정값은이러한코드의라인수로모든것을포함하지않지만중요한척도이다. 상대적지표는직접측정할수없는속성을표현하고있으며주관적이고측정기준에서파생된문맥에의존한다. 이러한속성을측정하는데이보다확실한방법은없다. 변수가많으면테스트난이도가상승하는등, 모든숫자로표현된정보는다른지표를예측하게되거나주관적이된다. 메트릭의장점 코드리뷰의목적은취약점이발생되어악용될수있는개발오류를감지하는것이다. 또한코드리뷰는애플리케이션개발보안업무에서개발팀의진행사항을측정하는데사용할수있다. 코드리뷰는보안에대한개발이취약한분야와강한분야를정확하게파악할수있다. 개발자에게개발된솔루션내에서보안취약점의근본원인을해결할수있도록한다. 이를통해소프트웨어개발정책과지침그리고사용자자체적으로해석에대해서조사할수있다. 소통이핵심요소이다. 또한지표는코드검토자의역량, 코드리뷰과정의정확성, 코드리뷰기능의생산성, 그리고코드리뷰기능의효율성과효과를측정할수있다. 52

53 위그림은코드리뷰프로세스전반에걸쳐측정지표사용에대한설명이다. 개발보안지표 결함밀도 : 코드라인 (LOC) 당프로그래밍평균결함비율이다. 이것은코드품질의상위수준관점을제공하지만그이상은아니다. 결함밀도가실제적인통계를의미하지는않는다. 결함밀도는코드의사소한문제뿐만아니라심각한보안결함까지같은수준에서검출하기때문이다. 결함밀도만을사용해서는코드의보안성을정확하게판단할수없다. 코드라인 (LOC): 실행코드라인의개수이다. 주석코드와공백은포함되지않는다. 코드라인은코드의크기를측정하기위한 또다른통계이다. 이것은대략적인크기만제공할뿐정확하지않다. 코드라인수에따라서응용프로그램의 크기를추정하는것은전문가의오판이라고생각하는견해도있다! 53

54 기능점수 : 기능을측정하여소프트웨어크기를추정하는것이다. 특정태스크수행, 프로그래밍언어의사용또는개발 방법론의독립적인수행구문수를조합하는것이다. 위험도 : 결함밀도와마찬가지로발견된문제는위험에의해등급이매겨진다 ( 높음, 중간및낮음 ). 위험도는 [X 위험 / 코드라인 ] 또는 [Y 위험 / 기능점수 ] 값을통해개발되고있는코드의품질에대해서정확히파악할수있다. 내부애플리케이션개발정책및표준에의해정의된다 (X&Y 는높음, 중간또는낮음위험 ). 예 : 1000 라인의코드당높은위험결함 4 개 3 기능점수당중간위험결함 2 개 경로복잡도 / 복잡도와결함 / 순환복잡도 순환복잡도 (Cyclomatic Complexity) 는클래스와메소드또는전체시스템과같은코드항목에대해위험및안전성을평가기준을만들수있다. 70 년대토마스멕케이브 (Thomas McCabe) 가정의하였고계산및적용방법이쉬워유용하다. CC = 분기문의수 +1 분기노드는다음과같은명령문들이다 : If...else, Switch, Case, Catch, While, do, 기타등등... 분기노드수가증가할수록복잡도또한증가한다. 복잡한코드는불안정성하며유지보수가어렵다. 복잡한코드는더높은결함위험이있다. 순환복잡도의임계값설정 : 0-10: 안정적코드. 허용된복잡도 54

55 11-15: 중간위험. 더복잡함 16-20: 높은위험코드. 코드단위에대해많은분기노드. 검토진행율측정 검사율 이통계는코드리뷰를수행하는데필요한기간을산정하는데사용할수있다. 검사율은코드리뷰자가시간당 수행할수있는범위에대한비율이다. 경험에따르면시간당 250 줄이기준속도이다. 검사율은검토품질 측정의일부로사용해서는안되며단순히작업기간을결정하기위해사용해야한다. 결함검출율 이통계는측정시간당결함발견율이다. 코드검토팀이성능을재측정하는데사용할수있다. 그러나품질측정 수단으로는사용하지않는다. 일반적으로검사율이감소하면결함검출율은증가한다. 코드커버리지 코드라인의기능포인트를 % 로측정하고, 코드커버러지는검토코드의비율이다. 수동검토의경우거의 100% 에다다르지만그와달리자동검토는 80-90% 정도만해도좋은것으로간주한다. 결함수정율 발견된결함을수정하는데많은시간이소요된다. 이통계는 SDLC 를최적화하는데사용할수있다. 평균 결함율은오버타임을측정할수있으며, 프로젝트계획단계에서얼마나시간이필요한지측정가능하다. 재검토결함율 코드를재검사시더많은결함이존재할비율로, 몇가지결함이여전이존재하거나이전에발견된결함을 해결하는중에발생하는기타결함이다. 55

56 코드크롤링 코드크롤링은의문이있는검토대상의코드베이스를스캔하는것이다. 이것은보안취약점이있는핵심포인터를찾는것이다. 특정 API 는외부, 파일입출력또는사용자관리인터페이스를연결한다. 이는공격자가노리는핵심영역이다. 코드크롤링을통해우리는이러한영역과관련된 API 를찾는다. 또한우리는보안문제를발생할수있는비지니스로직영역을찾을필요가있지만, 일반적으로메소드명명규칙에의한맞춤형이름과직접검색이안되게하지만우리는특정주요 API 의관계로특정메소드에접근할수있다. 또한특정언어와관련된공통적인문제를찾을필요가있다 ; * 보안 * 과관련되어있지않은문제라도어떤특별한상황의경우응용프로그램의안정성 / 가용성에영향을미칠수있다. 코드리뷰를할때있을수있는또다른문제점은지적재산권을보호하기위해저작권을공지하는것이다. 코드크롤링은수동또는자동화된도구를사용하여자동화된방식으로수행할수있다. Grep 나 wingrep 와같은간단한도구를사용할수있다. 또한특정프로그래밍언어에관련된키워드를검색하는다른도구를사용해도된다. 이절에서는 Java/J2EE,.NET 및클래식 ASP 를위한코드크롤링의기능을다룬다. 또한트랜잭션분석세션에서자세히다룬다. 주요지표의검색 코드리뷰의기본은애플리케이션보안에영향을미칠수있는코드의영역을찾아서분석하는것이다. 코드리뷰는코드에대해철저하게이해하고, 어떤의도가있는지그리고어떤의미가있는지확인하며최우선적으로관심영역에대한코드베이스를조사해야한다. 코드베이스에서텍스트검색을통해 API 및기능에관련된키워드를찾을수있다. 다음은.NET 프레임워크 1.1 & 2.0 에대한가이드이다..NET 에서코드검색 첫째로텍스트검색을수행하기위해사용할수있는도구에익숙혀져야하고, 무엇을찾는지알아야한다. 이절에서우리는비쥬얼스튜디오 (VS) 와.NET 을가지고있다고가정한다. VS 는 " 파일에서찾기 " 와 Findstr 이라불리는커맨드라인도구가있다. 경험상윈도우 XP 의검색시험도구는좋지않으며, 만약사용해야할경우 SP2 가확실히더욱효과적이다. 시작하려면 "User", "Password", "Pswd", "Key", "Http" 등일반적인패턴이나키워드를찾고철저하게코드를검사해야한다. 이것은 VS 의툴인 findstring 을사용하여수행할수있다.: findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*] 56

57 HTTP 요청문자열 외부자원에서들어오는요청은보안코드리뷰시핵심영역이다. 수신하는모든 HTTP 요청이구성, 최대및최소 길이에대한유효성이검증된데이터인지, 그리고데이터가화이트리스트파라미터범주에포함되는지 확인해야한다. 요점은이것은분석해야하고, 보안을보장하기위한핵심영역이다. request.accepttypes request.browser request.files request.headers request.httpmethod request.item request.querystring request.form request.cookies request.certificate request.rawurl request.servervariables request.url request.urlreferrer request.useragent request.userlanguages request.issecureconnection request.totalbytes request.binaryread InputStream HiddenField.Value TextBox.Text recordset HTML 출력 여기서는클라이언트로응답하는것을찾고있다. 데이터가검증되지않은채또는데이터검증없이외부입력 값을반사하는응답은반드시확인해야한다. 많은클라이언트측공격은응답검증을수행하지않아발생한다. XSS 와같은공격이이에해당한다. response.write <% = HttpUtility UrlEncode innertext innerhtml HtmlEncode SQL 및데이터베이스 데이터베이스가코드와관련있는곳을찾는것은코드리뷰시중요한일이다. 데이터베이스코드를살펴보면 응용프로그램이 SQL 인젝션에취약한지확인하는데도움이된다. 이를위해코드에 SqlParameter, 57

58 OleDbParameter 또는 OdbcParameter(System.Data.SqlClient) 를사용하고있는지확인하는것이다. 즉 데이터베이스에서파라미터를문자그대로처리하여실행되지않도록한다. exec sp_executesql execute sp_executesql select from Insert update delete from where delete exec sp_ execute sp_ exec xp_ execute sp_ executestatement executesql setfilter executequery GetQueryResultInXML adodb sqloledb sql server driver Server.CreateObject.Provider.Open ADODB.recordset New OleDbConnection ExecuteReader DataSource SqlCommand Microsoft.Jet SqlDataReader ExecuteReader GetString SqlDataAdapter CommandType StoredProcedure System.Data.sql 쿠키 쿠키조작은세션하이제킹 / 세션고정및매개변수조작과같은다양한애플리케이션보안공격에활용될수 있다. 쿠키기능과관련된모든코드를검사해야하며, 이를통해세션보안을수립할수있다. System.Net.Cookie HTTPOnly 58

59 document.cookie HTML 태그 아래의대부분의 HTML 태그는크로스사이트스크립팅 (XSS) 과같은클라이언트측공격에사용될수있다. 태그가사용되는곳과웹애플리케이션의표현및태그의사용에관련된모든데이터유효성검사는전체 문맥상에서검토하여야한다. HtmlEncode URLEncode <applet> <frameset> <embed> <frame> <html> <iframe> <style> <layer> <ilayer> <meta> <object> <body> <frame security <iframe security <img> 입력값제어 아래입력값제어는웹애플리케이션폼필드를생성하고보여주는서버클래스이다. 이를참고하면애플리케이 션으로의입력지점을찾을수있다. system.web.ui.htmlcontrols.htmlinputhidden system.web.ui.webcontrols.hiddenfield system.web.ui.webcontrols.hyperlink system.web.ui.webcontrols.textbox system.web.ui.webcontrols.label system.web.ui.webcontrols.linkbutton system.web.ui.webcontrols.listbox system.web.ui.webcontrols.checkboxlist 59

60 system.web.ui.webcontrols.dropdownlist WEB.CONFIG.NET 프레임워크는.config 파일에환경설정을정의한다..config 파일은텍스트기반의 XML 파일이다. 일반적으로단일시스템에여러개의.config 파일이존재할수있다. 웹애플리케이션은애플리케이션의루트디렉토리에있는 web.config 파일을참고한다. ASP.NET 애플리케이션의 web.config 는애플리케이션의운용에대한많은정보를포함하고있다. requestencoding responseencoding trace authorization compilation CustomErrors httpcookies httphandlers httpruntime sessionstate maxrequestlength debug forms protection appsettings ConfigurationSettings appsettings connectionstrings authentication mode allow deny credentials identity impersonate timeout remote global.asax 필요한경우각각의애플리케이션은자체 Global.asax 을가지고있다. Global.asax 는이벤트코드와애플리케이 션사용을위한값을설정한다. 전체애플리케이션과그에속한모든사용자가접근할수있기때문에, 애플리케 이션변수가민감한정보를포함하지않는지확인해야한다. Application_OnAuthenticateRequest Application_OnAuthorizeRequest Session_OnStart Session_OnEnd 60

61 로깅 로깅은정보유출의원인이될수있다. 로깅하위시스템에대한모든호출을검사하고모든민감한정보가 기록된다면이를확인하고검사해야한다. 일반적인실수로인증기능내에사용자 ID 와패스워드가결합된 기록을남기거나민감한데이터가포함된데이터베이스요청을기록한다. log4net Console.WriteLine System.Diagnostics.Debug System.Diagnostics.Trace Machine.config 특정프로그램에서는 Machine.config 의많은변수가 Web.config 에서덮어씌여질수있다는점을기억해야 한다. validaterequest enableviewstate enableviewstatemac 쓰레드와병행실행 멀티쓰레드기능을포함하는코드의위치를확인한다. 동시실행문제는보안취약점이될수있는경쟁상태가발생할수있다. 쓰레드키워드는새로운쓰레드객체에서생성된다. 민감한보안정보를가지고있는정적전역변수를사용하는코드는세션문제가발생할수있다. 정적생성자는사용하는코드는쓰레드간의문제가발생할수있다. 쓰레드해제를동기화하지않는경우동시에쓰레드해제를요청는문제를일으킬수있으며, 이는리소스해제문제가발생한다. Thread Dispose 클래스설계 61

62 Public( 공개 ) 과 Sealted( 봉인 ) 클래스는클래스수준의설계와관계가있다. 의도치않게파생된클래스는 봉인되어야한다. 모든클래스필드는합당한이유로 public 인지확인해야한다. 불필요한경우에는노출시키면 안된다. Public Sealed 리플렉션, 직렬화 코드는실행시동적으로생성될수있다. 외부입력에의해동적으로생성되는코드는문제를야기할수도있다. 코드에민감한데이터를포함하는경우에는직렬화할필요가없다. Serializable AllowPartiallyTrustedCallersAttribute GetObjectData StrongNameIdentityPermission StrongNameIdentity System.Reflection 예외및오류 catch 블록를통해사용자에게정보를누출하지않도록해야한다. Finally 블록이사용되는자원일경우확인해야 한다. 추적을활성화하는것은정보누출관점에서는좋은방법은아니다. 맞춤형오류가구현되었는지확인해야 한다. catch{ Finally 62

63 trace enabled customerrors mode 암호화 암호를사용할경우 AES 나 3DES 같이강력한것을사용해야한다. 암호키사이즈는클수록좋다. 다음과같은 사항을고려해야한다. 해쉬는어디서수행하는지? 패스워드는해쉬값으로저장하고있는지? 난수는어떻게 생성되는지? PRNG( 의사난수생성기 ) 는충분히랜덤한지? RNGCryptoServiceProvider SHA MD5 base64 xor DES RC2 System.Random Random System.Security.Cryptography 스토리지 만약민감한데이터를메모리에저장할경우다음과같이사용하는것을권장한다. SecureString ProtectedMemory 인가, ASSERT 및 REVERT 코드접근통제권한을우회하는것은좋은생각이아니다. 또한아래는관리되지않은코드호출, CLR( 공용언어 런타임 ) 와같은잠재적으로위험한권한목록이다..RequestMinimum.RequestOptional Assert Debug.Assert CodeAccessPermission ReflectionPermission.MemberAccess SecurityPermission.ControlAppDomain SecurityPermission.UnmanagedCode SecurityPermission.SkipVerification SecurityPermission.ControlEvidence SecurityPermission.SerializationFormatter SecurityPermission.ControlPrincipal 63

64 SecurityPermission.ControlDomainPolicy SecurityPermission.ControlPolicy 레거시메소드 printf strcpy 64

65 J2EE/JAVA 에서코드검색 입력과출력스트림 아래는애플리케이션으로데이터를읽는데사용하는것이다. 아래는애플리케이션으로데이터를읽을때입력 지점이될수있다. 입력지점은외부자원으로부터생길수있으며, 반드시이를조사해야한다. 이것은경로 추적 (Path Traversal) 공격또는 DoS 공격에사용될수있다. Java.io java.util.zip java.util.jar FileInputStream ObjectInputStream FilterInputStream PipedInputStream SequenceInputStream StringBufferInputStream BufferedReader ByteArrayInputStream CharArrayReader File ObjectInputStream PipedInputStream StreamTokenizer getresourceasstream java.io.filereader java.io.filewriter java.io.randomaccessfile java.io.file java.io.fileoutputstream mkdir renameto 서블릿 API 호출은파라미터, 헤더, URL 그리고쿠키변조 (Tampering), HTTP 응답쪼개기는정보유출을위한경로가될 수있다. 이와같은 HTTP 요청으로부터직접적으로얻은 API 의파라미터는엄격히검사하여야한다. javax.servlet.* getparameternames getparametervalues getparameter getparametermap getscheme getprotocol getcontenttype getservername getremoteaddr getremotehost getrealpath getlocalname getattribute getattributenames getlocaladdr getauthtype getremoteuser getcookies issecure HttpServletRequest getquerystring getheadernames getheaders getprincipal getuserprincipal isuserinrole 65

66 getinputstream getoutputstream getwriter addcookie addheader setheader setattribute putvalue javax.servlet.http.cookie getname getpath getdomain getcomment getmethod getpath getreader getrealpath getrequesturi getrequesturl getservername getvalue getvaluenames getrequestedsessionid 크로스사이트스크립팅 javax.servlet.servletoutputstream.print javax.servlet.jsp.jspwriter.print java.io.printwriter.print 분할응답 javax.servlet.http.httpservletresponse.sendredirect addheader, setheader 리다이렉션 sendredirect setstatus addheader, setheader SQL 및 DATABASE 코드와관련된자바데이터베이스를검색할때, 다음목록은검토되는애플리케이션의영속성계층 (persistence layer) 과관련된클래스 / 메소드를정확하게찾는데도움이된다. 66

67 jdbc executequery select insert update delete execute executestatement java.sql.connection.preparestatement java.sql.connection.preparecall createstatement java.sql.resultset.getstring java.sql.resultset.getobject java.sql.statement.executeupdate java.sql.statement.executequery java.sql.statement.execute java.sql.statement.addbatch SSL 종단간암호화를위한도구로써, SSL 이용하는코드를찾는다. 다음은 SSL 기능이개발된곳을찾아준다. com.sun.net.ssl SSLContext SSLSocketFactory TrustManagerFactory HttpsURLConnection KeyManagerFactory 세션관리 getsession invalidate getid 레거시상호작용 명령어인젝션공격또는 OS 인젝션공격에취약할수있다. 네이티브 OS 에연결된자바는심각한문제와 잠재적인위험으로인해모든서버에심각한문제가발생할수있다. 67

68 java.lang.runtime.exec java.lang.runtime.getruntime 로깅 애플리케이션에포함된아래코드를검사하면몇가지정보유출을알수있다. java.io.printstream.write log4j jlo Lumberjack MonoLog qflog just4log log4ant JDLabAgent 아키텍쳐분석 애플리케이션에서주요설계요소를찾을수있다면검색범위를좁힐수있다. 그러면구성요소와프레임워크 의알려진취약점을찾을수있다. ### Ajax XMLHTTP ### Hibernate import org.hibernate ### Struts org.apache.struts ### Castor org.exolab.castor ### Spring org.springframework ### JAXB javax.xml ### Java Server Faces (JSF) import javax.faces 68

69 ### JMS JMS 일반적키워드 개발자들은가장중요한것은소스코드라고말한다. 아래의키워드를이용하면가능한소프트웨어취약점을 찾을수있다. Hack Kludge Bypass Steal Stolen Divert Broke Trick FIXME ToDo Password Backdoor WEB 2.0 Ajax 와자바스크립트 Ajax 에서발생할수있는자바스크립트이슈 document.write eval document.cookie window.location document.url XMLHTTP window.createrequest 69

70 클래식 ASP 에서코드검색 입력 Request Request.QueryString Request.Form Request.ServerVariables Query_String hidden include.inc 출력 Response.Write Response.BinaryWrite <%= 쿠키.cookies 오류처리 err. Server.GetLastError On Error Resume Next On Error GoTo 0 URL 정보 location.href location.replace method="get" 70

71 데이터베이스 commandtext select from update insert into delete from where exec execute.execute.open ADODB. commandtype ICommand IRowSet 세션 session.timeout session.abandon session.removeall DOS 공격방지 server.scripttimeout IsClientConnected 로깅 WriteEntry 리다이렉션 Response.AddHeader Response.AppendHeader Response.Redirect Response.Status Response.StatusCode 71

72 Server.Transfer Server.Execute 72

73 자바스트립트 / WEB 2.0 키워드와포인터 Ajax 와자바스크립트를이용해서클라이언트측에서돌아가는기능을구현할수있다. 그기능들로인해예전의보안이슈들이다시회자되고있다. 다음키워드는사용자상태와브라우저를제어하는데사용하는 API 호출에관한것이다. AJAX 및기타웹 2.0 패러다임은클라이언트측으로보안이슈를집중시켰지만서버측보안이슈도포함을하고있다. Ajax 사용및자바스크립트문제를찾는것 eval( ) document.cookie document.referrer document.attachevent document.body document.body.innerhtml document.body.innertext document.close document.create document.createelement document.execcommand document.forms[0].action document.location document.open document.url document.urlunencoded document.write document.writeln location.hash location.href location.search window.alert window.attachevent window.createrequest window.execscript window.location window.open window.navigate window.setinterval window.settimeout XMLHTTP 73

74 코드리뷰와 PCI DSS 소개 카드결제산업데이터보안표준 (Payment Card Industry Data Security Standard; PCI) 은 2005 년 6 월에신용카드결제처리회사에대한강제준수사항이되었다.. 자체개발한코드에대해코드리뷰하는것은표준이처음발표되었을부터요구사항이다. 이절은해당 PCI 요구사항에서준수해야할코드리뷰에관한설명이다. 코드리뷰요구사항들 PCI 표준은안전한응용프로그램개발과관련해서몇가지가더있지만여기서는코드리뷰에만초점을맞춘다. 코드리뷰에관한모든요구사항은 6 에서찾을수있다 : 보안시스템및응용프로그램을개발하고유지하고있다. 특히요구사항 은사용자정의코드의코드리뷰 : 잠재적인코딩취약점을찾아내기위해출시전에자체개발한코드에대한리뷰. 이요구사항은다른 PCI 요구사항을반드시고려해야한다는의미이다. 즉 출시전자체응용프로그램계정, 사용자 ID 및패스워드제거 6.5 OWASP 가이드라인과같이시큐어코딩에기반하여모든웹응용프로그램을개발. 소프트웨어개발 프로세스의일반적인코딩취약점예방법은다음과같다 : 검증되지않은입력값 부적절한접근통제 ( 예 : 사용자 ID 의악의적인사용 ) 인증과세션관리취약점 ( 계정정보와세션쿠키의사용 ) 크로스사이트스크립트공격 버퍼오버플로우 인젝션결함 ( 예 : SQL 인젝션 ) 74

75 6.5.7 부적절한오류처리 안전하지않은저장 서비스거부 안전하지않은구성관리 이표준은구체적인방법에대해서설명하지않지만방향을제시해준다. 어떤방법으로접근할수있도록도와 준다. 현재버전의표준 ( 작성시버전 1.1) 은요구사항 6.6 을소개했다. 이요구사항은기업들에게두가지 옵션을주었다 : 1) 모든고객의응용프로그램코드는응용프로그램보안전문조직에의해일반적인보안취약점검토 2) 웹인터페이스가있는응용프로그램앞에응용계층방화벽설치 PCI 위원회는코드리뷰를하는내부자원을포함했다. 이것으로내부코드리뷰에중점을두고, 이프로세스가 제대로수행되었는지확인할수있다. 75

76 기술통제검토 : 인증 소개 너는누구인가? 인증은일반적으로사용자이름및패스워드와같은자격증명을통해, 한개체가다른개체의신원을확인하는프로세스이다. 조직마다의다양한요구사항에따라, 여러가지선택가능한인증방법이있다. 인증방법이올바르게선택되지않고개발되는경우, 공격자가시스템에접근하기위해악용할수있는취약점을노출할수있다. 패스워드저장및사용자자격증명은다층보안및컴플라이언스관점에서도이슈이다. 아래절은패스워드저장및검토에대해논의한다. 취약한인증기능과관련된소스코드측면에대해논의할것입니다. 결함이있는구현또는깨진비즈니스로직이원인이될수도있다.: 인증은비공개된데이터, 민감한기능을보호하는핵심적인방어책이다. 취약한패스워드및패스워드기능 패스워드강도는사용자설정 / 패스워드생성시에시행되어야한다. 패스워드는복잡하게구성되어야한다. 새로운패스워드등록단계에서애플리케이션의백엔드 / 서버측면에서확인되어야한다. 잘못된예 패스워드가널이아닌지확인하는것으로충분하지않다. String password = request.getparameter("password"); if (password == Null) { throw InvalidPasswordException() } 좋은예 패스워드가아래규칙에적합한지확인해야한다. 1 개이상의대문자 (A-Z) 1 개이상의소문자 (a-z) 1 개이상의숫자 (0-9) 76

77 1 개이상의특수문자 (!" $%&...) 지정된최소길이 (8 자리 ) 지정된최대길이 ( 모든외부입력과함께 ) 연속된문자않됨 (123abcd) 1 줄에서두개이상의동일한문자안됨 (1111) HTTP 요청을받자마자, 코드에서위의규칙을찾아서사용해야한다. 규칙은복잡한정규표현식이나논리적인 자체코드구문이어야한다. if password.regex([a-z]) and password.regex([a-z]) and password.regex([0-9]) and password.regex({8-30}) and password.rexex([!" $%^&*()]) return true; else return false; 위의코드의정규표현식구문 : (?=^.{8,30}$)(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*()_+}{"":;'?/>.<,]).*$..NET 인증제어.NET 은환경설정파일에인증관련태그가있다. <authentication> 요소는응용프로그램이사용하는인증모드를구성한다. <authentication> 77

78 적절한인증모드는응용프로그램또는웹서비스설계방법에따라달라진다. 아래그림과같이기본 Machine.config 설정은보안 Windows 인증을기본적으로적용한다. authentication Attributes:mode="[Windows Forms Passport None]" <authentication mode="windows" /> 양식인증가이드라인. 양식인증을사용하기위해, <authentication> 요소에 mode= Forms 로설정한다. 다음, 하위 <forms> 요소를사용하여양식인증을구성한다. 다음은안전한 <forms> 인증요소환경설정을보여준다. <authentication mode="forms"> <forms loginurl="restricted\login.aspx" Login page in an SSL protected folder protection="all" requiressl="true" timeout="10" name="appnamecookie" path="/formsauth" slidingexpiration="true" > Privacy and integrity Prevents cookie being sent over http Limited session lifetime Unique per-application name and path Sliding session lifetime </forms> </authentication> 양식인증보안을향상하기위하여, 아래권장사항을사용하시기바란다. 웹사이트분할 protection= All 설정쿠키시간제한값을작게설정고정된만료기간을사용하는것을고려양식인증에 SSL 사용 SSL 을사용하지않을경우 slidingexpiration = false 설정 78

79 프로덕션서버에 <credentials> 요소를사용하지말것 <machinekey> 요소구성 고유쿠키이름및경로사용 클래식 ASP 페이지에서는일반적으로 DB 에대하여검증한후, 세션변수에사용자정보를포함하여수동으로 인증을수행하였으며, 아래와같이확인할수있다. Session ("UserId") = UserName Session ("Roles") = UserRoles 쿠키없는폼인증 HTTP 헤더의쿠키에있는고유 ID 와같은폼안의인증티켓은기본적으로쿠키에저장된다. ( 인증티켓은사용자가시스템에인증되었는지를기억하는데사용된다.) 상태를저장하지않는 http 프로토콜에서인증을유지하기위한다른방법. 쿠키가없는디렉티브 (directive cookieless) 로사용되는인증티켓의유형을정의할수있다. <forms> 엘리먼트의쿠키가없는값의종류 : UseCookies 항상사용하는쿠키티켓지정 UseUri 사용하지않는쿠키티켓지정 AutoDetect 기기가지원하지않으면쿠키티켓은사용되지않는다. 기기프로파일이쿠키를지원하면탐색기능을사용하여쿠키가활성화할수있다. UseDeviceProfile 정의되지않은경우기본설정됨. 기기프로파일이쿠키를지원하는경우에만쿠키기반의인증티켓을사용. 탐색기능은사용되지않는다. cookieless="useuri" : 위의 <forms> 요소에서무엇을찾을수있나? 탐색에대하여이야기할때, HTTP 헤더안의사용자에이전트디렉티브를참고하고있다. 이것은 ASP.NET 에서 쿠키가지원된다는정보를준다. 패스워드저장전략 79

80 패스워드저장소또한문제이다. 공격자는애플리케이션에비인가접근을통해패스워드가저장된장소에접근할수있다. 패스워드는일방향해쉬알고리즘으로저장되어야한다. 일방향기능 (SHA-256 SHA-1 MD5,..;) 은해쉬기능으로알려져있다. 일단패스워드가저정되고나면, 사람들이패스워드를읽어야할이유가없다. 인증기능은사용자가입력한패스워드의해쉬를수행하고, 저장된해쉬값과비교하는것이다. 패스워드가동일하다면, 해쉬값은동일하다. 복구될수없는패스워드해쉬값을저장하면, 평문의패스워드복구가더어렵게된다. 이것은또한, 애플리케이션관리자가다른사용자의패스워드에접근할수없으므로내부위협벡터를완화하는데도움을준다. SHA-1 해쉬가구현된자바코드예시 : import java.security.messagedigest; public byte[] gethash(string password) throws NoSuchAlgorithmException { MessageDigest digest = MessageDigest.getInstance("SHA-1"); digest.reset(); byte[] input = digest.digest(password.getbytes("utf-8")); 솔트 : 단순하게해쉬된패스워드를저장하는것은이러한두개의패스워드가동일한경우동일한해쉬값이생성될가능성과생일공격 ( 의문제가있다. 위문제점의해결책은솔트를이용하는것이다. 솔트는지정된길이의랜덤숫자이다. 솔트는각각의저장된입력값에따라반드시달라야한다. 솔트는해쉬된패스워드옆에평문으로저장되어야한다. import java.security.messagedigest; public byte[] gethash(string password, byte[] salt) throws NoSuchAlgorithmException { MessageDigest digest = MessageDigest.getInstance("SHA-256"); digest.reset(); 80

81 digest.update(salt); return digest.digest(password.getbytes("utf-8")); } 인증관련취약점 양식필드를활용하는인증과관련된많은문제가있다. 부적절한필드유효성검사로인해아래와같은문제가 일어날수있다. SQL 인젝션을위한코드리뷰 SQL 인젝션은인증기능을우회하는사용할수있으며, 심지어추후공격을위해시스템에악의적사용자를 추가할수있다. 데이터검증을위한코드리뷰 모든외부에서입력되는데이터에대해서는반드시검증되어야한다. 이것은인증필드에도해당된다. XSS 이슈를위한코드리뷰 크로스사이트스크립트는인증페이지에서 ID 도용, 피싱, 세션하이재킹공격을수행할수있다. 오류처리를위한코드리뷰 잘못되고취약한오류처리는데이터베이스구조고, 유효하거나유효하지않은사용자 ID 등과같은것을이해할 수있도록하여인증기능의내부동작을이해하는데사용될수있다. 자바를이용한해쉬 출처 81

82 기술통제검토 : 인가 소개 웹애플리케이션의광범위한계층에서인가에관한문제가존재한다. 사용자가애플리케이션계층에서애플리케이션의특정기능에대한접근권한을얻기위한사용자의기능적인가에서부터데이터베이스접근인가과영속성계층 (persistence layer) 에서최초권한과같은문제들이있다. 그렇다면, 코드리뷰시봐야할것은무엇인가? 공격관점에서가장일반적인이슈는호기심의결과나, SQL 인젝션과같은취약점이다. 예 : SQL 인젝션에취약한애플리케이션에서 system/admin 접근권한을가지고있는애플리케이션이사용하는데이터베이스계정은최소권한의데이터베이스계정보다공격에대한영향도가더크다. 사용자데이터가나뉘어져있는다중사용자데이터베이스환경에서인가는핵심요소이다. 클라이언트 / 사용자들은다른클라이언트의데이터를볼수없다 ( 수평인가 ). 인가는또한일부사용자그룹의기능을제한하는데사용될수있다. 또한슈퍼유저는일반유저가접근하지못하도록하는특별한관리기능을가질수있다. 인가는애플리케이션개발에서맞춤영역이다. 인증이성공한후로드되는사용자세션을가지고테이블을조회하도록구현될수있다. 각요청에따라백엔드 LDAP 또는데이터베이스시스템에실시간으로질의를할수있다. 잠재적으로취약한코드찾는방법 비즈니스로직오류는인가오류를찾는데있어주요영역이다. 인가체크부분은주의깊게봐야하는부분이다. 악성로직등논리적조건의경우에는검사가필요하다. if user.equals("normaluser"){ grantuser(normal_permissions); }else{ //user must be admin/super grantuser("super_persmissions); } 82

83 클래식 ASP 페이지에서는접근제어유효성검사나제한기능이포함된인클루드파일을이용해서인가기능이동작한다. 아래와같은문장을자주볼수있을것이다. <!--#include file="validateuser.inc"--> 추가적인이슈 : inc 확장자가인식되지않으면 ASP 코드가실행되지않으므로인클루드파일은직접호출되거나 애플리케이션기능을노출시킬수있다. 인가에취약한패턴 인가모델이단순하게권한이없는사용자에게특정기능을보여주지않는기능만있는지확인해봐야한다. 애플리케이션을크롤링해보면, 사용자 GUI 상에서보여지지않는링크들을찾을수있을것이다. 간단한 HTTP GET 요청만으로도숨겨진링크를찾을수있다. 확실히, 서버측에서도작업수행에대한권한이있는지확인해야한다. 그리고 GUI 를 숨기는 버튼과링크에의존하면안된다. 사용자수준의인가때문에클라이언트단에서버튼을숨기는것으로는사용자가버튼을통해수행하는실행작업을막을수없다 document.form.adminfunction.disabled=true; <form action="./doadminfunction.asp"> 페이지를로컬로저장하고, disable=true 를 disable=false 로변경하고 form action 을추가하면 disable 된 버튼을활성화할수있다. HotSpots 데이터베이스 : 데이터베이스에접근하는애플리케이션이사용하는계정은최소권한이적용되었는지확인하라. ASP.NET: (WEB.CONFIG) <authorization> 엘리먼트는사용자나웹클라이언트별로 ASP.NET 에서특정폴더, 페이지, 자원에대한인가및 접근을제어할수있다. 오직인가된사용자만이특정페이지에접근하거나볼수있게해야한다. <system.web> <authorization> <deny users="?"/> <-- 익명의사용자는접근거부. 사용자는반드시인증되어야함. </authorization> 83

84 </system.web> ASP.NET 2.0 에서 rolemanager 엘리먼트는프레임워크내에서관리역할을지원하는데사용된다. rolemanager 엘리먼트는개발자에게개발되어야할많은샘플코드를지원한다. web.config 에서활성화 (enable) 되어있는지 확인하라. <system.web>... <rolemanager enabled="true false" <providers>...</providers> </rolemanager>... </system.web> APACHE 1.3 아파치에는 httpd.conf 라는파일이있다. 이파일에서 Allow 와 Deny 로접근제어를구현할수있다. allow from address 는허용할 IP 주소나도메인이름을나타낸다. 단위는호스트수준의단위이다. Deny from : 해당 IP 의접근을거부한다. Order 지시자 : 접근순서지정 Order Deny, Allow : 먼저모두거부하고, 특정호스트만접근가능 Deny from all Allow from owasp.org : 모두거부하고, owasp.org 만허용 아파치에서사용자수준인가를바꾸기위해서 Satisfy 지시문을이용할수있다. 좋은예 모든사용자요청에대해인가를확인한다. String action = request.getparameter("action") if (action == "dostuff"){ boolean permit = session.authtable.isauthorised(action); // check table if authoirsed to do action 84

85 } if (permit){ dostuff(); }else{ throw new (InvalidRequestException("Unauthorised request"); // inform user of no authorization session.invalidate(); // Kill session } 외부개체로부터모든요청을수행하는인가기능 나쁜예 사용자인가를기반으로 GUI 를만드는것이나쁜예이다. 제어기능을볼수없다면, 아무도사용하지않는다 - 가장많이발생하는오류다. 만약사용자가 URL 을가지고있다면기능이계속호출될수있다. 이것은모든 HTTP 요청에대해인가를확인하지않기때문이다. 85