검수요청.png검수요청.png

OWASP

위키원
rlatpdbs2931 (토론 | 기여)님의 2020년 9월 16일 (수) 17:46 판 (새 문서: 300픽셀|썸네일|OWASP '''OWASP'''(The Open Web Application Security Project)는 전 세계적으로 보안 전문가들이 보안 취약점 진단 기준과...)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)
이동: 둘러보기, 검색
OWASP

OWASP(The Open Web Application Security Project)는 전 세계적으로 보안 전문가들이 보안 취약점 진단 기준과 표준을 수립하고, 웹 어플리케이션 보안 관련 문서를 배포하고 보안 취약점 관련 툴을 개발하는 오픈소스 커뮤니티이다.

개요

애플리케이션 보안 위험

OWASP는 무상으로 어플리케이션 보안 도구와 표준, 보안성 시험, 안전한 코드 개발 등을 지원하고 있다. 상업적인 목적이나 이윤 압박이 없기 때문에, 어플리케이션 보안에 대해 공정하고, 실질적이고, 효율적인 정보를 제공할 수 있게 한다. 주로 웹에 관한 정보 노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며, 웹 애플리케이션의 취약점 중에서 빈도가 많이 발생하고, 보안상 영향을 크게 줄 수 있는 것들의 10대 취약점들을 발표한다. 3년 정도를 거치면서 10대 취약점들을 변경해 나가면서 적절한 정보를 제공한다.[1]

OWASP TOP 10

위험 평가표

공격자들은 어플리케이션을 통해 잠재적인 많은 경로를 이용하여 사업이나 조직에 피해를 입힌다. 하지만 어떤 경로들은 미미한 영향을 미쳐 공격 효과가 거의 없을 수도 있고, 다른 경우에는 엄청난 피해를 입히는 위협적인 공격일 수도 있다. 또한 경로를 찾는 과정이 어려운 공격이 있을 수 있고 쉬운 공격이 있을 수 있다. OWASP Top 10은 광범위한 조직의 가장 심각한 위험을 식별하는데 초점을 맞추고 있다. OWASP Risk Rating Methodology에 기초하여 평가표를 통해 위험에 대한 가능성과 기술적인 영향에 관한 포괄적인 정보를 제공한다. [1]

2017 TOP 10

A1 인젝션

  • 인젝션(Injection)

SQL(Structured Query Language), 운영체제(OS), XXE(Xml eXternal Entity), 경량 디렉터리 액세스 프로토콜(LDAP) 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분이 인터프리터로 보내질때 발생한다. 공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속인다. [2]


  • 공격의 발생원인
  1. 사용자 제공 데이터가 유효하지 않거나, 필터링 되어 지지 않거나, 애플리케이션에 의해 정제되지 않는다.
  2. 상황인식기반 필터링 없이 동적 쿼리나 매개 변수화 되지 않은 호출이 인터프리터에서 사용된다.
  3. 악의적인 데이터가 객체 관계형 매핑(ORM) 검색매개변수 내에서 사용되어 추가로 민감한 정보를 추출한다.
  4. 악의적인 데이터가 직접적으로 동적 쿼리안에 포함된 구조적 데이터와 악의적 데이터를 포함한 명령어, 일반명령어, SQL, 저장 프로시저에 사용되며 연결한다.
  • 공격 대응 방법
  1. 인젝션을 예방하기 위해서는 데이터를 지속적으로 명령어와 쿼리로 부터 분리시켜야 한다. 기본 옵션은 인터프리터 사용을 피하거나, 매개 변수화 된 인터페이스를 제공하는 안전한 애플리케이션 프로그래밍 인터페이스(API)를 사용하거나 ORMs 툴을 사용하여 마이 그레이션 하는 것이다. 매개변수화 된 경우에도 PL/SQL이나 트랜잭트 SQL(Transact-SQL), 데이터/쿼리가 연결되거나 악의적인 데이터가 EXECUTE IMMEDIATE 를 함께 실행한다면 저장 프로시저는 SQL인젝션을 실행한다.
  2. 서버 측 화이트리스트나 적극적인 입력값 유효성 검증을 해야한다. 남은 동적 쿼리들을 위하여 특정 필터링 구문을 사용하여 인터프리터에 대한 특수 문자를 필터링 처리 한다. 테이블, 컬럼 이름 등과 같은 SQL구조는 필터링 처리를 할 수가 없기 떄문에 사용자가 제공한 구조 이름은 안전하지 않다.
  3. LIMIT과 다른 SQL 컨트롤 쿼리를 사용하여 SQL인젝션으로 인한 대량 노출을 예방한다. [2]

