A01_2021-Broken Access Control(취약한 접근 제어)

기존 2020년도 취약점의 5번째 위치에서 1번째로 이동합니다.

A02_2021-Cryptographic Failures(암호화 실패)

기존 2020년도 취약점의 3번째 위치에서 2번째로 이동합니다.

A03_2021-Injection(인젝션)

기존 2020년도 취약점의 1번째 위치에서 3번째로 이동합니다.

A04_2021-Insecure Design(불안전한 디자인)

2021년도 신규항목입니다.

A05_2021-Security Misconfiguration(보안 구성 오류)

기존 2020년도 취약점의 6번째 위치에서 5번째로 이동합니다.

A06_2021-Vulnerable and Outdated Componets(취약하고 오래된 구성요소)

기존 2020년도 취약점의 9번째 위치에서 6번째로 이동합니다.

A07_2021-Identification and Authentication Failures(식별 및 인증실패)

기존 2020년도 취약점의 2번째 위치에서 7번째로 이동합니다.

A08_2021-Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)

2021년도 신규항목입니다.

A09_2021-Security Logging and Monitoring Failures(보안 로깅 및 모니터링 실패)

기존 2020년도 취약점의 10번째 위치에서 9번째로 이동합니다.

A10_2021-Server-Side Request Forgery(SSRF) (서버 측 요청 위조)

2021년도 신규항목입니다.

CSRF : 사이트간 요청 위조

- 웹 애플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 하여 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격방법을 의미한다.

• 정의만 보면 앞서 알아봤던 사이트간 요청 위조

- 웹 애플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 하여 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격방법을 의미한다.

정의만 보면 크로스 사이트 스크립팅, SQL Injection 공격과 비슷하다.

XSS가 사용자가 특정 사이트를 신뢰한다는 점을 공격하는 거라면, CSRF는 특정 사이트가 사용자의 브라우저를 신뢰한다는 점을 공격하는 것이다르다.

간단하게 정리하자면, 악성코드가
XSS : 클라이언트에서 발생

CSRF : 서버에서 발생

이라고 할 수 있다.

시나리오

1. XX 관리자 중 한명이 관리 권한을 가지고 회사내에서 작업을 하던 중 메일을 조회한다.
(로그인이 이미 되어있다고 가정하면 관리자로서의 유효한 쿠키를 갖고있음)

2. 해커는 다음과 같이 태그가 들어간 코드가 담긴 이메일을 전송한다. 관리자는 Image 크기가 0이므로 눈치채지 못한다.

...

<img src="http://xx.com/changeUserAccount?id=admin&password=admin" width="0" height="0">

...

3. 피해자가 이메일을 열어볼 때, 이미지 파일을 받아오기 위해 URL이 열린다.

4. 해커가 원하는 대로 관리자의 계정이 id와 pw 모두 admin인 계정으로 변경된다.

방어방법

1. Referrer 검증

request Header에 있는 요청을 한 페이지의 정보가 담긴 referrer 속성을 검증하여 차단.

일반적으로 이 방법만으로도 대부분 방어가 가능할 수 있다.

같은 도메인 상에서 요청이 들어오지 않는다면 차단하도록 설정하는 것이다.

2. CSRF Token 사용

랜덤한 수를 사용자의 세션에 저장하여 사용자의 모든 요청(Request)에 대하여 서버단에서 검증하는 방법.

•  로그인시, 또는 작업화면 요청시 CSRF 토큰을 생성하여 클라이언트 Session에 전송한다.

session.setAttribute("CSRF_TOKEN",UUID.randomUUID().toString());

• 요청 페이지에 CSRF 토큰을 셋팅하여 전송한다.

<input type type="hidden" name="_csrf" value=$[csrf_token]" />

3. CAPTCHA 사용

요즘은 거의 모든 웹사이트에서 캡차를 이용하는 것 같은데 캡차이미지상의 숫자/문자가 아니라면 해당 요청을 거부하는 것이다.

이 외에도 form 태그를 입력할 시 GET방식을 지양하고 POST방식을 쓰도록 하는 것이 기본이라고 할 수 있다.

톰캣 컨테이너 세션 (jsessionid)

• Tomcat 컨테이너에서 Session을 유지하기 위해 발급하는 키이다.
• http Protocol은 Stateless하다. 요청할 때마다 새로운 연결이 생성되고 응답후 연결은 끊기게 되므로 상태를 유지할 수 없다.
• 따라서, 상태를 저장하기 위해서 Tomcat은 jsessionid 쿠키(jessionid의 Session유지 방법으로 내부적으로 쿠키를 사용한다)를 클라이언트에게 발급해주고 이 값을 통해 세션을 유지할 수 있도록 한다.
• 각 Client에 해당하는 Session 객체는 서버에서 유지되고 있지만 클라이언트에서 요청이 올 때 이전에 접근했던 사용자인지 처음 접근하는 사용자인지 구별하기 위해서 jsessionid를 사용한다.

