Content Table

{: #my_toc} {:.inline_toc}

cm-toc v.0.4 By 코마

HTTP 헤더 하드닝 파트 1

쉽고 간편한 HTTP 헤더 보안

03 Sep 2019 by 코마 (gbkim1988@gmail.com)

안녕하세요 코마입니다. 오늘은 HTTP 헤더 하드닝에 대해 알아보도록 하겠습니다. 😺

개요

HTTP 는 우리 삶에 있어 가장 가까이 있는 프로토콜이 아닌가 하는 생각이 듭니다. HTTP 를 모르면 개발자가 아닐 정도이지요. 이에, 저 코마는 HTTP 보안에 대해서 조금 자세히 살펴보려고 합니다. 만약 기존 개발을 하시거나 처음 공부를 하려는 분들에게 이 글이 적합한 것 같습니다. 그럼 여행을 떠나 볼까요?

HttpOnly 플래그

마이크로소프트의 시니어 보안 프로그램 매니저인 마이클 하워드(Michael Howard)는 XSS 공격의 대다수는 session 쿠키를 목적으로 한다고 언급합니다. 그리고 HttpOnly 플래그를 통해 이러한 위협을 억제할 수 있다고 언급한바 있습니다.

그렇다면, java 코드를 통해서 HttpOnly 를 설정하는 방법을 알아볼까요?

Cookie cookie = getMyCookie("myCookieName"); // 쿠키 정보를 가져온다.
cookie.setHttpOnly(true); // 쿠키 속성에 HttpOnly 플래그를 설정한다.


위의 코드를 통해서 서버의 HTTP 응답 헤더에 아래의 포맷의 데이터가 전송됩니다. 아래의 포맷에서 HttpOnly 플래그에 우선 집중해 주세요.

Set-Cookie: <name>=<value>[; <Max-Age>=<age>] 
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]
  1. www.example.com 에 접속합니다.
  2. editcookie 확장 플러그인을 chrome 에 설치해주세요.
  3. 자신의 이름을 키로 한 쿠키를 생성합니다. 저의 경우 code-machina=yes 라고 지정하였어요
  4. 그리고 Http Only 를 체크표시해줍니다.
  5. 개발자 도구(F12)를 활성화 하고 콘솔(Console) 창에서 document.cookie 를 입력해주세요


어떤가요? document.cookie 를 입력하였을 때 code-machina 와 같은 문구가 보이나요? 보이지 않다면 어려분은 HttpOnly 플래그를 설정한 쿠키의 특성을 실습하셨습니다.

이제, 여러분이 중요하다고 여기는 세션쿠키 등에 대해서 HttpOnly 플래그를 설정하고 XSS 취약점이 발생할 경우 그 영향도를 대폭 줄일 수 있게되었습니다.

Secure 플래그

MiTM 위협으로부터 HTTP 프로토콜은 안전하지 않습니다. 따라서 SSL/TLS 암호화를 이용한 HTTP 통신이 필요해졌습니다. 이에, 등장한 것이 HTTPS 입니다.

Secure 플래그는 중간자 공격에 대해서 세션 쿠키 정보를 보호하는데 효과적입니다. 만약에 여러분의 인증 정보가 HTTP 통신을 통해서 전송된다고 가정해볼까요?

이 경우 중간에서 패킷을 관찰하는 공격자의 쉬운 먹이감이됩니다. 즉, 암호화를 통해서만 쿠키 값을 전송하도록 하는 설정이 필요하다는 생각이 들게됩니다.

이를 위해서 Secure 플래그를 설정하며 Secure 플래그를 설정하게 될 경우 HTTPS 통해서만 전송되게 됩니다.



  1. example.com 에 https 로 접속을 하도록합니다.
  2. editcookie 를 통해서 Secure 플래그가 설정된 쿠키 값을 생성합니다.
  3. 개발자 도구의 네트워크 패널을 통해서 http 로 전송될 경우 쿠키가 전송되는지 확인합니다.
  4. 따란~! 👏 쿠키가 HTTP 통신으로는 전송되지 않음을 확인하였습니다.

어떤가요? 중요한 정보를 전송할 때는 Secure 플래그를 반드시 설정해야겠다는 마음가짐이 생기지 않나요? 실제로 구글 등의 거대 IT 기업들은 이미 이러한 설정을 마친 상태입니다. 사소한 곳에도 보안을 실천하는 기업이군요!

SameSite 플래그

