위키원
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]
- 공격의 발생원인
- 사용자 제공 데이터가 유효하지 않거나, 필터링 되어 지지 않거나, 애플리케이션에 의해 정제되지 않는다. 상황인식기반 필터링 없이 동적 쿼리나 매개 변수화 되지 않은 호출이 인터프리터에서 사용되며, 악의적인 데이터가 객체 관계형 매핑(ORM) 검색매개변수 내에서 사용되어 추가로 민감한 정보를 추출한다. 악의적인 데이터가 직접적으로 동적 쿼리안에 포함된 구조적 데이터와 악의적 데이터를 포함한 명령어, 일반명령어, SQL, 저장 프로시저에 사용되며 연결한다.
- 공격 대응 방법
- 인젝션을 예방하기 위해서는 데이터를 지속적으로 명령어와 쿼리로 부터 분리시켜야 한다. 기본 옵션은 인터프리터 사용을 피하거나, 매개 변수화 된 인터페이스를 제공하는 안전한 애플리케이션 프로그래밍 인터페이스(API)를 사용하거나 ORMs 툴을 사용하여 마이 그레이션 하는 것이다. 매개변수화 된 경우에도 PL/SQL이나 트랜잭트 SQL(Transact-SQL), 데이터/쿼리가 연결되거나 악의적인 데이터가 EXECUTE IMMEDIATE 를 함께 실행한다면 저장 프로시저는 SQL인젝션을 실행한다.
- 서버 측 화이트리스트나 적극적인 입력값 유효성 검증을 해야한다. 남은 동적 쿼리들을 위하여 특정 필터링 구문을 사용하여 인터프리터에 대한 특수 문자를 필터링 처리 한다. 테이블, 컬럼 이름 등과 같은 SQL구조는 필터링 처리를 할 수가 없기 떄문에 사용자가 제공한 구조 이름은 안전하지 않다.
- LIMIT과 다른 SQL 컨트롤 쿼리를 사용하여 SQL인젝션으로 인한 대량 노출을 예방한다.[2]
A2 취약한 인증
- 취약한 인증(Broken Authentication)
- 인증과 세션 관리와 관련된 애플리케이션 기능이 정확하게 구현되어 있지 않아서, 공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점을 공격하여 다른 사용자 계정을 일시적 또는 영구적으로 탈취하는 것을 허용한다.[2]
- 공격의 발생원인
- 인증과 관련된 공격으로부터 보호하기 위해서 사용자의 신원, 인증 및 세션을 관리하는 것이 매우 중요하다. 공격자가 유효한 사용자 이름과 비밀번호를 가진 상태에서 계정 정보 삽입과 같은 자동화 공격을 허용하며, 무차별 공격 또는 기타 자동화 공격을 허용한다. Password1 또는 admin/admin 과 같은 기본 암호, 약한 암호 또는 잘알려진 암호를 허용하고, 안전하지 않게 만들어진 지식 기반 답변과 같은 취약하거나 효과가 없는 자격 증명 복구나 비밀번호 복구를 허용한다. 평문, 암호화되거나 취약한 해쉬 비밀번호를 사용하여 다중 인증이 없거나 비효율적이다. 세션 ID가 URL에 노출되고 세션 ID를 제대로 무효화 시키지 않으며, 로그아웃이나 비활성 기간 중에 사용자 세션 및 인증 토큰이 제대로 무효화 되지 않는다.
- 공격 대응 방법
- 가능한 경우, 다중인증을 구현하여 자동화된 계정 정보 삽입,무차별 공격, 탈취된 계정 정보 재사용 공격을 예방한다.
- Admin 계정의 경우 기본 계정 정보를 사용하여 제공하거나 배포하지 않는다.
- 비밀번호를 생성하거나 변경할 때 최악의 Top 10000개 비밀번호 목록 이외로 설정하도록 하는 것과 같은 약한 비밀번호 검사를 구현한다.
- 암호 길이, 복잡성 및 순환 정책 또는 다른 최신 정책, 근거 기반암호 정책을 조정한다.
- 계정 열거공격에 대한 대비로 모든 결과에 대해 동일한 메시지를 사용하여 등록, 계정 정보 복구, API 경로를 강화한다.
- 로그인 실패에 대한 제한이나 시간 연기를 하십시오. 모든 실패에 대해 로그를 남기고 계정 정보 삽입, 무차별 공격, 다른 공격들이 탐지되면 관리자에게 알람이 오도록 설정한다.
- 로그인 이후에 예측 불허한 무작위 세션 ID를 생성하는 서버 측의 안전한 내장 세션 관리자를 사용한다. 세션 ID는 URL에 없어야 하며, 매우 안전하게 보관되어야 하고 로그아웃, 유휴 및 절대 시간 초과 이후 무효화되어야 한다.
- 공격 시나리오
- 알려진 암호 목록을 사용한 계정 정보 삽입이 일반적이다. 애플리케이션이 자동화된 위협 또는 계정 정보 삽입 방어를 구현하지 않은 경우, 애플리케이션을 암호 오라클로 사용하여 계정 정보가 유효한지 확인할 수 있다. 대부분의 인증 공격은 암호를 유일한 인증 요소로 계속 사용하는 것으로 인해 발생하기 때문에 모범 사례로 간주된 비밀번호 주기와 복잡성 요구사항은 사용자가 취약한 비밀번호를 등록하고 재사용할 수 있도록 한다. 애플리케이션 세션에 대한 적절한 만료 시간이 정해지지 않기 때문에 사용자는 공용 컴퓨터로 애플리케이션에 접근, 로그아웃을 선택하지 않고 단순히 브라우저 탭을 닫고 나갔을 때, 한시간 이후에 공격자가 같은 브라우저를 사용한다면 사용자는 여전히 인증되어 있다.[2]
A3 민감한 데이터 노출
- 민감한 데이터 노출(Sensitive Data Exposure)
- 많은 웹 애플리케이션들이 신용카드, 개인 식별 정보 및 인증 정보와 같은 중요한 데이터를 제대로 보호하지 않는다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하는 등 약하게 보호된 데이터를 훔치거나 변경할 수 있으며, 중요 데이터가 저장 또는 전송 중이거나 브라우저와 교환하는 경우 특별히 주의하여야 하며, 암호화와 같은 보호조치를 취해야 한다.[2]
- 공격의 발생원인
- 우선 전송을 하거나 하지 않거나 데이터 보호 요구사항을확인한다. 패스워드, 신용카드 번호, 건강기록, 개인정보, 업무 기술들은 특별한 보호가 필요하며 금융 데이터 보호 규정에 해당된다면 특별히 보호해야 한다. 평문으로 데이터를 전송하는 프로토콜이 그런 경우이다. 외부 인터넷 트래픽은 특히 위험하기 때문에 로드 밸런서, 웹 서버, 백엔드 시스템 간의 내부 트래픽도 확인한다.백업을 포함하여 저장할 때 평문으로 처리하는 민감한 데이터가 있으며,오래되거나 취약한 암호 알고리즘을 이전 및 현재 소스 코드에 적용한다. 디폴트 암호 키 사용 및 약한 암호 키를 생성 및 재사용하거나 적절한 키 관리 및 변경이 이루어 진다. 사용자 프로그램(브라우저)에서 보안 디렉티브나 헤더와 같은 암호화를 적용하고, 사용자 프로그램(앱, 메일 클라이언트)에서 서버 인증이 유효한지 확인한다.
- 공격 대응 방법
- 애플리케이션에서 사용하는 데이터를 처리, 저장, 전송으로 분류한다. 개인정보 보호법, 법률, 업무 필요에 따라 어떤 데이터가 민감한지 파악한다.
- 분류에 따라 통제한다.
- 불필요한 민감한 데이터는 저장하지 않으며, 가능한 빨리 그런 데이터를 폐기 및 규정을 준수하거나 불필요한 내용을 줄인다.
- 모든 민감한 데이터들을 암호화하는지 확인한다.
- 최신의 강력한 표준 알고리즘, 프로토콜, 암호 키를 사용하는지 확인한다.
- Perfect Forward Secrecy(PFS) 암호를 사용하는 TLS, 서버의암호 우선 순위 지정 및 보안 매개 변수와 같은 보안 프로토콜로 전송 중인 모든 데이터를 암호화 한다.
- 민감한 데이터를 포함하는 응답 캐시를 비활성화한다.
- 개별적으로 설정들의 유효성을 검증한다.
- 공격 시나리오
- 애플리케이션은 자동화된 데이터베이스 암호화를 사용하여 데이터베이스의 신용 카드 번호를 암호화한다. 그러나 이 데이터는 검색될 때 자동으로 복호화되므로 SQL 삽입 결함으로 일반 텍스트의 신용 카드 번호가 검색될 수 있다. 모든 웹 페이지에 TLS를 반드시 사용하지 않거나 약한 암호화를 지원하는 사이트. 공격자는 쉽게 네트워크 트래픽을 모니터링하고 HTTPS를 HTTP로 낮추며, 요청을 중간에서 가로채고 사용자 세션 쿠키를 탈취한다. 이어서 공격자는 이 쿠키를 다시 사용해서 사용자의(인증된) 세션을 악용하여 사용자의 개인 정보에 접근하거나 수정한다. 금융 거래시 수취인과 같은 전송된 모든 데이터를 바꿀수도 있다. 패스워드를 저장할 때 솔트를 하용하지 않거나 간단한 해시를 사용하는 데이터베이스. 파일 업로드 취약점을 통해 공격자는 패스워드 데이터베이스를 가져올 수 있다. 솔트되지 않은 해시들은 미리 계산된 해시들을 가진 레인보우 테이블에 노출될 수 있다. 간단하거나 빠른 해시 함수로 만들어진 해시는 솔트를 적용했더라도 GPU를 이용하여 크랙될 수 있다.[2]
A4 XML 외부 개체
- XML 외부 개체(XML External Entities)
- 오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가한다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있다.[2]
- 공격의 발생원인
- 애플리케이션이 직접 XML를 입력 받거나 특히 신뢰할 수 없는 곳의 XML를 업로드하거나 XML 문서에 신뢰할 수 없는 데이터를 입력할 경우. 이는 XML 프로세서가 처리한다. 애플리케이션에 있는 XML 프로세서나 웹 서비스 기반의 SOAP에 Document Type Definitions(DTD)이 활성화되어 있을 경우. DTD 처리를 비활성화하는 정확한 방법은 처리기마다 다르기 때문에 문서들을 참조해야 한다. 애플리케이션이 페더레이션 보안이나 싱글 사인온(SSO)의 목적으로 확인 처리를 위해 SAML을 사용할 경우 애플리케이션이 1.2이전의 SOAP을 사용하고 있다면 XML 개체들이 SOAP 프레임워크에 넘겨질 경우 XXE 공격에 민감할 수 있다. XXE 공격에 취약하다는 것은 애플리케이션이 서비스 공격에 취약하다는 것을 의미한다.
- 공격 대응 방법
- 가능할 때마다, JSON과 같은 덜 복잡한 데이터 형식을 사용하거나 민감한 데이터를 지양한다.
- 애플리케이션이나 운영체제에서 사용중인 모든 XML 프로세서와 라이브러리를 패치하거나 업그레이드한다. 의존성 체커를 사용하며, SOAP을 SOAP 1.2나 그 이상으로 업그레이드한다.
- OWASP Cheat Sheet 'XXE Prevention’에 따라 애플리케이션에 있는 모든 XML 파서의 XML 외부 개체와 Document Type Definitions(DTD) 처리를 비활성화한다.
- 서버에서 허용 목록(화이트리스트)을 이용한 입력값 검증, 필터링, 검사를 구현해서 XML 문서, 헤더, 노드에 있는 악의적인 데이터를 막는다.
- XML이나 XSL 파일 업로드 기능이 XSD 검증기 같은 것을 사용해서 XML이 유효한 내용인지 확인하고 검증한다.
- 많은 것들이 통합된 크고 복잡한 애플리케이션에서는 수동으로 소스코드 리뷰가 최선의 방법일 수 있으나, SAST는 소스코드에 존재하는 XXE를 탐지하는데 도움이 될 수 있다.
- 공격 시나리오
- 공격자는 서버에서 데이터를 가져오려고 시도하며, 공격자는 ENTITY 라인을 변경하여 서버의 사설망을 찾으려 한다. 공격자는 잠재적으로 무한 파일을 포함하여 서비스 거부 공격을 시도한다. [2]
A5 취약한 접근 통제
- 취약한 접근 통제(Broken Access Control)
- 인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 다른 사용자의 데이터를 수정하거나, 접근 권한을 변경하는 등 권한 없는 기능과 데이터에 접근할 수 있다.[2]
- 공격의 발생원인
- URL, 내부 애플리케이션 상태나 HTML 페이지 조작, 맞춤형 API 공격툴을 통해 접근통제 절차를 우회할 수 있다. 기본 키가 다른 사용자의 레코드로 변경되도록 허용하고 다른 계정의 정보를 열람하거나 편집할 수 있도록 허용되어 있다면 접근통제에 실패한다. 로그인 하지 않고 활동하는 사용자나 일반 사용자로 로그인하여 관리자 처럼 활동하는 사용자가 있다면 권한상승이 가능한 상태이다. JSON 웹 토큰 (JWT)의 접근 통제 토큰 재전송이나 변경, 권한 상승 목적으로 쿠키나 감춰진 필드 조작, JWT 토큰 무효화 악용 등과 같은 메타 데이터 조작 행위가 허용된다면 접근 통제에 실패한 것이다. CORS에 대한 설정이 잘못되어 있을 경우 인가되지 않은 API에 접근을 허용할 수 있다. 인증 절차를 거치지 않은 사용자가 인증이 필요한 페이지를 둘러보게 하거나, 권한이 필요한 페이지에 일반 사용자가 접근해 보도록 하거나 메소드에 대한 접근통제를 적용하지 않은 API를 사용해 보게끔 함으로써 접근통제 실패 여부를 확인할 수 있다.
- 공격 대응 방법
- 불특정 다수에게 공개된 자원을 제외하곤 디폴트 정책은 차단으로 운영해야 한다.
- CORS 사용 최소화를 포함한 접근통제 절차를 구현하고 애플리케이션 전체에 적용해야 한다.
- 접근통제 모델은 사용자에게 특정 레코드를 생성/열람/수정/삭제 할 수 있는 권한을 허용하기 보다는 레코드 소유자만 권한을 갖게 끔 강제해야 한다.
- 유일한 애플리케이션 비즈니스의 제한 요구 사항들은 도메인 모델에 의해 적용되어야 한다.
- 웹 서버상의 디렉토리 리스팅 기능을 비활성화 하고 .git과 같은 메타데이터와 백업파일들이 웹 루트에 존재하지 않게끔 운영해야 한다.
- 접근 통제에 실패한 경우에는 기록되어야 하고, 반복적인 실패가 발생하는 것과 같이 적절한 시점에 관리자에게 경고 메시지가 전송되어야 한다.
- 자동화 공격 툴로 인한 피해를 최소화 하기 위해 API와 컨트롤러에 대한 접근 임계치를 제한해야 한다.
- JWT토큰은 로그아웃 이후 무효화 되어야 한다.
- 공격 시나리오
- 공격자는 브라우저에서 서버로 전송되는 시점에 아래와 같은 형태로 acct 파라미터를 원하는 값으로 수정할 수 있고, 만약 입력 값을 적절히 검증하지 않는다면 다른 사용자의 계정에 접근하게 될 수도 있다. 공격자가 브라우저를 통해 원하는 대상의 URL을 직접 입력할 경우 접근 대상이 Admin 페이지라면 관리자외의 인원은 접근할 수 없어야 한다. 인가되지 않은 사용자가 요청한 페이지에 접근할 수 있거나, 관리자외의 인원이 Admin 페이지에 접근할 수 없다.[2]
A6 잘못된 보안 구성
- 잘못된 보안 구성(Security Misconfiguration)
- 잘못된 보안 구성은 가장 흔하게 보이는 이슈이다. 취약한 기본 설정, 미완성, 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과로, 모든 운영체제, 프레임워크, 라이브러리와 애플리케이션을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치/ 업그레이드를 진행해야 한다.[2]
- 공격의 발생원인
- 애플리케이션 스택 전 영역에 적절한 보안 강화 절차가 누락된 상태이거나 클라우드 서비스 상에 권한이 부적절하게 설정되어 있다. 불필요한 기능이 활성화 되거나 설치되어 있고, 디폴트 계정과 비밀번호가 활성화 되어 있거나 해당 정보들을 변경없이 사용하고 있다. 에러 처리 과정에서 스택 추적 정보나 공격에 도움이 될만한 다른 정보들을 노출하고 있다. 업그레이드된 시스템 상에 최신 보안 기능들이 비활성화 되어 있거나 안전하게 설정되어 있지 않다. 애플리케이션 서버, 프레임워크(예:Struts, Spring, ASP.NET),라이브러리, 데이터베이스 상에 보안 설정이 되어 있지 않다. 서버가 보안 헤더, 보안 강화 수단을 보내지 않거나 안전한 값을 설정하지 않고 있다. 구 버전이나 취약한 버전의 소프트웨어를 사용하고 있다.
- 공격 대응 방법
- 위험을 적절하게 차단할 수 있도록 빠르고 쉽게 다른 환경으로 전환할 수 있는 반복적인 보안 강화 절차를 적용해야 한다. 개발, 품질 관리, 운영 환경은 환경 별로 상이한 자격 증명 정보를 사용하고 동등한 보안 수준으로 설정되어야 하며, 새로운 보안 환경을 구축하는데 소모되는 리소스를 최소화 하기 위해 절차를 자동화 해야 한다.
- 불필요한 기능, 구성 요소, 문서, 샘플 애플리케이션 없이 최소한으로 플랫폼을 유지하고 사용하지 않는 기능과 프레임워크는 삭제하거나 설치하면 안된다.
- 패치 관리 절차의 일부분으로 모든 보안 정보, 업데이트, 패치를 대상으로 설정을 적절히 검토하고 갱신하는 절차가 필요하다.
- 세분화, 컨테이너화, 클라우드 보안 그룹과 같은 방법으로 구성 요소나 입주자들 간에 효율적이고 안전한 격리를 제공하는 세분화된 애플리케이션 아키텍처를 적용해야 한다.
- 보안 해더와 같은 보안 강화 수단을 사용자에게 전송해야 한다.
- 모든 영역의 보안 설정이 적절히 반영되어 있는지 검증할 수 있는 자동화된 절차를 수립해야 한다.
- 공격 시나리오
- 알려진 취약점을 포함하고 있는 샘플 애플리케이션이 삭제되지 않은 채로 애플리케이션 서버가 운영 환경에서 사용 중이라면, 샘플 애플리케이션은 공격자가 서버를 공격하는데 악용될 수 있다. 샘플 애플리케이션 중에 관리 콘솔이 포함되어 있고 디폴트 계정 정보가 변경되지 않았다면, 공격자는 디폴트 패스워드를 사용해 접속에 성공함으로써 권한을 획득할 수 있다. 서버 내 디렉토리 리스팅이 비활성화되지 않았다면, 공격자는 디렉토리 목록이 노출됨을 발견하게 되고 자바 클래스 파일을 다운로드하여 디컴파일과 리버스엔지니어링을 통해 애플리케이션 상에 존재하는 심각한 접근 통제 취약점을 찾아낼 수 있다. 사용자에게 전달하는 응답 메시지 상에 스택 추적 정보와 같은 상세한 에러 메시지를 노출하도록 애플리케이션 서버가 설정되어 있다면, 구성 요소 버전 정보와 같은 공격에 도움을 줄 수 있는 민감한 정보나 내부적인 결함들이 잠재적으로 노출될 수 있다. 클라우드 서비스 제공자가 다른 클라우드 서비스 이용자들이 인터넷을 통해 접근 가능한 상태로 디폴트 공유 권한을 열어둔 상태라면, 클라우드 스토리지에 저장되어 있는 민감한 데이터에 대한 접근을 허용할 수 있다.[2]
A7 크로스 사이트 스크립팅
- 크로스 사이트 스크립팅(Cross-Site Scripting)
- XSS 취약점은 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생하며, XSS는 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션을 탈취할 수 있게 만들고, 웹 사이트를 변조시키고, 악성 사이트로 리다이렉션할 수 있도록 허용한다.[2]
- 공격의 발생원인
- 리플렉티드 XSS은 HTML 출력의 일부로써 유효성이 확인되지 않고, 특수문자가 필터되지 않은 사용자 입력이 애플리케이션 혹은 API에 포함된다. 공격이 성공하면 공격자는 피해자의 브라우저에서 임의의 HTML과 자바스크립트를 실행할 수 있다. 전형적으로 사용자는 악의적인 워터링 홀 공격을 수행하는 웹 사이트, 광고 사이트 혹은 이와 유사한 공격자에 의해 제어되는 페이지를 가리키는 몇몇 악의적인 링크와 상호 작성을 해야 한다. 저장 XSS은 응용 프로그램 또는 API에서 나중에 다른 사용자 또는 관리자가 볼 수 있는 정제되지 않은 사용자 입력값이 저장되며, 저장 XSS는 종종 높은 혹은 중대한 위험으로 간주된다. DOM 기반 XSS은 페이지에 공격자가 제어 가능한 데이터를 동적으로 포함할 수 있는 자바스크립트 프레임워크, 한 페이지 애플리케이션, 그리고 API는 DOM 기반 XSS에 취약하다. 애플리케이션은 안전하지 않은 자바스크립트 API로 공격자가 제어 가능한 데이터를 보내지 않는다. 전형적인 XSS 공격은 세션 도용, 계정 탈취, 다중 요소 인증 우회, 트로이 목마 악성코드 배포 로그인 패널과 같은 DOM 노드 대체 혹은 변조, 악성코드 다운로드, 키 로깅, 그리고 다른 클라이언트 측면의 공격과 같은 사용자 브라우저에 대한 공격을 포함한다.
- 공격 대응 방법
- 최신 ROR(Ruby on Rails), React JS와 같이 XSS를 자동으로 필터링 처리하는 프레임워크를 사용한다. 각 프레임워크의 XSS 보호의 한계를 알아보고 다루지 않은 사용 사례들을 적절히 처리해야 한다.
- HTML 출력 내 컨텍스트 기반으로 신뢰할 수 없는 HTTP 요청 데이터를 필터링하며 리플렉티드 및 저장 XSS 취약점을 해결한다.
- 클라이언트 측에서 브라우저 문서를 수정할 때 상황에 맞는 인코딩을 적용하면 DOM XSS에 대해 대응할 수 있다.
- 컨텐츠 보안 정책(CSP)의 활성화는 XSS에 대한 심층적인 방어 통제이다. 로컬 파일 첨부를 통해 악성코드를 배치할 수 있는 다른 취약점이 없는 경우라면 효과적이다.
- 공격 시나리오
- 애플리케이션은 유효성 검사 또는 필터링 처리없이 다음의 HTML 조각의 구성 내 신뢰할 수 없는 데이터를 사용한다. 공격자는 XSS를 사용하여 애플리케이션이 사용할 수 있는 자동화된 크로스 사이트 요청 변조(CSRF) 방어를 무력화 할 수 있다.[2]
A8 안전하지 않는 역직렬화
- 안전하지 않는 역직렬화(Insecure Deserialization)
- 안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어지며, 역직렬화 취약점이 원격 코드 실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있다.[2]
- 공격의 발생원인
- 객체 및 데이터 구조 관련 공격이다. 공격자가 애플리케이션 로직을 수정하거나 애플리케이션에 사용 가능한 클래스가 있는 경우 임의의 원격 코드를 실행하여 역직렬화 중이나 이후에 동작을 변경할 수 있다. 접근 통제 관련 공격과 같이, 기존 데이터 구조가 사용되지만 내용이 변경되는 일반적인 데이터 변조 공격이다.
- 공격 대응 방법
- 악성 객체 생성이나 데이터 변조를 방지하기 위해 직렬화된 객체에 대한 디지털 서명과 같은 무결성 검사를 구현한다.
- 객체 생성 전 코드가 일반적으로 정의할 수 있는 클래스 집합을 기대하므로 역직렬화하는 동안 엄격한 형식 제약 조건을 적용한다.
- 가능하다면 낮은 권한 환경에서 역직렬화하는 코드를 분리하여 실행한다.
- 예상하지 않은 형식이 들어올 경우나 역직렬화가 예외를 생성할 경우 등 예외나 실패에 대한 로그를 남긴다.
- 역직렬화하는 컨테이너 또는 서버에서 들어오고 나가는 네트워크 연결을 제한하거나 모니터링 한다.
- 역직렬화를 모니터링하여 사용자가 역직렬화를 지속적으로 할 경우에 경고 한다.
- 공격 시나리오
- 리액트 애플리케이션은 일련의 스프링 부트 마이크로 서비스를 호출한다. 코드가 변경되지 않도록 하며, 이들이 제기한 해결책은 사용자 상태를 일련 번호로 변환하고 각 요청과 함께 앞뒤로 전달한다. 공격자는 자바 객체 서명을 확인하고 자바 직렬 킬러 도구를 사용하여 애플리케이션 서버에서 원격 코드 실행을 얻는다.[2]
A9 알려진 취약점이 있는 구성 요소 사용
- 알려진 취약점이 있는 구성 요소 사용(Using Components with Known Vulnerabilities)
- 라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 컴포넌트는 애플리케이션과 같은 권한으로 실행된다. 만약에 취약한 컴포넌트가 악용된 경우, 이는 심각한 데이터 손실을 일으키거나 서버가 장악되며, 알려진 취약점이 있는 컴포넌트를 사용한 애플리케이션과 API는 애플리케이션 방어를 약화시키거나 다양한 공격과 영향을 주게 한다.[2]
- 공격의 발생원인
- 클라이언트와 서버 측면의 양쪽에서 사용하는 모든 구성 요소의 버전을 알지 못한다면, 취약할 가능성이 있다. 여기에는 직접 사용하는 구성 요소와 중첩된 종속성이 포함된다. 소프트웨어가 취약하거나, 지원되지 않거나, 오래된 버전인 경우, 취약할 가능성이 있다. 여기에는 운영체제, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), 애플리케이션, API와 모든 구성요소, 런타임 환경과 라이브러리 등이 포함된다. 정기적으로 취약점을 스캔하지 않거나, 사용 중인 컴포넌트와 관련된 보안 취약점 공지 서비스에 등록하지 않은 경우, 취약할 가능성이 있다. 위험 기반으로 적절한 시기에 플랫폼, 프레임워크와 종속성을 수정하거나 업그레이드하지 않은 경우, 취약할 가능성이 있다. 이는 패치 적용이 변경 통제 하에서 매월 또는 분기별 작업하는 환경에서 일반적으로 발생하며, 이로 인해 조직은 며칠 또는 몇 달 동안 수정된 취약점에 불필요하게 노출될 수 있다. 소프트웨어 개발자가 업데이트된, 업그레이드된 혹은 패치된 라이브러리의 호환성을 테스트하지 않는다면 취약할 가능성이 있다.
- 공격 대응 방법
- 사용하지 않는 종속성, 불필요한 기능, 구성 요소, 파일과 문서등을 제거한다.
- 안전한 링크를 통해 공식적인 출처로부터 구성 요소를 획득한다. 조작되거나, 악의적인 구성 요소가 포함될 가능성을 줄이기 위해 서명된 패키지를 사용한다.
- 유지 관리되지 않거나, 이전 버전의 보안 패치를 만들지 않는 라이브러리 및 구성 요소를 모니터링하며, 패치가 불가능한 경우, 발견된 문제를 모니터링, 탐지 혹은 보호하기 위해 가상 패치를 배포하는 것을 고려한다.
- 공격 시나리오
- 일반적으로 구성요소는 애플리케이션 자체와 동일한 권한으로 실행되므로 구성요소의 결함으로 인해 심각한 영향을 받을 수 있다.[2]
A10 불충분한 로깅 및 모니터링
- 불충분한 로깅 및 모니터링(Insufficient Logging & Monitoring)
- 불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부 기관이 탐지한다.[2]
- 공격의 발생원인
- 로그인, 로그인 실패, 그리고 높은 가치를 가진 트랜잭션들과 같은 감사해야 할 이벤트들이 기록되지 않는다. 경고 및 오류에 대해 로그 메시지가 없거나, 불충분하거나 불명확하다. 의심스러운 활동에 대해 애플리케이션과 API의 로그를 모니터링하지 않는다. 로그를 단지 로컬에만 저장한다. 적절한 경고 임계값과 응답 에스컬레이션 프로세스가 적절하지 않거나 효과적이지 않다. DAST 도구(OWASP ZAP)를 통한 침투 테스트 및 검사는 경고들을 추적하지 않는다. 애플리케이션은 실시간 혹은 거의 실시간으로 유효한 공격을 탐지, 에스컬레이션 또는 경고할 수 없다. 사용자나 공격자에게 로깅이나 경고 이벤트가 보여질 수 있다면, 정보 유출에 취약하다.
- 공격 대응 방법
- 모든 로그인, 접근 통제 실패, 그리고 서버 측면의 입력값 검증 실패 등이 의심스럽거나 악의적인 계정을 식별할 수 있는 충분한 사용자 문맥으로 기록될 수 있는지 확실히 해야한다.
- 중앙 집중적 로그 관리 솔루션에 의해 쉽게 사용될 수 있는 형식으로 로그가 생성되는지 확인한다.
- 부가 가치가 높은 거래에는 단지 추가만 가능한 데이터베이스 테이블 혹은 유사한 것과 같은 변조나 삭제를 방지하기 위한 무결성 통제 기능을 갖춘 감사 추적 기능을 확인한다.
- 의심스러운 활동이 적시에 탐지되고 대응될 수 있도록 효과적인 모니터링 및 경고를 설정한다.
- 공격 시나리오
- 소규모 팀이 운영하는 오픈소스 프로젝트 포럼 소프트웨어는 그 소프트웨어 내 결함이 악용되어 해킹당했을 때, 공격자는 다음 버전과 모든 포럼 내용이 포함된 내부 소스코드 저장소를 삭제한다. 소스코드를 복구할 수 있었지만, 모니터링, 로깅 혹은 경고의 부재는 훨씬 더 큰 불이익을 초래한다. 공격자는 공통 암호를 사용하는 사용자를 찾기 위해 스캔을 한다. 이 암호를 사용하여 모든 계정을 탈취할 수 있다. 다른 모든 사용자의 경우, 이 스캔은 단지 하나의 잘못된 로그인 기록만을 남기며, 며칠 후 다른 비밀번호로 이 작업을 반복할 수 있다. 미국의 한 주요 소매 업체는 첨부 파일을 분석하는 내부 악성코드 분석 샌드박스를 갖고 있다. 샌드박스 소프트웨어는 잠재적으로 원치않은 소프트웨어를 탐지했지만, 아무도 이 탐지에 대응하지 않았고, 샌드박스는 외부 은행에 의한 사기성 카드 거래로 인해 그 보안사고가 탐지되기 전까지 얼마 동안 경고를 표시했다.[2]
각주
참고자료
- ChocoPeanut, 〈OWASP 및 모바일 OWASP〉, 《티스토리》, 2017-04-20
- Architecture & IT Tech, 〈(인터넷 보안)OWASP TOP10 에대해서 조사 및 분석〉, 《티스토리》, 2018-12-23
- OWASP 공식홈페이지 - https://owasp.org/www-project-top-ten
같이 보기