쿠키(Cookie)

쿠키는 사용자가 웹사이트를 방문할 때 웹 Brower를 통해 전송되어 사용자의 컴퓨터 하드디스크에 저장되는 작은 Text파일을 말하며 주요 역할은 다음과 같다.

• 사용자 인증 정보를 기억함으로써 웹사이트 내 특정 페이지에 접속할 때마다 로그인을 새로 해야 하는 수고를 덜어준다.
• 쇼핑정보, 관심사, 지역 등 사용자에 관한 다양한 정보를 저장함
• 사용자에게 개인화 된 광고를 보여주거나 리마케팅 등을 통해 보다 효과적인 광고 운영이 가능하도록 한다.
• 구글 애널리틱스와 같은 웹분석 데이터 수집 혹은 정보 추적의 용도로 사용한다.
• 브라우저 단위로 생성한다. 크롬, IE와 같이 서로 다른 브라우저는 상호간에 생성된 쿠키를 볼 수 ㅇ벗다.
• 웹사이트 단위로 생성한다. 웹사이트 A(예:네이버)는 웹사이트 B(예: 구글)에서 생성한 쿠키에 접근할 수 없다.
• HTTP 쿠키, 웹 쿠키, 인터넷 쿠키 또는 브라우저 쿠키라고도 한다.

쿠키의 유형

유형에 따른 분류

• 1사 쿠키 : 사용자가 방문한 웹사이트에 의해 생성된 쿠키로서 이 1사 쿠키를 발급한 웹사이트만 이들 쿠키를 읽을 수 있다.
• 3사 쿠키 : 사용자가 방문한 웹사이트가 아닌 제3의 웹사이트에 의해 생성된 쿠키를 말한다.

만료 날짜 존재 여부에 따른 분류

• 임시 쿠키(temporary Cookie) : 만료 날짜가 정해지지 않은 쿠키로서 사용자가 Web Session을 종료하거나 브라우저창을 닫으면 삭제된다.
• 지속 쿠키(persistent Cookie) : 만료 날짜가 정해져 있는 쿠키로서 한 번 생성되면 인위적으로 삭제하기 전에는 만료일까지 컴퓨터에 남아있다.

쿠키의 종류

구글 애널리틱스 쿠키 (_ga)

• 구글 애널리틱스는 고유한 사용자를 식별하고 이들 사용자의 세션과 캠페인 정보를 저장하는데 쿠키를 사용한다.
• 현재 우리가 주로 사용하는 유니버셜 애널리틱스(Universal Analytics)는 '_ga'라는 단일 쿠키를 사용한다.
• 사용자가 웹 사이트를 방문하면 구글 애널리틱스 추적코드(GATC, Google Analytics Tracking Code)가 실행되며 '_ ga' 쿠키가 존재하는지를 먼저 파악한다.
• 기존 쿠기가 존재하면 이 쿠키를 갱신하여 사용하며, 존재하지 않는다면 새로운 쿠키를 생성한다.
• '_ga'쿠키는 사용자가 방문한 웹사이트에 의해 생성되는 1사 쿠키이자, 세션이 종료되더라도 유지되는 지속 쿠키(persistent cookie)에 해당한다.
• 이 쿠키는 아래와 같이 4 개의 숫자 세트로 구성되며 '고객ID(Client ID)'라는 사용자 개개인을 구분하는 데 사용되는 매우 중요한 정보를 담고 있다.

구글 애널리틱스 쿠키의 구성요소

'_ga'쿠키는 각각의 의미를 갖는 네 개의 문자/숫자 세트로 구성된다.

1. 첫 번째 세트 GA1은 사용되고 있는 쿠키 포맷의 버전을 나타낸다. 현재는 GA1으로 고정되었다. 향후 쿠키 포맷이 변경되면 이와함께 달라질 수 있다.

2. 두 번째 세트는 점(dot)으로 구분되는 도메인 구성요소의 수를 의미한다.
ex) example.com=2, example.co.kr = 3, sub.example.co.kr = 4

3. 세 번째 세트는 무작위로 생성된 숫자 세트로 고유의 사용자를 식별하는데 사용한다.

4. 네 번째 세트는 사용자가 웹사이트에 처음 방문할 때의 타임스탬프(timestamp)를 나타낸다.

※ 세 번째 및 네 번째 필드값이 합쳐서 고객 ID를 구성한다.

쿠키와 고객 ID (Client ID)

구글 애널리틱스는 고객 ID를 통해 여러 GA세션에 걸쳐서 고유의 사용자를 식별한다.