A2 취약한 인증

  • 취약한 인증(Broken Authentication)

인증과 세션 관리와 관련된 애플리케이션 기능이 정확하게 구현되어 있지 않아서, 공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점을 공격하여 다른 사용자 계정을 일시적 또는 영구적으로 탈취하는 것을 허용한다. [2]

  • 공격의 발생원인

인증과 관련된 공격으로부터 보호하기 위해서 사용자의 신원, 인증 및 세션을 관리하는 것이 매우 중요하다.

  1. 공격자가 유효한 사용자 이름과 비밀번호를 가진 상태에서 계정 정보 삽입과 같은 자동화 공격을 허용한다.
  2. 무차별 공격 또는 기타 자동화 공격을 허용한다.
  3. Password1 또는 admin/admin 과 같은 기본 암호, 약한 암호 또는 잘알려진 암호를 허용한다.
  4. 안전하지 않게 만들어진 지식 기반 답변과 같은 취약하거나 효과가 없는 자격 증명 복구나 비밀번호 복구를 허용한다.
  5. 평문, 암호화되거나 취약한 해쉬 비밀번호를 사용한다.
  6. 다중 인증이 없거나 비효율적이다.
  7. 세션 ID가 URL에 노출된다.
  8. 세션 ID를 제대로 무효화 시키지 않으며, 로그아웃이나 비활성 기간 중에 사용자 세션 및 인증 토큰 이제대로 무효화 되지 않는다.
  • 공격 대응 방법
  1. 가능한 경우, 다중인증을 구현하여 자동화된 계정 정보 삽입,무차별 공격, 탈취된 계정 정보 재사용 공격을 예방한다.
  2. Admin 계정의 경우 기본 계정 정보를 사용하여 제공하거나 배포하지 않는다.
  3. 비밀번호를 생성하거나 변경할 때 최악의 Top 10000개 비밀번호 목록 이외로 설정하도록 하는 것과 같은 약한 비밀번호 검사를 구현한다.
  4. 암호 길이, 복잡성 및 순환 정책 또는 다른 최신 정책, 근거 기반암호 정책을 조정한다.
  5. 계정 열거공격에 대한 대비로 모든 결과에 대해 동일한 메시지를 사용하여 등록, 계정 정보 복구, API 경로를 강화한다.
  6. 로그인 실패에 대한 제한이나 시간 연기를 하십시오. 모든 실패에 대해 로그를 남기고 계정 정보 삽입, 무차별 공격, 다른 공격들이 탐지되면 관리자에게 알람이 오도록 설정한다.
  7. 로그인 이후에 예측 불허한 무작위 세션 ID를 생성하는 서버 측의 안전한 내장 세션 관리자를 사용한다. 세션 ID는 URL에 없어야 하며, 매우 안전하게 보관되어야 하고 로그아웃, 유휴 및 절대 시간 초과 이후 무효화되어야 한다.
  • 공격 시나리오
  1. 알려진 암호 목록을 사용한 계정 정보 삽입이 일반적이다. 애플리케이션이 자동화된 위협 또는 계정 정보 삽입 방어를 구현하지 않은 경우, 애플리케이션을 암호 오라클로 사용하여 계정 정보가 유효한지 확인할 수 있다.
  1. 대부분의 인증 공격은 암호를 유일한 인증 요소로 계속 사용하는 것으로 인해 발생하기 때문에 모범 사례로 간주된 비밀번호 주기와 복잡성 요구사항은 사용자가 취약한 비밀번호를 등록하고 재사용할 수 있도록 한다.
  1. 애플리케이션 세션에 대한 적절한 만료 시간이 정해지지 않기 때문에 사용자는 공용 컴퓨터로 애플리케이션에 접근, 로그아웃을 선택하지 않고 단순히 브라우저 탭을 닫고 나갔을 때, 한시간 이후에 공격자가 같은 브라우저를 사용한다면 사용자는 여전히 인증되어 있다. [2]

