OWASP Top 10 List 에 대한 정리

 

 

 

 

OWASP Top 10 List 에 대한 정리

Open Web Application Security Project

UI솔루션본부 임한솔

 

 

 

 

 

목차

1.      OWASP TOP 10 및 문서소개

2.      OWASP WEB TOP 10

3.      OWASP Mobile TOP 10 

 

 

 

 

 

1        OWASP TOP 10소개

OWASP(The Open Web Application Security Project)는 오픈소스 웹 애플리케이션 보안 프로젝트로, 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며, 웹 애플리케이션의 취약점 중에서 빈도가 많이 발생하고, 보안상 영향을 크게 줄 수 있는 것들의 10대 취약점들을 발표하였습니다.

본 문서는 ~2013년 OWASP TOP 10, ~2014년 OWASP TOP 10 Mobile 기준으로 작성되었으며 대부분 내용의 출처는 위키백과(https://ko.wikipedia.org) 입니다.

2        OWASP WEB TOP 10

2.1     A1: Injection (인젝션)

인젝션 취약점은 SQL, OS, LDAP 등에 해당되며 신뢰할 수 없는 데이터를 명령어나 질의문의 일부분으로서 보내질 때 발생하는데, 공격자의 데이터는 개발자가 의도하지 않은 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있습니다.

이에 대한 대응으로는 익히 알려진 보안솔루션을 사용하여 대응하거나 홈페이지 개발 시에 소스코드단에서 시큐어코딩으로 대응하는 방법이 있습니다.

OS 인젝션(시스템 인젝션) 취약점의 경우 외부에서 URL 또는 파라미터로 전달이 가능한 DB와 연동된 페이지에 대하여 시스템 명령어(ls, cat, ifconfig / dir, ipconfig 등) 삽입으로 운영체제 명령어 실행결과를 출력하는 취약점으로 웹 방화벽에서 모든 사용자 입력 폼(로그인 폼, 검색 폼, URL 등)을 대상으로 특수문자, 특수구문 필터링 규칙을 적용하여 대응할 수 있으며 소스코드상에서 해당 명령어들을 필터링하여 대응 할 수도 있습니다.

SQL 인젝션 취약점의 경우 DB와 연동된 웹 어플리케이션에서 SQL 질의문에 대한 필터링이 제대로 이루어지지 않을 경우 공격자가 입력이 가능한 폼(웹 브라우저 주소입력창 또는 로그인 폼 등)에 조작된 쿼리를 삽입하여 공격자에게 공개되지 않은 웹 서버의 DB 정보를 열람 또는 조작을 할 수 있는 취약점으로 이 역시 웹 방화벽에서의 필터링 규칙을 적용하거나 소스코드상에서 해당 명령어들을  필터링하는 대응방법이 있으며 JAVA의 경우 PreparedStatement 클래스의 setString 혹은 setInt 메소드를 통해 바인딩된 쿼리문을 활용하여 대응 할 수 있습니다.  또한 이미 인젝션에 대하여 대응을 하고 있는 ORM framework , DB framework 등을 사용하면 손쉽게 SQL 인젝션에 대하여 대응할 수 있습니다.

2.2     A2: Broken Authentication and Session Management (인증 및 세션 관리 취약점)

인증과 세션 관리와 관련된 기능이 정확하게 구현되어 있지 않아서, 공격자가 패스워드, 키 또는 세션 토큰을 해킹하여 다른 사용자 ID로 가장할 수 있는 취약점으로 소스코드상에서 공격자가 직접 열람,추가,변경 할 수 없는 서버 단 세션변수를 사용해야 하며 세션 또한 일정 시간이 지나면 자동 파기하고 중복된 로그인을 방지하여야 합니다.

2.3     A3: Cross-Site Scripting (XSS) (크로스 사이트 스크립팅)

XSS 취약점은 신뢰할 수 없는 데이터를 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생하며 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로 이동할 수 있는 취약점으로 웹 방화벽에서 해당하는 특수문자, 특수구문을 필터링하는 대응방법이 있으며 소스코드상에서 XSS공격에서 주로 사용되는 문자들을 리스트로 지정하여 해당 문자가 존재할 시 URL인코딩으로 치환하거나 해당 문자 삽입을 방지 하여야 합니다.

2.4     A4: Insecure Direct Object References (취약한 직접 객체 참조)

직접 객체 참조는 개발자가 파일, 디렉토리, DB 키와 같은 내부 구현 객체를 참조하는 것을 노출시킬 때 발생한다. 접근 통제를 통한 확인이나 다른 보호수단이 없다면, 공격자는 노출된 참조를 조작하여 허가 받지 않은 데이터에 접근할 수 있는 취약점으로 웹 방화벽에서 상위 혹은 하위 디렉토리로 이동하는 특수문자를 필터링하는 대응방법이 있으며 파일을 다운로드하는 소스코드에서는 직접적으로 파일의 경로 및 파일명을 파라미터로 받는 것을 피해야 합니다.

2.5     A5: Security Misconfiguration (보안 설정 오류)

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

2.6     A6: Sensitive Data Exposure (민감 데이터 노출)

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

2.7     A7: Missing Function Level Access Control (기능 수준의 접근 통제 누락)

대부분의 웹 애플리케이션은 UI에 해당 기능을 보이게 하기 전에 기능 수준의 접근권한을 확인하며 이는 각 기능에 접근하는 서버에 동일한 접근통제 검사를 수행하기 때문에 요청에 대해 적절히 확인하지 않을 경우 공격자는 적절한 권한 없이 기능에 접근하기 위한 요청을 위조할 수 있는 취약점으로 관리자 페이지 등에 대하여 유저 권한을 클라이언트가 아닌 서버에서 판단해야 하며 역할에 기반한 별도의 인증절차를 요구하도록 만들어야 하고 보여주지 않는 페이지들은 URL만 숨길 것이 아니라 권한이 없는 유저들은 접근 불가하게 코딩 해야 합니다.

2.8     A8: Cross-Site Request Forgery (CSRF) (크로스 사이트 요청 변조)

CSRF 취약점은 로그온 된 피해자의 취약한 웹 애플리케이션에 피해자의 세션 쿠키와 기타 다른 인증정보를 자동으로 포함하여 위조된 HTTP 요청을 강제로 보내도록 하는 것입니다. 이는 검증되지 않거나 신뢰할 수 없는 데이터를 정상적인 데이터로 위조할 수 있는 취약점으로 XSS공격을 기반으로 하기 때문에 XSS취약점을 방지하면 어느 정도 예방되는 효과를 얻을 수 있습니다.

2.9     A9: Using Components with Known Vulnerabilities (알려진 취약점이 있는 컴포넌트 사용)

컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행되어 이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악됩니다. 알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미치므로 사용중인 컴포넌트, 프로그램에 대하여 지속적인 업데이트를 하며 사용하지 않는 기능들을 최대한 비활성화 하는 것이 좋습니다.

2.10        A10: Unvalidated Redirects and Forwards (검증되지 않은 리다이렉트 및 포워드)

웹 애플리케이션은 종종 사용자들을 다른 페이지로 리다이렉트 하거나 포워드하고, 대상 페이지를 결정하기 위해 신뢰할 수 없는 데이터를 사용합니다. 적절한 검증 절차가 없으면 공격자는 피해자를 피싱 또는 악성코드 사이트로 리다이렉트 하거나 승인되지 않은 페이지에 접근하도록 전달할 수 있는 사회공학적인 취약점으로 리다이렉트 페이지를 신뢰된 페이지로 제한하거나 리다이렉트되는 URL이 악성인지 아닌지 판별하는 타 서비스를 이용하여 검증 후 사용자를 리다이렉트 시켜야 합니다.

 

3        OWASP Mobile TOP 10

3.1    M1: Weak Server Side Controls (서버사이드에서 발생할 수 있는 취약점)

대부분의 앱이 서버와의 통신으로 이루어지고 개발시 하이브리드 앱으로 많이 개발되기 때문에 클라이언트에서 파라미터 값 변조를 통한 웹에서 발생 할 수 있는 취약점들이 도출될 수 있습니다. 이는 OWASP WEB TOP 10 에서 언급한 내용들과 같습니다.

3.2    M2: Insecure Data Storage (중요정보들이 스마트폰 내에 저장되는 경우)

스마트폰 분실 혹은 공격자에 의해 권한 탈취 시 해당 중요정보들 또한 공격자에게 전달됩니다. 따라서 중요데이터는 필요한 데이터를 제외하고는 모바일 디바이스 안에 저장하지 않아야 합니다.

3.2.1    iOS

-        계정(자격증명)을 파일시스템 안에 저장해서는 안되며, 웹 또는 api 로그인 방식(https)을 통해 인증하고 세션시간은 사용자의 사용 시간을 고려한 최소한의 시간으로 설정해야 합니다.

-        중요정보 저장시 iOS 표준 암호화 방식인 CommonCrypto를 사용하며, 추가적인 암호화 또한 고려해야 하며 익히 사용되는 솔루션을 이용하는 것도 하나의 방법입니다.

-        SQLite 를 사용할 경우 암호화를 위해 SQLCipher모듈을 사용합니다.

-        개발시 NSUserDefaults 에 중요정보를 저장하지 않아야 합니다.

-        NSManagedObject를 사용하여 데이터를 저장할 경우 암호화 되지 않은 데이터들이 저장되는 것을 주의해야 합니다.

-        중요정보 저장 시 하드 코딩된 암호화 또는 암호화 해독 키에 의존하지 말아야 합니다.

 

3.2.2    Andorid

-          기기관리자 API를 이용하여 local storage에 setStorageEncryption을 사용하여 암호화 할 수 있습니다.

-           javax.crypto패키지를 이용하여 SD카드 저장 시 암호화 할 수 있습니다.

-          앱사이에 정보공유가 필요하지 않은 경우 공유설정 속성을 NOT MODE_WORLD_READABLE 해야 합니다.

-          중요정보 저장 시 하드코딩된 암호화 또는 암호화 해독키에 의존하지 말아야 합니다.

-          OS에서 제공된 기본 암호화 메커니즘 이외 추가적인 암호화 계층을 고려해야 합니다.

3.3     M3: Insufficient Transport Layer Protection (민감한 정보 평문 전송)

 개인정보 혹은 중요정보들이 네트워크상에서 평문으로 전송될때 발생하게 됩니다. 요청, 응답시에 SSL통신 적용이 필요하며 대체 채널(SMS, MMS, 알림) 등으로 민감한 데이터를 전송하지 않습니다.

3.4     M4: Unintended Data Leakage (의도하지 않은 데이터 누출)

 타 애플리케이션에서 접근 가능한 데이터영역에 민감한 정보를 저장 시 발생할 수 있는 취약점입니다. 개발 시 아래항목에 대해 민감한 정보 저장여부를 확인하여 접근 가능한 타 애플리케이션들을 제어하여 민감한 정보 노출을 최소화 해야 합니다.

-          URL Caching (Both request and response)

-          Keyboard Press Caching

-          Copy/Paste buffer Caching

-          Application backgrounding

-          Logging

-          HTML5 data storage

-          Browser cookie objects

-          Analytics data sent to 3rd parties

3.5     M5: Poor Authorization and Authentication (인증 및 인가 검증 미흡)

 클라이언트 내부에서 인증 시 우회 가능하기 때문에 인증 검증을 서버사이드에서 인증 절차를 확인해야 합니다.  애플리케이션 바이너리 변조에 대한 무결성 검증을 하지 않을 경우 내부 로직 변경으로 인증우회가 가능합니다.

3.6     M6: Broken Cryptography (취약한 암호화)

중요 정부와 암호 키를 함께 저장하거나 애플리케이션에 대한 데이터 보호를 위해 취약한 암호화 방식을 적용할 경우 나타날 수 있는 취약점입니다. 이는 지속적인 암호화 이슈 확인과 이를 적용한 애플리케이션 업데이트를 통하여 해결이 가능합니다.

3.7     M7: Client Side Injection (클라이언트 사이드 인젝션)

SQLite Injection, Local File Inclusion, XML injection, javascript injection(xss, etc), Binary injection 등 클라이언트에서 발생할 수 있는 인젝션 공격입니다. Javascript injection의 경우 모바일웹에서 OWASP WEB TOP 10  에 대하여 대처를 하였을 경우 해당되지 않습니다.

 

3.8     M8: Security Decisions Via Untrusted Inputs (검증 안된 입력 값에 의한 보안 의사결정)

 애플리케이션이나 프로세스간 통신 시 발생 할 수 있는 취약점입니다. 신뢰할 수 없는 외부 프로세스 또는 애플리케이션의 요청에 대한 의사결정을 방지하여야 합니다.

3.9     M9: Improper Session Handling (부적절한 세션 관리)

인증 후 세션을 부여 받았을 때, 한 개의 세션에 한 개의 모바일 디바이스가 허용되도록 해야 합니다.

아래는 OWASP공식 홈페이지에서 다룬 올바른 세션 핸들링 입니다.

-         Failure to Invalidate Sessions on the Backend: 많은 개발자들이 세션 파기 시 모바일 애플리케이션에서만 세션을 파기하는데, 해당 세션  탈취 시 서버와 통신을 이어갈 수 있어 서버 측에서 또한 세션을 파기해야 합니다.

-         Lack of Adequate Timeout Protection: 세션 timeout을 설정해야 합니다. 세션 timeout설정하여 악의적인 사용자가 존재하는 세션을 탈취 시 타 사용자 권한을 획득하는 것을 막을 수 있습니다.

-         Failure to Properly Rotate Cookies: 인증 상태 변경 시 이전 세션에서 사용되었던 쿠키가 허용되지 않도록 파기해야 합니다.

-         Insecure Token Creation: 토큰 생성시 guessing /anticipation attack 에 노출되지 않도록 개발자는 잘 적립된 암호화 알고리즘을 통해 암호화 해야 합니다.

3.10        M10: Lack of Binary Protections (바이너리 보호 미흡)

애플리케이션이 변조되진 않았는지 무결성 검증 후 실행하도록 하여야 합니다.