OWASP(Open Web Application Security Project)는 오픈소스 웹 애플리케이션 보안 프로젝트
Point
무엇보다 보안은 개발조직 전반에 걸쳐 필수적인 요소라고 인식하는 문화를 만드는 것이 중요하다고 OWASP는 강조
가장 최선의 보안은 개발 단계 (코딩 단계)에서 부터의 보안
생각
실무 경험상 침해사고의 대부분은 Application 취약점 이나 개발 로직상의 보안 취약성으로 뚫리는 경우가 대부분임
이외, PC 관리, 서버 OS 레벨의 보안적인 측면의 관리 부재도 한몫 하지만...
개발 단계에서 아래 사항들에 대해 고민하고 보안 이슈에 대해 조금이라도 고려하여 개발한다면
100%는 아니지만 잘 알려진 해킹 공격들에 대해서 조금이나마 보안은 가능할것으로 생각됨........
그러나 현실은 이상적인 보안과 상당한 갭이 있다는것...
예를 들자면, (뭐 다 그렇다는 것은 절대 아님 / 일부 무개념의 사람들이 하는 말씀..)
보안은 보안팀에서 알아서 하는거 아닌가요?
보안팀에서 알아서 막아야죠
IPS나 웹방화벽이 못막나요?
서버 통신이 안되는데 방화벽 문제 같은데요?
이런 저런 사유로 저희 부서는 불편해서 보안 정책 반영 못합니다.
그건 저쪽 팀에서 해야죠 서로 책임 떠넘기기...
뭐 이외에도 수두룩하지만..
요점
- 보안은 특정 부서에서만 하는 것이 아니라 전체 직원이 보안에 대한 경각심을 항상 염두해두고
모든 분야에서 움직일때 비로소 최대의 효과를 낼수 있을까 말까....
- 털리거나 뚫리면 최소한 쪽팔린줄 알고 반성하고, 재발 하지 않도록 보안에 대해 항상 심사 숙고해야함
아무런 불이익이 없으니 그냥저냥... 매번 똑같은 보안 사고 무한 반복...
- IT 서비스 관련 실무자 (경력, 신입) 채용시 기본적인 보안 관련 면접 항목을 추가 해야함
특히나 개발자 채용시.......
예) 서버 관리자 : 랜섬웨어가 어떻게 걸리나요? 어떻게 하면 방지 할수 있을까요?
개발자 : XSS 는 뭔가요? 방지 대책은 어떤게 있을까요? 소스 코딩은 어떻게 해야 할까요?
- 보안 사고는 숨길게 아니라 외부 까지는 아니더라도 내부적으로는 공개 해야함 (상위 관리자 예: 대표님)
서로 쉬쉬 하는 문화는 득보다는 독이됨...
쉬쉬해봐야 시간 지나면 잊혀지고 잊혀지면 보안 홀(구멍)은 계속됨...
- 가장 중요한것은 보안에 대한 개개인의 마인드 개발이던 기획이던 서버관리자던 어떤 분야던 마찬가지
보안 (침해)사고가 나지 않거나 해킹 사고 발생해도 그냥 묻히면 1년이고 10년이고
우리 부서, 우리 회사는 괜찮아라는 잘못된 생각 (아마 대부분...)
반대로 항상 의심하고 한번더 확인하고 항상 노심초사 하는 관리자라면 그래도 숟가락으로 막을꺼 가래로 막는
사태는 면할수 있음...
But, 보안 관련 일선에 있지 않는 사람(직군)은 공감이나 체감하기 힘든 면도 있을수 있을듯...
여튼 상기 내용은 지극히 주관적이고 개인적인 의견임...
* 2017년 OWASP 10대 웹 애플리케이션 취약점
2013 대비 2017 변화
| OWASP Top 10 - 2013 | OWASP Top 10 - 2017 | ||||
|---|---|---|---|---|---|
| No | 취약점 | 비고 | No | 취약점 | 비고 |
1 | 인젝션 | 1 | 인젝션 | ||
2 | 취약한 인증과 세션 관리 | 2 | 취약한 인증 | ||
3 | 크로스 사이트 스크립팅 | 3 | 민감한 데이터 노출 | ||
4 | 안전하지 않은 직접 객체 참조 | 2017:A5 | 4 | XML 외부 개체(XXE) | 신규 |
5 | 잘못된 보안 구성 | 5 | 취약한 접근 통제 | 합침 | |
6 | 민감한 데이터 노출 | 6 | 잘못된 보안 구성 | ||
7 | 기능 수준의 접근 통제 누락 | 2017:A5 | 7 | 크로스 사이트 스크립팅(XSS) | |
8 | 크로스 사이트 요청변조(CSRF) | 삭제 | 8 | 안전하지 않은 역직렬화 | 신규 |
9 | 알려진 취약점이 있는 구성요소 사용 | 9 | 알려진 취약점이 있는 구성요소 사용 | ||
10 | 검증되지 않은 리다이렉트 및 포워드 | 삭제 | 10 | 불충분한 로깅 및 모니터링 | 신규 |
1. A1:2017- 인젝션
SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생합니다. 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있습니다.
2. A2:2017- 취약한 인증
인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키, 세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용합니다.
3. A3:2017- 민감한 데이터 노출
다수의 웹 애플리케이션과 API는 금융 정보, 건강 정보, 개인 식별 정보와 같은 중요한 정보를 제대로 보호하지 않습니다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하기 위해 보호가 취약한 데이터를 훔치거나 수정할 수 있습니다. 중요한 데이터는 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으며, 브라우저에서 주고 받을 때 각별한 주의가 필요합니다.
4. A4:2017- XML 외부 개체 (XXE)
오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가합니다.
외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있습니다
5. A5:2017- 취약한 접근 통제
인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않습니다.
공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 다른 사용자의 데이터를 수정하거나, 접근 권한을 변경하는 등 권한 없는 기능과 데이터에 접근할 수 있습니다.
6. A6:2017- 잘못된 보안 구성
잘못된 보안 구성은 가장 흔하게 보이는 이슈입니다. 취약한 기본 설정, 미완성 (또는 임시 설정), 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과입니다. 모든 운영체제, 프레임워크, 라이브러리와 애플리케이션을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치/ 업그레이드를 진행해야 합니다.
7. A7:2017- 크로스 사이트 스크립팅 (XSS)
XSS 취약점은 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생합니다. XSS는 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션을 탈취할 수 있게 만들고, 웹 사이트를 변조시키고, 악성 사이트로 리다이렉션할 수 있도록 허용합니다.
8. A8:2017- 안전하지 않은 역직렬화
안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다.
역직렬화 취약점이 원격 코드 실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있습니다.
9. A9:2017- 알려진 취약점이 있는 구성요소 사용
라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 컴포넌트는 애플리케이션과 같은 권한으로 실행됩니다.
만약에 취약한 컴포넌트가 악용된 경우, 이는 심각한 데이터 손실을 일으키거나 서버가 장악됩니다. 알려진 취약점이 있는 컴포넌트를 사용한 애플리케이션과 API는 애플리케이션 방어를 약화시키거나 다양한 공격과 영향을 주게 합니다.
10. A10:2017- 불충분한 로깅 & 모니터링
불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있습니다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부 기관이 탐지합니다.
* OWASP Top 10 2017 RC2 발표 새로 선정된 보안 취약점 3가지는
A4. External Entity(XXE)
XXE는 악의적인 자바스크립트를 막기 위한 필터장치를 우회하는 취약점이다.
XML 문서에서 동적으로 외부 URI의 리소스를 포함시킬 수 있는 외부 엔티티(Entity)를 사용할 때 발생한다.
외부 엔티티는 파일 URL 처리기, 패치되지 않은 Windows 서버의 내부 SMB 파일 공유, 내부 포트 검색, 원격 코드 실행 및 Billion Laughs 공격과 같은 서비스 거부 공격과 내부파일 공개에 악용될 수 있다.
A8. 안전하지 않은 역직렬화 취약점(Insecure Deserialization)
이 취약점은 응용 프로그램이 악의적인 직렬화된 객체를 받았을 때 불안정한 직렬화 오류가 발생한다.
안전하지 않은 직렬화로 인해 원격코드가 실행된다. 공격자에 의해 직렬화된 개체가 재생, 변조, 삭제, 삽입, 공격자 권한 상승 등의 문제가 발생될 수 있다.
A10. 불충분한 로깅 및 모니터링(Insufficient Logging & Monitoring)
이 취약점은 불충분한 로깅 및 모니터링과 사고 대응과의 통합이 누락되거나 비효율적인 경우 공격자에 의해 시스템 공격으로 이어지거나 데이터 변조와 추출, 심지어 파괴될 수 있는 취약점이다.
* OWASP 모바일 보안 프로젝트(OWASP Mobile Security Project)의 모바일 보안 위험 Top 10
| 구분 | Mobile Top 10 2014 | Mobile Top 10 2016(RC) |
| M1 | 취약한 서버 통제 (Weak Server Side Control) | 부적절한 플랫폼의 사용 (Improper Platform Usage) |
| M2 | 안전하지 않은 데이터 저장 (Insecure Data Storage) | 안전하지 않은 데이터 저장 (Insecure Data Storage) |
| M3 | 불충분한 전송계층의 보호 (Insufficient Transport Layer Protection) | 안전하지 않은 통신 (Insecure Communication) |
| M4 | 의도하지 않은 데이터 누출 (Unintended Data Leakage) | 안전하지 않은 인증 (Insecure Authentication) |
| M5 | 충분하지 않은 인증 및 권한부여 (Poor Authorization and Authentication) | 불충분한 암호화 (Insufficient Cryptography) |
| M6 | 취약한 암호화 (Broken Cryptography) | 안전하지 않은 권한부여 (Insecure Authorization) |
| M7 | 클라이언트 측면의 인젝션 (Client Side Injection) | 이용자 코드 품질 (Client Code Quality) |
| M8 | 신뢰할 수 없는 입력을 통한 보안 결정 (Security Decisions Via Untrusted Inputs) | 코드 변조 (Code Tampering) |
| M9 | 부적절한 세션 처리 (Improper Session Handling) | 역공학 (Reverse Engineering) |
| M10 | 바이너리 보호 미비 (Lack of Binary Protections) | 불필요한 기능 (Extraneous Functionality) |
– Mobile Top 10 2016에 선정된 각 항목에 대한 설명은 다음과 같음
| 구분 | Mobile Top 10 | 내용 |
| M1 | 부적절한 플랫폼의 사용 | 플랫폼 기능의 오용 또는 플랫폼 보안통제 미 적용으로 인해 발생하는 문제 Android intents*, 플랫폼 권한, TouchID의 오용, 키 체인 또는 모바일 운영 체제의 일부인 다른 보안 컨트롤을 포함 할 수 있습니다. * 컴포넌트(Activity, Content Provider, Broadcast Receiver, Service) 간의 호출과 메시지 전달에 이용 |
| M2 | 안전하지 않은 데이터 저장 | Top 10 Mobile Risk 2014에서 M2와 M4의 조합 안전하지 않은 데이터 저장 및 의도하지 않은 데이터 유출을 포함 합니다. |
| M3 | 안전하지 않은 통신 | 세션성립을 위한 악의적인 핸드쉐이킹(handshaking), 잘못된 SSL 버전, 불완전한 연결, 민감한 정보의 평문 통신 등을 포함 합니다. |
| M4 | 안전하지 않은 인증 | 최종 사용자 또는 잘못된 세션 관리 인증의 개념을 포함 필요한 경우 사용자를 식별하지 못함 필요한 경우 사용자 신원 유지 실패 세션 관리의 약점 |
| M5 | 불충분한 암호화 | 암호화 여부뿐만 아니라 올바르지 않은 암호화 중요한 정보는 암호화 적용이 필요하며 TLS 또는 SSL관련해서는 M3에서 진행 모바일 애플리케이션에 대한 암호화 미 적용은 M2 영역에 속함 |
| M6 | 안전하지 않은 권한 부여 | 권한부여(예를 들어 이용자 측의 권한 결정, 강제 검색 등)에 대한 실패 권한부여의 문제(예를 들어 장치 등록, 사용자 식별 등)와는 구별됨 앱이 인증해야 하는 상황에서 사용자를 전혀 인증하지 않으면 (예 : 인증되고 승인 된 액세스가 필요할 때 일부 리소스 또는 서비스에 익명 액세스를 부여하는 경우) 인증 실패가 아닌 권한 부여 실패입니다. |
| M7 | 이용자 코드 품질 | 신뢰할 수 없는 입력을 통한 보안 결정 모바일 클라이언트의 코드 수준 구현 문제에 대한 포괄적인 내용으로 이는 서버 측 코딩 실수와 구별됩니다. 이는 버퍼 오버 플로우, 형식 문자열 취약점 및 모바일 장치에서 실행되는 일부 코드를 다시 작성하는 코드 품질 실수와 같은 것들을 포함합니다 |
| M8 | 코드 변조 문제점 | 바이너리 패치, 로컬 리소스 수정, 메서드 후킹, 메서드 변경 및 동적 메모리 변조 등을 포함 응용 프로그램이 모바일 장치로 전달되면 코드 및 데이터 리소스가 해당 모바일 장치에 상주합니다. 공격자는 코드를 직접 수정하거나, 메모리 내용을 동적으로 변경하거나, 응용 프로그램이 사용하는 시스템 API를 변경하거나 대체하거나, 응용 프로그램의 데이터와 자원을 수정할 수 있습니다. 이것은 공격자에게 소프트웨어의 의도 된 사용을 개인적 또는 금전적 이득을 위해 전복시키는 직접적인 방법을 제공 할 수 있습니다. |
| M9 | 역공학 | 소스 코드, 라이브러리, 알고리즘 및 기타 자산을 결정하는 최종 핵심 바이너리 분석을 포함 IDA Pro, Hopper, otool 및 기타 이진 검사 도구와 같은 소프트웨어는 침입자가 응용 프로그램의 내부 동작을 파악할 수 있도록 합니다. 이는 백엔드 서버, 암호화 상수 및 암호 및 지적 재산에 대한 정보를 공개하는 것 외에도 응용 프로그램의 초기 취약점을 악용하는 데 사용될 수 있습니다. |
| M10 | 불필요한 기능 | 개발자는 숨겨진 백 도어 기능이나 개발환경에서 의도하지 않게 내부 개발 보안 문제에 포함될 수 있음 예를 들어 개발자가 실수로 하이브리드 앱에 댓글로 비밀번호를 포함 할 수 있습니다. 또 다른 예는 테스트 중 2 요소 인증을 사용하지 못하도록 하는 것입니다. |