A3 민감한 데이터 노출

  • 민감한 데이터 노출(Sensitive Data Exposure)

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

  • 공격의 발생원인

우선 전송을 하거나 하지 않거나 데이터 보호 요구사항을확인한다. 패스워드, 신용카드 번호, 건강기록, 개인정보, 업무 기술들은 특별한 보호가 필요하며 금융 데이터 보호 규정에 해당된다면 특별히 보호해야 한다.

  1. 평문으로 데이터를 전송하는 프로토콜이 그런 경우이다. 외부 인터넷 트래픽은 특히 위험하기 때문에 로드 밸런서, 웹 서버, 백엔드 시스템 간의 내부 트래픽도 확인한다.
  2. 백업을 포함하여 저장할 때 평문으로 처리하는 민감한 데이터가있다.
  3. 오래되거나 취약한 암호 알고리즘을 이전 및 현재 소스 코드에 적용한다.
  4. 디폴트 암호 키 사용 및 약한 암호 키를 생성 및 재사용하거나 적절한 키 관리 및 변경이 이루어 진다.
  5. 사용자 프로그램(브라우저)에서 보안 디렉티브나 헤더와 같은 암호화를 적용한다.
  6. 사용자 프로그램(앱, 메일 클라이언트)에서 서버 인증이 유효한지 확인한다.
  • 공격 대응 방법
  1. 애플리케이션에서 사용하는 데이터를 처리, 저장, 전송으로 분류한다. 개인정보 보호법, 법률, 업무 필요에 따라 어떤 데이터가 민감한지 파악한다.
  2. 분류에 따라 통제한다.
  3. 불필요한 민감한 데이터는 저장하지 않으며, 가능한 빨리 그런 데이터를 폐기 및 규정을 준수하거나 불필요한 내용을 줄인다.
  4. 모든 민감한 데이터들을 암호화하는지 확인한다.
  5. 최신의 강력한 표준 알고리즘, 프로토콜, 암호 키를 사용하는지 확인한다.
  6. Perfect Forward Secrecy(PFS) 암호를 사용하는 TLS, 서버의암호 우선 순위 지정 및 보안 매개 변수와 같은 보안 프로토콜로 전송 중인 모든 데이터를 암호화 한다.
  7. 민감한 데이터를 포함하는 응답 캐시를 비활성화한다.
  8. 개별적으로 설정들의 유효성을 검증한다.
  • 공격 시나리오
  1. 애플리케이션은 자동화된 데이터베이스 암호화를 사용하여 데이터베이스의 신용 카드 번호를 암호화한다. 그러나 이 데이터는 검색될 때 자동으로 복호화되므로 SQL 삽입 결함으로 일반 텍스트의 신용 카드 번호가 검색될 수 있다.
  2. 모든 웹 페이지에 TLS를 반드시 사용하지 않거나 약한 암호화를 지원하는 사이트. 공격자는 쉽게 네트워크 트래픽을 모니터링하고 HTTPS를 HTTP로 낮추며, 요청을 중간에서 가로채고 사용자 세션 쿠키를 탈취한다. 이어서 공격자는 이 쿠키를 다시 사용해서 사용자의(인증된) 세션을 악용하여 사용자의 개인 정보에 접근하거나 수정한다. 금융 거래시 수취인과 같은 전송된 모든 데이터를 바꿀수도 있다.
  3. 패스워드를 저장할 때 솔트를 하용하지 않거나 간단한 해시를 사용하는 데이터베이스. 파일 업로드 취약점을 통해 공격자는 패스워드 데이터베이스를 가져올 수 있다. 솔트되지 않은 해시들은 미리 계산된 해시들을 가진 레인보우 테이블에 노출될 수 있다. 간단하거나 빠른 해시 함수로 만들어진 해시는 솔트를 적용했더라도 GPU를 이용하여 크랙될 수 있다. [2]

