웹 주요 보안 취약점 정리

서론

OWASP (The Open Web Application Security Project, 오픈소스 웹 애플리케이션 보안 프로젝트) 는 웹에 관한 정보누출, 악성파일 및 스크립트, 보안 취약점 등을 연구하며, 10대 웹 애플리케이션의 취약점 (OWASP TOP10) 을 발표했다.

가장 최근 발표인 2017년 기준 OWASP TOP 10 에 대한 내용과 더불어 CORS, CSRF, XSS, CSP 에 대한 내용도 해당 페이지 다룬다.

 

본론

1. OWASP Top 10 Overview (2017)

A1 Injection (인젝션)

SQL, OS, XXE(Xml eXternal Entity), LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생한다. 공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다.

 

A2 Broken Authentication (취약한 인증)

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

 

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

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

 

A4 XML External Entities (XXE) (XML 외부 개체 (XXE))

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

 

A5 Broken Access Control (취약한 접근 통제)

취약한 접근 제어는 인증된 사용자가 수행할 수 있는 것에 대한 제한이 제대로 적용되지 않는 것을 의미한다. 공격자는 이러한 취약점을 악용하여 사용자의 계정 액세스, 중요한 파일 보기, 사용자의 데이터 수정, 액세스 권한 변경 등과 같은 권한 없는 기능, 또는 데이터에 액세스할 수 있다.

 

A6 Security Misconfiguration (잘못된 보안 구성)

훌륭한 보안은 애플리케이션, 프레임워크, 애플리케이션 서버, 웹 서버, 데이터베이스 서버 및 플랫폼에 대해 보안 설정이 정의되고 적용되어 있다. 기본으로 제공되는 값은 종종 안전하지 않기 때문에 보안 설정은 정의, 구현 및 유지되어야 한다. 또한 소프트웨어는 최신의 상태로 유지해야 한다.

 

A7 Cross-Site Scripting (XSS) (크로스 사이트 스크립팅 (XSS))

XSS 취약점은 애플리케이션이 신뢰할 수 없는 데이터를 가져와 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생한다. XSS는 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로 이동할 수 있다.

 

A8 Insecure Deserialization(안전하지 않은 역직렬화)

안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다. 역직렬화 취약점이 원격 코드실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있다.

 

A9 Using Components with Known Vulnerabilities (알려진 취약점이 있는 구성요소 사용)

컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행된다. 이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다. 알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미친다.

 

A10 Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링)

불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부기관이 탐지한다.

 

2. CSRF, XSRF (Cross-Site Request Forgery: 사이트 간 요청 위조)

사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정,삭제,등록 등) 을 특정 웹사이트에 요청하게 하는 공격이다.

사용자가 웹사이트에 로그인 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.

 

 

CSRF 공격은 공격자에 의해 위조된 요청으로 공격이 진행되므로 실제 서버에서 발행한 페이지가 맞는지 CSRF 토큰으로 확인하여 공격을 방지한다.

이에 대한 프로세스는 아래와 같다.

인증 -> View전달(CSRF 토큰) -> 요청 (CSRF 토큰) -> CSRF 토큰 확인 -> 거부 or 확인 -> 토큰 삭제

 

3. CORS (Cross-Origin Requets Sharing: 교차출처 요청 공유)

브라우저 환경에서만 적용되며, 한 출처가 다른 출처에 요청을 할 수 있도록 하는 보안 메커니즘이다.

모든 브라우저는 단일출처정책(Single Origin Policy)을 따른다. 즉, 기본적으로 다른 출처에 요청을 할 수 없지만, 서버가 적절하게 구성된 CORS 헤더를 제공하는 경우 선택적으로 교차출처정책을 사용할 수 있게된다.

 

기본적으로 다른출처에 요청을 하면 브라우저는 먼저 pre-flight options 요청을 보낸다.

원래 요청은 서버가 허용된 출처 목록에 요청하는 출처가 포함된 경우에만 이루어진다.

