"OWASP(The Open Web Application Security Project)"
오픈소스 웹 애플리케이션 보안 프로젝트이다.
주로 웹에 관한 정보 노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며
10대 웹 애플리케이션의 취약점 (OWASP TOP 10)을 발표했다.
Top Ten Overview (2017)
1번째 Injection (인젝션)
인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생한다.
공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다.
[공격종류]
| Error based SQL Injection | 논리적 에러를 이용한 SQL Injection |
| Union based SQL Injection | Union 명령어를 이용한 SQL Injection |
| Blind SQL Injection | 데이터베이스로부터 특정한 값이나 데이터를 전달받지 않고, 단순히 참과 거짓의 정보만 알 수 있을 때 사용함. |
| Stored Procedure SQL Injection | 저장된 프로시저 에서의 SQL Injection |
| Mass SQL Injection | 다량의 SQL Injection 공격 |
[방어기법]
1) Prepared Statement 구문 사용
2) Error Message 노출 금지
3) 웹 방화벽 사용
[참고]
https://noirstar.tistory.com/264
2번째 Broken Authentication (취약한 인증)
인증과 세션 관리와 관련된 애플리케이션 기능은 정확하게 구현되어 있지 않아서
공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점을 공격하여
다른 사용자 계정을 일시적 또는 영구적으로 탈취하는 것을 허용한다.
[공격기법]
1) Url에 세션 정보가 노출되도록 코딩하는 경우
2) 공공장소의 컴퓨터에서 사용되는 애플리케이션에서 세션 타임아웃이 없고, 로그아웃을 하지 않고 단순히 브라우저만 닫는 경우 세션이 유지되는 경우
3) 쿠키 변조(쿠키를 사용하는 웹페이지의 경우 쿠키를 암호화할 때 취약한 암호를 사용하는 경우)
[방어기법]
- 강력한 패스워드 정책
- 전송 중의 자격증명 보호
- SSL과 같은 로그인 트랜젝션 전체를 암호화
- 서버 측 인증 기술 사용
- Hidden Field, Client Side Cookie 보다는 Server Side의 Session ID 사용
- 인증 관련 정보는 Get 방식이 아닌 Post 방식으로 요청
- 동시 로그인 금지 및 암호화 채널 사용
[참고]
3번째 Sensitive Data Exposure (민감한 데이터 노출)
대부분의 웹 애플리케이션과 API는 금융정보, 건강정보, 개인 식별정보와 같은 민감 정보를 제대로 보호하지 않는다.
공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하는 취약한 데이터를 훔치거나 변경할 수 있다.
브라우저에서 중요 데이터를 저장 또는 전송할 때, 특별히 주의하여야 하며, 암호화와 같은 보호조치를 취해야 한다.
프로그램이 보안과 관련된 민감한 데이터를 평문으로 송·수신할 경우, 통신채널 스니핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있다.
[공격기법]
Base64 인코딩 복호화
=> Base64는 다른 이진 데이터 변환 규칙과 관계없이 아스키코드만으로 데이터를 인코딩하므로 플랫폼 제한 없이 사용할 수 있다. 그래서 디코딩할 수 있는 사이트에 입력 후 힌트의 원문을 출력할 수 있다.
[방어기법]
- 인증 정보와 같은 민감한 정보 전송 시 안전하게 암호화해서 전송해야 한다.
- 분석 단계에서 정의된 중요정보를 네트워크를 통해 전송해야 하는 경우 안전한 암호모듈로 암호화 한 뒤 전송하거나 안전한 통신 채널을 사용하도록 설계해야 한다. 안전한 암호화는 “암호연산” 요구 항목을 충족시키는 암호화 알고리즘이나 암호키를 사용해야 한다.
- 쿠키에 포함되는 중요 정보는 암호화해서 전송해야 한다.
- 쿠키에는 중요정보가 포함되지 않도록 설계해야 하지만 부득이 쿠키에 중요정보가 포함되어야 하는 경우에는 반드시 세션 쿠키로 설정되어야 하며, 전달되는 중요 정보는 반드시 암호화해서 전송해야 한다.
[참고]
https://01092090536.tistory.com/68
4번째 XML External Entities (XXE) (XML 외부 개체 (XXE))
XML 문서에서 동적으로 외부 URL의 리소스를 포함시킬 수 있는 외부 엔티티(Entity, 이하 엔티티)를 사용할 때 발생한다.
외부 엔티티는 파일 URL 처리기, 패치되지 않은 Windows 서버의 내부 SMB파일 공유, 내부 포트 검색, 원격 코드 실행 및 Billion Laughs 공격과 같은 서비스 거부 공격과 내부 파일 공개에 악용될 수 있다.
안드로이드 스튜디오, 인텔리제이(IntelliJ), 이클립스, APK툴이며 대부분의 안드로이드 통합 개발 환경(IDE)에서도 취약점이 발견된다. 이 취약점을 통틀어 파스 드로이드(ParseDriod)라고 보안 전문 업체 체크포인트가 명시했다.
주로 XML 외부 개체 취약점이 있다는 것이 공통점이다.
[공격기법]
사용자가 웹 애플리케이션으로 전달되는 XML 데이터를 직접 업로드하거나 수정할 수 있는 경우,
공격자는 외부 엔티티를 참조하는 XML 데이터를 전송하여
파일과 같은 서버 내부의 정보를 탈취하거나 서비스 거부 공격, SSRF 등의 공격을 할 수 있다.
[방어기법]
- XML Parser에서 DOCTYPE 태그를 사용하지 않도록 설정한다.
- 코드 상 DOCTYPE 태그를 포함하는 입력을 차단하도록 입력 검증을 사용한다.
- XML 파서에서 외부 엔티티를 금지해야 한다.
- JAXP와 Xerces와 같은 파서는 기본적으로 lib.xml에서 확장 엔티티를 해제해야 한다.
- 엔티티 기능을 비활성화한다.
- Libxml_use_internal_errors(true)
- Xml 파싱 도중 오류가 발생하였을 경우, 오류 메시지를 출력하지 않게 해주는 함수
- 오류 메시지를 해커에게 노출시키지 않는 것도 도움된다.
- Libxml_disable_entity_loader(true): 외부 리소스를 불러오지 못하게 하는 함수
[참고]
https://bangsj1224.tistory.com/entry/Chapter-15-XXE-%EA%B3%B5%EA%B2%A9
5번째 Broken Access Control (취약한 접근 통제)
취약한 접근 제어는 인증된 사용자가 수행할 수 있는 것에 대한 제한이 제대로 적용되지 않는 것을 의미한다.
공격자는 이러한 취약점을 악용하여 사용자의 계정 액세스, 중요한 파일 보기, 사용자의 데이터 수정, 액세스 권한 변경 등과 같은 권한 없는 기능, 또는 데이터에 액세스 할 수 있다.
[공격기법]
- 관리자 페이지 노출
- SSI 삽입
- SSI 란 Server Side Includes의 약자로서 웹페이지 내에서 CGI를 사용하지 않고서도 방문자 카운터, 최종 변경일 및 CGI 환경변수의 사용 등을 간단히 사용할 수 있게 해주는 것으로 CGI 환경변수뿐 아니라 일반적인 HTML 문서 및 특정 명령의 실행결과 등을 지정한 위치에 삽입할 수 있다.
- 부적절한 인가
[방어기법]
- 관리자 페이지에 임의의 사용자가 접근할 수 없도록 관리자 페이지에 접근할 수 있는 권한을 가진 단말기만 접근 가능하도록 접근권한을 설정한다.
- 웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP 주소까지도 인증 요소로 체크하도록 웹 관리자 사용자 인터페이스를 개발한다.
- 관리자 인증 후 접속할 수 있는 페이지의 경우 해당 페이지 주소를 직접 입력하여 접속하지 못하도록 관리자 페이지 각각에 대하여 관리자 인증을 위한 세션을 관리한다.
- 정보시스템(네트워크 장비, 서버, 응용프로그램, DB 등) 및 정보보호 시스템에 대한 접근은 사용자 인증, 로그인 횟수 제한, 불법 로그인 시도 경고 등 안전한 사용자 인증 절차에 의해 통제되어야 한다.
- 공개 인터넷망을 통하여 접속을 허용하는 주요 정보시스템의 경우 아이디, 패스워드 기반의 사용자 인증 이외의 강화된 인증수단(OTP, 공인인증서 등) 적용을 고려하여야 한다.
[참고]
6번째 Security Misconfiguration (잘못된 보안 구성)
훌륭한 보안은 애플리케이션, 프레임워크, 애플리케이션 서버, 웹 서버, 데이터베이스 서버 및 플랫폼에 대해 보안 설정이 정의되고 적용되어 있다.
기본으로 제공되는 값은 종종 안전하지 않기 때문에 보안 설정은 정의, 구현 및 유지되어야 한다. 또한 소프트웨어는 최신의 상태로 유지해야 한다.
[공격기법]
- 백업 파일 노출 : 특정 확장자(.bak) 파일들이 서버에서 적절하게 처리되지 못한 경우 소스가 유출될 수 있다는 것
- 디렉터리 리스팅 : 웹 서버에는 현재 브라우징 되는 디렉터리의 모든 파일들을 사용자에게 보여줄 수 있는 디렉토리 인덱스 기능이 대부분 존재한다. 그러나 이런 기능이 활성화되어 있는 경우 해커가 웹 애플리케이션의 구조를 파악할 수 있는 기회를 제공해 주며, 민감한 정보(개인정보가 담긴 xls 파일 등)가 포함된 설정 파일을 조회할 수 있게 된다.
- 설정 파일 및 환경변수 노출 : 일반적으로 웹 애플리케이션을 설정하기 위해 위치하는 파일들은 시스템이나 DB에 관련한 많은 정보를 포함하고 있다. 이런 파일들이 공격자에게 노출될 경우 공격자에게 시스템의 많은 정보를 제공하게 된다. 이것이 보안상 매우 위험한 일이다. 예를 들어, PHP를 사용하는 시스템에는 기본적으로 phpinfo.php라는 파일이 웹 서버 root에 설치되거나 또는 개발 시 시스템 환경을 참조하기 위해 직접 작성하여 사용한다.
[방어기법]
1) 불필요한 파일을 관리해야 한다.
2) 디렉터리 권한을 설정해야 한다.
3) 최소한의 사용자 계정을 사용해야 한다.
4) 운영체제, 웹/앱 서버, DBMS, 코드 라이브러리들의 소프트웨어 보안을 업데이트해야 합니다. 그렇지 않다면, 보안 위협이 생기지 않도록 구성해야 한다.
[참고]
https://hacking-beginner.tistory.com/184
7번째 Cross-Site Scripting (XSS) (크로스 사이트 스크립팅 (XSS))
XSS 취약점은 애플리케이션이 신뢰할 수 없는 데이터를 가져와 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생한다.
XSS는 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로 이동할 수 있다.
[공격종류]
- 저장 XSS 공격
- 웹 애플리케이션 취약점이 있는 웹 서버에 악성 스크립트를 영구적으로 저장해 놓는 방법이다.
- 이때 웹 사이트의 게시판, 사용자 프로필 및 코멘트 필드 등에 악성 스크립트를 삽입해 놓으면, 사용자가 사이트를 방문하여 저장되어 있는 페이지에 정보를 요청한다. 서버는 악성 스크립트를 사용자에게 전달하여 사용자 브라우저에서 스크립트가 실행되면서 공격한다.
- 반사 XSS 공격
- 웹 애플리케이션의 지정된 변수를 이용할 때 발생하는 취약점을 이용하는 것으로, 검색 결과, 에러 메시지 등 서버가 외부에서 입력받은 값을 받아 브라우저에게 응답할 때 전송하는 과정에서 입력되는 변수의 위험한 문자를 사용자에게 그대로 돌려주면서 발생한다.
- DOM 기반 XSS 공격
- DOM이란 W3C 표준으로 HTML 및 XML 문서에 접근방법을 표준으로 정의하는 문서 객체모델이다.
- 2005년에 처음으로 아밋 클라인이 관련 취약점 논문을 발표하면서 알려졌다.
- 피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 공격 스크립트가 DOM 생성의 일부로 실행되면서 공격한다.
- 페이지 자체는 변하지 않으나, 페이지에 포함되어 있는 브라우저 측 코드가 DOM 환경에서 악성코드로 실행된다.
[방어기법]
- 입/출력 값 검증 및 무효화
- 보안 라이브러리(AntiXSS, OWASP ESAPI 라이브러리)
- 브라우저 확장 프로그램
[참고]
https://kaite-story.tistory.com/79
http://www.kisa.or.kr/uploadfile/201312/201312161355109566.pdf
[CSRF와 비교]
사이트 간 요청 위조(CSRF)는 사용자의 의도와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 요청하게 하는 공격기법
비교XSSCSRF
| XSS | CSRF | |
| 공격 대상 | 클라이언트 | 서버 |
| 공격 시점 | 악성 스크립트가 심어진 게시물 등을 열었을 때 | 이메일 등을 통해 전달된 주소를 열었을 때 |
| 공격 방법 | 클라이언트의 브라우저에서 실행 | 정상적인 사용자가 서버에 요청(서버에서 실행) |
| 이용 허점 | 클라이언트가 웹사이트를 신뢰하는 상태 | 특정 웹사이트가 사용자를 신뢰하는 상태 |
8번째 Insecure Deserialization(안전하지 않은 역직렬화)
역직렬화란 서로 간에 원활한 통신을 위해 데이터를 스트림 하기 위해 직렬화를 시키고 그 직렬화된 데이터 스트림을 다시 받고 역직렬 화해서 데이터를 확인하는 과정을 말한다.
[공격기법]
역직렬화 취약점은 직렬화 형태로 처리되는 개체에 변조, 공격자 권한 상승 등의 문제가 발생되는 취약점이다.
공격자는 이처럼 악의적인 객체를 넘겨주고 애플리케이션이 이를 로드하는 과정에서 검증되지 않은 객체를 만들어 공격자가 의도한 행위가 실행된다.
애플리케이션이 악의적인 역직렬화 객체를 받으면 불안전한 역직렬화(Insecure Deseralization) 취약점이 발생하며, 원격코드가 실행된다. 역직렬화 취약점으로 인해 원격 코드가 실행되지 않아도 직렬화된 객체를 재생, 변조 또는 삭제하여 사용자를 속이거나 주입 공격을 받고 권한을 강화할 수 있다.
직렬화는 다음 용도의 애플리케이션에서 사용될 수 있다.
RPC(Remote-Process Communication)/IPC(Inter-Process Communication)
- 유선 프로토콜, 웹 서비스, 메세지 브로커
- 캐싱/ 지속 연결 • 데이터베이스, 캐시 서버, 파일 시스템
- HTTP 쿠키, HTML 양식 파라미터, API 인증 토큰
[방어기법]
- 악성 객체 생성이나 데이터 변조를 방지하기 위해 직렬화된 객체에 대한 디지털 서명과 같은 무결성 검사를 구현한다.
- 객체 생성 전 코드가 일반적으로 정의할 수 있는 클래스 집합을 기대하므로 역 직렬화 하는 동안 엄격한 형식 제약조건을 적용한다. 이 기법에 대한 우회가 입증되었으므로 여기에 의존하는 것은 바람직하지 않다.
- 가능하다면 낮은 권한 환경에서 역 직렬화 하는 코드를 분리하여 실행한다. 예상하지 않은 형식이 들어올 경우나 역 직렬 화가 예외를 생성할 경우에 실패에 대한 로그를 남긴다.
- 역 직렬 화하는 컨테이너 또는 서버에서 들어오고 나가는 네트워크 연결을 제한하거나 모니터링한다. 역 직렬화를 모니터링하여 사용자가 역 직렬화를 지속해서 할 경우에 경고한다.
[참고]
https://xbb123.tistory.com/160
9번째 Using Components with Known Vulnerabilities (알려진 취약점이 있는 구성요소 사용)
컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행된다.
이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다.
알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미친다.
[공격 발생원인]
1) 클라이언트와 서버 측면의 양쪽에서 사용하는 모든 구성 요소의 버전을 알지 못한다면, 취약할 가능성이 높다.
2) 소프트웨어가 취약하거나 지원되지 않거나 오래된 버전인 경우, 취약할 가능성이 높다.
(운영체제, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), 애플리케이션, API와 모든 구성요소, 런타임 환경과 라이브러리 포함)
3) 정기적으로 취약점을 스캔하지 않거나 사용 중인 컴포넌트와 관련된 보안 취약점 공지 서비스에 등록하지 않은 경우, 취약할 가능성이 높다.
4) 소프트웨어 개발자가 업데이트되거나 혹은 패치된 라이브러리의 호환성을 테스트하지 않는다면 취약할 가능성이 높다.
ex) CVE-2017-5638
[방어기법]
1) 패치 관리 프로세스
2) 사용하지 않는 종속성, 불필요한 기능, 구성 요소, 파일과 문서 등을 제거
3) versions, DependencyCheck, retire.js 와 같은 도구를 사용하여 클라이언트 및 서버 측의 구성 요소(예: 프레임워크, 라이브러리)와 해당 종속성의 버전을 지속적으로 관리
4) CVE와 NVD로부터 구성요소 내 취약점을 지속적으로 모니터링
5) 소프트웨어 구성 분석 도구를 사용하여 프로세스를 자동화
6) 사용하는 구성요소와 관련된 보안 취약점에 대한 전자메일 알림을 구독
7) 안전한 링크를 통해 공식적인 출처로부터 구성 요소를 획득
8) 조작되거나, 악의적인 구성 요소가 포함될 가능성을 줄이기 위해 서명된 패키지를 사용
[참고]
https://xbb123.tistory.com/160
10번째 Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링)
불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고 지속성을 유지하며 더 많은 시스템을 중심으로 공격할 수 있도록 만들고 데이터를 변조, 추출 또는 파괴할 수 있다.
대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고 이는 일반적으로 내부 프로세스와 모니터링보다 외부기관이 탐지한다.
[공격기법]
최근 애플리케이션은 API(SOAP/XML, REST/JSON, RPG, GWT)에 연결되는 브라우저 및 모바일 애플리케이션의 Javascript 와 같은 Rich Client Application과 API를 포함하는 경우가 많다.
이러한 API는 보호되지 않은 경우가 흔하며 다양한 취약점을 갖고 있다.
[방어기법]
클라이언트와 API 사이의 통신이 보호되고 있는지 확인해야 하며, API에 강력한 인증방식이 모든 인증정보, 키 및 토큰을 보호하고 있는지 살펴봐야 한다.
[참고]
'Security > WebHacking' 카테고리의 다른 글
| [HackCTF Web] 보물 (422) | 2019.11.28 |
|---|---|
| [HackCTF Web] Button (431) | 2019.11.20 |
| [HackCTF Web] Hidden (272) | 2019.11.19 |
| [HackCTF Web] / (295) | 2019.11.19 |
| [Websec.fr] Babysteps Level01 (285) | 2019.11.12 |