A4 XML 외부 개체

오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가한다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있다. [2]

  • 공격의 발생원인
  1. 애플리케이션이 직접 XML를 입력 받거나 특히 신뢰할 수 없는 곳의 XML를 업로드하거나 XML 문서에 신뢰할 수 없는 데이터를 입력할 경우. 이는 XML 프로세서가 처리한다.
  2. 애플리케이션에 있는 XML 프로세서나 웹 서비스 기반의 SOAP에 Document Type Definitions(DTD)이 활성화되어 있을 경우. DTD 처리를 비활성화하는 정확한 방법은 처리기마다 다르기 때문에 문서들을 참조해야 한다.
  3. 애플리케이션이 페더레이션 보안이나 싱글 사인온(SSO)의 목적으로 확인 처리를 위해 SAML을 사용할 경우.
  4. 애플리케이션이 1.2이전의 SOAP을 사용하고 있다면 XML 개체들이 SOAP 프레임워크에 넘겨질 경우 XXE 공격에 민감할 수 있다.
  5. XXE 공격에 취약하다는 것은 애플리케이션이 서비스 공격에 취약하다는 것을 의미한다.
  • 공격 대응 방법
  1. 가능할 때마다, JSON과 같은 덜 복잡한 데이터 형식을 사용하거나 민감한 데이터를 지양한다.
  2. 애플리케이션이나 운영체제에서 사용중인 모든 XML 프로세서와 라이브러리를 패치하거나 업그레이드한다. 의존성 체커를 사용하며, SOAP을 SOAP 1.2나 그 이상으로 업그레이드한다.
  3. OWASP Cheat Sheet 'XXE Prevention’에 따라 애플리케이션에 있는 모든 XML 파서의 XML 외부 개체와 Document Type Definitions(DTD) 처리를 비활성화한다.
  4. 서버에서 허용 목록(화이트리스트)을 이용한 입력값 검증, 필터링, 검사를 구현해서 XML 문서, 헤더, 노드에 있는 악의적인 데이터를 막는다.
  5. XML이나 XSL 파일 업로드 기능이 XSD 검증기 같은 것을 사용해서 XML이 유효한 내용인지 확인하고 검증한다.
  6. 많은 것들이 통합된 크고 복잡한 애플리케이션에서는 수동으로 소스코드 리뷰가 최선의 방법일 수 있으나, SAST는 소스코드에 존재하는 XXE를 탐지하는데 도움이 될 수 있습다.
  • 공격 시나리오
  1. 공격자는 서버에서 데이터를 가져오려고 시도한다.
  2. 공격자는 ENTITY 라인을 변경하여 서버의 사설망을 찾으려 한다.
  3. 공격자는 잠재적으로 무한 파일을 포함하여 서비스 거부 공격을 시도한다. [2]

각주

  1. 1.0 1.1 ChocoPeanut, 〈OWASP 및 모바일 OWASP〉, 《티 스토리》, 2017-04-20
  2. 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Architecture & IT Tech, 〈[인터넷 보안OWASP TOP10 에대해서 조사 및 분석]〉, 《티 스토리》, 2018-12-23

참고자료

  • ChocoPeanut, 〈OWASP 및 모바일 OWASP〉, 《티 스토리》, 2017-04-20
  • Architecture & IT Tech, 〈[인터넷 보안OWASP TOP10 에대해서 조사 및 분석]〉, 《티 스토리》, 2018-12-23
  • 공식홈페이지, 〈[1]〉, 《OWASP》

같이 보기

  검수요청.png검수요청.png 이 OWASP 문서는 보안에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.