하지만 기본 헤더가 있는 GET, HEAD, POST 요청에서는 pre-flight 요청을 보내지 않는다. 이것을 "단순요청" 이라고 한다.

 

Cross-origin 요청에는 두가지 요청 방식이 있는데 "단순요청(Simple Request)" 와 "비단순요청 혹은 예비요청 (pre-flight)" 이 있다.

예비요청을 하는 목적은 사용자 데이터에 영향을 줄 수 있기 때문에 미리 실제 요청을 전송하기에 안전한지 확인한다.

하지만 서비스에 따라 방화벽에서 options 가 차단되어 예비요청을 못하는 경우도 있다.

단순요청과 예비요청에 대한 자세한 사항은 MDN 문서 를 확인하자.

 

CORS 와 관련된 HTTP 헤더는 아래와 같다.

 

4. Same-origin policy: 동일출처 정책

어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 보안 방식이다.

프로토콜, 호스트(도메인 or ip), 포트 중 한 가지라도 다르다면 동일출처가 성립되지 않는다.

 

 

5. XSS (Cross-Site Scripting: 교차 사이트 스크립팅)

공격자가 클라이언트 측 스크립트를 웹 페이지에 삽입하는 공격이다.

주로 여러 사용자가 사용하는 게시판이에 악성 스크립트가 담긴 글을 올리는 형태로 이루어지며, 

웹 애플리케이션이 사용자로부터 입력받은 값을 제대로 검사하지 않고 사용할 경우 나타난다.

 

OWASP 에도 있듯이, 공격자가 사용자의 정보(쿠키, 세션 등)을 탈취하거나, 자동으로 비정상적인 기능을 수행하게 할 수 있으며, 주로 다른 웹사이트와 정보를 교환하는 식으로 작동한다.

 

동일출처정책(Same-origin policy) 및 CSRF 보호를 모두 우회할 수 있으며, 

사용자가 웹사이트를 방문할 때마다 트리거되고, 이는 서버를 손상시킬 수 있다.

 

OWASP 에는 XSS 삭제우회, XSS 방지 치트 시트 를 참고하자.

 

6. CSP (Content Security Policy: 콘텐츠 보안 정책)

XSS 공격을 감지하고 완화하기 위한 추가 보안계층이다.

스크립트를 실행가능한 화이트리스트를 만들어 화이트리스트 도메인에서 로드된 스크립트만 실행한다.

스크립트, 스타일시트, 이미지, 글꼴, 개체, 미디어(오디오, 비디오), 프레임 및 양식작업을 포함한 모든 동적원본에 대해 허용된 원본을 지정할 수 있다.

 

CSP 는 Content-Security-Policy HTTP 헤더를 통해 설정된다.

 

CORS 와의 차이점은 CORS 는 제3자가 서버에 액세스하는 것을 방지하는 반면 CSP 는 XSS 에 대한 방어로 웹사이트 자체가 제3자로부터 콘텐츠를 로드하지 못하도록 차단한다는 것이다.

CSP 는 XSS 를 모두 막을 수 있는것은 아니지만 도움이 된다.

 

결론

이러한 웹보안 취약점들에 대해 방지를 하기 위해서는 프론트엔드, 백엔드 모두 신중한 설계와 이스케이핑, 필터링을 통해 방지하면 좋겠지만 설계 난이도가 복잡하고, 구현하기 어려울 수 있으며, 충분한 테스트가 없다면 배포 후 중단될 수도 있다.

그렇기에 웹 애플리케이션의 사용환경에 따라 적절하게 필요한 점은 수용하고, 고민을 해보자

 

 

참고자료

https://ko.wikipedia.org/wiki/OWASP

OWASP - 위키백과, 우리 모두의 백과사전

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS

교차 출처 리소스 공유 (CORS) - HTTP | MDN

https://developer.mozilla.org/ko/docs/Web/Security/Same-origin_policy

동일 출처 정책 - 웹 보안 | MDN

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Security-Policy

Content-Security-Policy - HTTP | MDN

https://chanto11.tistory.com/67#recentComments

[웹 보안] CSRF, CORS, XSS, CSP