• 사용자 웹사이트를 처음 방문하면 GA 쿠키가 생성되며 여기에는 고객ID가 저장된다. 이후 사용자가 웹 사이트에 방문해서 보인 행동으로 수집되는 모든 히트(페이지 뷰, 이벤트 및 거래) 정보에는 고객ID가 포함되며, 구글 애널리틱스는 이 고객ID를 토대로 웹사이트를 방문한 사용자의 히스토리를 통합해서 보여주게 된다
• 구글 애널리틱스는 사용자가 실제로 누군지를 알 필요는 없기 때문에 웹 분석 목적으로 이처럼 쿠키를 통해 사용자들을 상호 구분한다. 같은 맥락에서 GA는 개인 식별 정보(persionally indentifiable infomation)를 쿠키에 저장하지 않는다.
• GA쿠키(Client ID)는 쿠키가 생성된 기기 및 브라우저에서만 존재한다. 사용자가 한 컴퓨터 내에서 서로 다른 두 개의 브라우저를 사용한다면 서로 다른 두 개의 고객 ID가 생성된다. GA쿠키는 또한 기기간 상호 공유되지 않는다. 따라서 서로 다른 기기에서는 서로 다른 쿠기가 생성되고 서로 다른 사용자로 인식된다.
• 이러한 이유로 GA는 기본 값으로 다양한 기기와 브라우저를 사용해서 방문하는 고유의 사용자를 식별할 수 없다. 하지만 회원 로그인 등 개별 사용자를 식별할 수 있는 정보가 있다면 사용자 ID 설정(참조:구글 도움말)을 통해 하나의 사용자로 인식(교차 기기 추적, cross device tracking)할 수 있다.
• 고객 ID는 GA의 사용자 지표에 해당한다.

쿠키와 사용자ID(User ID)

• 사용자 ID는 다양한 웹 브라우저와 기기를 통해 방문하는 고유의 사용자를 식별하는데 사용되는 고유의 ID를 말한다.
• 구글 애널리틱스가 직접 생성, 운영하는 고객 ID와 달리, 사용자 ID는 웹 사이트의 사용자 인증 시스템을 통해 생성하고 사용자가 로그인할 때 별도의 설정을 통해 구글 애널리틱스에 전송되는 방식으로 운영된다.

• 구글 서비스 약관에 따르면 사용자 ID는 사용자의 이름, 이메일 주소와 같은 개인 식별 정보를 포함해서는 안된다.

기타 쿠키에 관한 정보

쿠기는 얼마동안 유지됩니까?

GA 쿠키는 기본 값으로 2년 동안 유지된다. 사용자가 웹사이트에 방문할 때마다 마지막 방문일로부터 2년 기간으로 만료 시점이 연장된다.

쿠키와 캠페인 유지기간?

GA 쿠키는 캠페인 정보또한 저장하고 있다. 사용자의 유입 캠페인은 직접 유입을 제외한 새로운 유입채널을 이용할 때마다 변경된다. 그리고 마지막으로 갱신된 캠페인은 새로운 캠페인으로 유입되기 전까지 6개월 동안 유지된다.

쿠키를 삭제하다면?

쿠키 사용의 단점 중 하나는 사용자가 언제든 쿠키를 삭제할 수 있다는 점이다. 사용자가 웹사이트에 방문하면 해당 트래픽 정보는 고객 ID와 함께 구글 애널리틱스로 전송된다. 이 사용자가 쿠키를 삭제한 후 다시 방문하게 되면 새로운 고객 ID가 발급되어 전송되며, 따라서 구글 애널리틱스는 이 사용자를 신규 사용자로 인식한다.

크롬 로그인 및 동기화

크롬에서 사용자 프로필을 생성하여 로그인하면 서로 다른 기기에서 북마크 등을 공유할 수 있는 한편 하나의 기기 내에서 다수의 사용자를 만들어서 사용하는 것도 가능하다. 하지만 이들 사용자간 쿠키는 전송/공유 되지 않는다.

서브 도메인과 교차 도메인 이슈

쿠키는 사이트 단위로 생성된다. 구글 애널리틱스는 서브도메인(예:"example.com"과 "sub.example.com")간 자동으로 작동되도록 고안되었다.

따라서 한 사용자가 이들 두 사이트를 번갈아가며 방문했을 때도 동일한 쿠키가 유지된다.

교차 도메인(예: "example.com"과 "exampleblog.com")은 서브도메인과는 아주 다르다. 이 두 사이트는 비즈니스 관점에서는 연관되어 있을지 모르나 웹사이트 관점에서는 전혀 다른 사이트로 간주된다. 따라서 쿠키가 상호 공유되지 않는다.

쿠기와 고객ID를 정확하게 이해하면 서브도메인 및 교차도메인 추적 과정에서 부딫치는 문제들을 해결하는 데도 큰 도움이 될 수 있다.