교차 전송이라는 용어가 있습니다. 영어로는 cross-site request 입니다. 문뜩 머리에서 CSRF 와 XSS 가 떠오르신다면 보안 공부를 탄탄히 다져 놓으신 것입니다. 👏

그렇다면 아래의 상황을 가정해 볼까요?

교차 전송을 통해 임의의 공격자가 내 정보를 다른 사이트로 전송하는 스크립트를 특정 페이지에 삽입하였고 이로 인하여 내 정보가 유출되었다.

상당히 까다로운 조건입니다. 그러나 위에서 언급한 쿠키 헤더 보안만 잘해도 이러한 공격으로부터 자유로울 수 있음을 명심해 주세요!

본론으로 돌아와서 SameSite 플래그는 다른 도메인으로의 쿠키 전송을 차단하는 역할을 하고 있습니다. 이를 위해서 두가지 옵션을 제공하는데요. 그것은 바로 Strict 와 lax 입니다.

우선, strict 의 경우 엄격한 규칙을 제공하며 default 값인 lax 의 경우 상대적으로 유연한 보안을 제공해줍니다.

사례를 들어볼까요? (저 코마는 내용을 설명하는데 있어 사례만큼 좋은게 없다고 생각합니다.)



만약, github 와 같은 private 깃헙 프로젝트를 회사의 토론장이나 이메일에 링크로 남겨놓았다고 생각해볼까요? 이 사이트는 깃헙을 sso 처럼 로그인하므로 사실상 github 사이트의 계정이나 마찮가지 입니다. 그러나, 링크를 따라서 실제로 깃헙페이지에 접속하였을 때는 세션 쿠키 정보가 전달되지 않아 프로젝트에 접근이 불가능합니다.

그러나 lax 의 경우 좀 더 유연한 정책을 가져갈 수 있습니다. 즉, 보안성과 사용 용이성의 사이에서 균형을 잘 잡았습니다. 위의 사레에서 link 를 통해서 리다이렉트 하는 경우 세션 쿠키가 정상적으로 전달됩니다. 그러나 POST 요청과 같은 CSRF가 발생할 수 있는 요청 메서드는 차단되게 됩니다.

Host Only 플래그

원래 쿠키는 domain 을 지정합니다. 예를 들어 domain=.yes24.com 이라고 설정된 경우는 www.yes24.com 혹은 ticket.yes24.com 등에서 쿠키 정보가 허용이됩니다. 그러나 Host Only 플래그를 설정할 경우 서브 도메인에 대해 쿠키 정보를 공유하지 않게 됩니다.



쿠키의 종류와 용도

뒤늦게 😢 쿠키의 용도와 종류를 간략히 소개해 드릴까해요. 쿠키는 아래와 같은 용도로 사용됩니다.

그렇다면 쿠키의 종류는 어떤게 있을까요?

세션쿠키는 클라이언트를 종료할 경우 삭제됩니다. 이는 Expires 또는 Max-Age 디렉티브를 설정하지 않았기 때문입니다. 하지만, 웹 브라우저가 session 복구 기능을 제공할 경우 대부분의 세션 쿠키들은 영구적일 수 있습니다. 이는 브라우저가 영원히 닫히지 않은 것처럼 사용할 수 있도록 해줍니다.

영구 쿠키는 특정 일자 혹은 특정 기간 동안에 삭제되지 않는 것을 의미합니다. Expires (만료), Max-Age (보존 기간)을 의미합니다. 그리고 그 이전까지는 쿠키가 삭제되지 않고 남아있습니다.



마무리

지금까지 쿠키 플래그에 대한 보안 방법에 대해서 알아보았어요. 😍 알면 알수록 쉽고 재미있는 기술인 것 같습니다. 여러분들도 이러한 짜투리 지식을 잘 관리하셔서 회의 때 이러한 플래그 설정의 중요성을 한번 어필해 보시는 것은 어떨까요?

아직 드릴 이야기가 무궁무진하니 좀 더 지켜봐주시면 더욱 감사할 것 같아요! 여러분이 Vue.js 를 장난감처럼 가지고 노는 그날까지 저 코마는 멈추지 않겠습니다. 대한민국 IT인 여러분들의 건승을 기원합니다.

지금까지 코마 였습니다.

구독해주셔서 감사합니다. 더욱 좋은 내용으로 찾아뵙도록 하겠습니다. 감사합니다



링크 정리

이번 시간에 참조한 링크는 아래와 같습니다. 잘 정리하셔서 필요할 때 사용하시길 바랍니다.

이 작가의 다음 글 감상