모의해킹 스터디 3주차 과제: 로그인, 쿠키, 세션, 세션ID

 <현재 환경 세팅>

1. Virtual Box 7.1.4 + 우분투 리눅스 20.04

2. 우분투 APM (Apache2 + PHP + MySQL)

3. 기본 웹 루트 경로 /var/www/html

4. VScode SSH

5. 사진 등은 termius

 

 

 

※ 제대로 복습하기 전에 백지 복습해보기

아래는 제대로 복습하기 전 강의 내용 중 기억에 남은 내용을 이해한대로 써내려간 것입니다.

근데 이제 코딱지와 껌을 곁들인..

서론

 

   우린 여러 사이트를 이용할 때 회원가입이란 것을 한다. 그래야 서버가 나를 알아보고 서비스에 접근할 권한을 주기 때문이다. 나를 알아보는 것이 "식별"이고 내가 맞다고 확인하는 것이 "인증"이다. 이 일련의 과정은 회원가입과 로그인 시에 처리된다. 여기까진 그렇다 치는데 문제는 서비스의 이용에 있다.

 

   로그인을 한 뒤 서버에 파일을 요청해도 (특정 페이지로 가려고 해도) 서버는 내가 나인지 기억을 못한다. 그래서 원래대로라면 내가 티스토리에 로그인 해도 내 블로그에 들어가려면 또 로그인해야하고, 마이페이지에 접속하려면 또 로그인을 해야하는 문제가 발생한다. 개발자들은 이것을 문제로 여겼고 방법을 찾으려 애썼다. 그렇게 찾은 방법이 바로 쿠키와 세션, 세션ID이다. 덕분에 우리는 사이트 한 번 이용하는데 로그인 백 번 할 필요가 없어진 것이다. 

 

   하지만 사이트의 자원을 착취하려는 블랙 해커들은 어떻게든 우회하려 하기 마련이다. 이런 우회 기법들을 배우고 연구하기에 앞서 쿠키와 세션, 세션ID, 그리고 로그인 처리의 여러 종류에 대해서 정확히 이해하고 있어야 한다. 아래부터는 제대로 복습하기에 앞서 강의에서 들은 내용을 내 머리에 남아있는만큼 써내려가 볼 것이다.  

 

본론

• 쿠키?

   쿠키는 서버가 이용자에게 붙이는 딱지이다. 코딱지가 더 기억에 남는다면 그렇게 받아들여도 좋을 것 같다. 아무튼 서버는 나한테 코딱지를 붙이고 내가 또 다른 파일(페이지)을 요청했을 때 나에게 붙은 코딱지를 보고 내가 서비스에 접근할 자격이 있음을 알아본다. (...근데 자기가 붙인 코딱지라는 걸 어떻게 알아보는 걸까? 코딱지의 DNA 같은 것을 보고 자기가 줬다고 판별하나..? 아니면 서버마다 붙이는 위치를 지정하나..?)

 

   쿠키만으로도 우리는 로그인을 백만 번 할 필요가 없어진다. 그럼 쿠키만 쓰면 되는 거 아니냐, 세션, 세션ID는 또 뭐냐, 있어보이려고 만든거냐! 이런 생각을 할 수도 있는데 쿠키엔 치명적인 보안 취약점이 있기 때문에 이것만 쓰기엔 위험했다.

 

   위에 말했듯이 쿠키는 서버가 나에게 붙이는 코딱지이다. 서버는 내가 가지고 있는 코딱지로 이 사람이 로그인을 했음을, 다른 페이지에 접근할 자격이 있음을 판별한다. 그럼 내가 이 코딱지를 다른 사람한테 옮겨 붙이면? 혹은 다른 사람이 내 코딱지를 가져다 자기한테 붙이면? 이 코딱지를 반으로 갈라(?) 자기가 가지면? (웩) 서버는 이제부터 그 사람을 나로 인식하고 서비스를 제공하게 될 것이다. 코딱, 아니 쿠키는 그정도로 탈취가 쉬운 정보이다. (근데 그럼 없애면 되는 거 아닌가? 왜 계속 쓰고 있지?) 그래서 대책이 필요했고 그렇게 세션에 대한 개념이 나온 것이다.

 

• 세션ID와 세션?

 (세션이 먼저 나온 건지 세션ID가 먼저 나온 건지 모르겠지만 기술 편의상 세션ID부터 쓰겠다.)

   세션 ID 또한 서버가 사용자에게 "너, 자격 있어." 하고 붙여주는 코딱지이다. 헷갈릴 수 있으니 이제부터 세션ID는 코딱지 말고 껌에 비유하도록 하겠다. 서버는 고유한 껌 브랜드(?)를 제작하고 인증된 사용자에게 각기 다른 껌을 붙여준다. 여기서 코딱지와 다른 점은 서버도 그 껌을 가지고 있다는 것이다. 서버는 이제 사용자에게 붙인 껌을 목록화 해서 관리할 수 있다. 그 껌 목록이 바로 세션이다. (제대로 복습할 때 이 개념은 수정되었다.)

 

   물론 그것만으론 해커가 세션ID를 탈취할 가능성을 막아내지 못한다. 하지만 쟤가 걔가 맞는지 식별할 값을 서버가 가지고 있고, 관리할 수 있다는 것은 세션ID를 서버가 유지 혹은 소멸시킬 수 있게 되었다는 뜻이다. 

 

   예를 들어, 사이트를 이용할 때 그런 경험을 했던 적이 한 번쯤 있을 것이다. 로그인해서 이런 저런 서비스를 잘 이용하고 있었는데 세션이 만료되어 다시 로그인하라는 경고문을 보았던 적 말이다. 이게 바로 서버가 내가 가진 껌을 껌 목록에서 삭제했다는 뜻이 된다. 그럼 나는 당장 좀 귀찮을지언정 적어도 해커가 내 껌을 갖고 내 행세하는 시간을 단축시킬 수 있을 것이다. (그럼 다시 로그인을 요구하지 않는 사이트들은 뭘까? 보안을 등한시하나? 아니면 다른 더 좋은 방안이 있나? 세션ID를 세상에 딱 하나만 있을 수 있게 하나? JWT인가 그게 이럴 때 쓰는 건가?)

 

• 로그인 처리 방식

   앞서 말했듯이 해커가 쿠키 또는 세션 ID를 탈취하는 이유는 인증된 사용자인 척 사이트의 서비스를 이용할 수 있기 때문일 것이다. 이처럼 인증된 사용자마냥 서버의 자원을 착취할 수 있는 방법은 쿠키 또는 세션ID 탈취만 있는 것이 아니다. 로그인 자체를 우회하는 방법도 있다. 

 

   로그인을 우회하기 위해선 서버의 로그인 처리 방식을 이해해야 하는데 여기엔 여러가지 케이스가 존재한다. 그 중 이번 강의에서 언급된 방식은 4가지이다. 이렇게 로그인 케이스를 나눈 이유는 우회하는 방법이 모두 다르기 때문이다. 

 

   1) 식별과 인증을 따로 처리 

   2) 식별과 인증을 동시에 처리

   3) 식별과 인증을 따로 처리하고 인증 데이터를 해시화

   4) 식별과 인증을 동시에 처리하고 인증 데이터를 해시화 (인증데이터만 하는건지 확인할 필요가 있다.)

 

   여기서 식별이란 사용자를 DB에서 찾아내는 작업이고 이에 필요한 데이터는 로그인 시 입력한 ID값이다. 인증이란 식별로 찾아낸 DB의 사용자가 지금 로그인을 시도하는 사용자가 맞다고 확인하는 작업이며 이에 필요한 데이터는 로그인 시 입력한 비밀번호 값이다. 추가로 식별에 필요한 데이터(아이디)는 노출되어도 상관 없고 인증에 필요한 데이터(비밀번호)는 타인에게 노출되면 안된다. 식별은 단순히 찾아내는 것뿐이고 인증은 자격이나 권한을 부여하는데 직접적으로 연관이 있기 때문인 것 같다.

 

결론

 

   지금까지 기억에 남아 있는 강의 내용을 바탕으로 상호 연관성을 엮어 적어보았다. 쿠키, 세션ID, 세션은 사이트 이용 시 식별인증에 필요한 정보이고 로그인은 사이트 입장 시 식별인증에 필요한 정보이다. 두 가지 모두 사이트의 자원을 이용하기 위해서 필수적으로 서버에 확인 받아야 하는 정보이다.

   하지만 블랙해커는 정석적인 방식을 무시하고 사이트의 자원을 착취하고자 하기 때문에 식별 인증 과정을 우회하려 할 것이다. 잘~ 우회하기 위해 알아 봤을 개념이 바로 쿠키, 세션ID, 세션, 그리고 로그인 로직에 대한 지식이다. 따라서 모의해킹, 화이트 해커를 준비하는 입장에서 본격적으로 웹 해킹 기법을 배우기에 앞서 위 개념에 대해 충분히 이해하고 넘어가야 할 것이다. 

 

 

  +  우회에 대한 오타쿠적 망상 +

 

   로그인을 과연 어떻게 우회하게 될까? 뭔가 판타지 만화에서 보면 주인공 일행이 다른 나라나 마을로 몰래 들어 갈 때 경계쪽에서 경비병을 피하기 위해 별 걸 다 했던 장면이 생각난다. 여기에도 여러가지 케이스가 있다.

예를 들어,

 

㉮ 주인공의 도움을 받은 상인의 짐칸에 숨어 들어간다.

               => 이 경우 만화에서 무사히 통과한 걸 본 기억이 없음. 그래야 높으신 분이랑 마주칠 수 있음. 

㉯ 문제 없는 방문객인 척 태연하게 들어간다

               => 물론 하나도 태연하지 않고 걍 겁나 수상해보임. 모의해킹에 이 상황을 대입해보자면 어쩌면! 로그인할 때 서버가 잠깐 착각하게 만들 수도 있지 않을까 싶다.

㉰ 개구멍을 이용한다.

               => 이쪽이 뭔가 그럴듯 하다. 프로그램 상 생기게 되는 개구멍이 있지 않을 것 같다. 쿠키나 세션ID 탈취는 나라는 개체를 찾아낼 필요도 없게 하는 느낌인데 로그인 우회는 일단 "나"를 찾아 내는 걸 피해야할 것이고 내가 맞다고 "확인"하는 것도 피해야할 것이고.. 그러려면 일단 검문하는 줄에서 벗어나 들어갈 수 있는 통로를 찾아야 할 것이다. 근데 그래도 나한테 세션ID를 주나? 그건 스터디를 끝까지 하다보면 알게 될 것이다.

㉱ 걍 냅다 경비병 공격

                => 이 방법도 충분히 있을 법하다. 날 식별할 프로그램을 다운시켜버리는 것이다. 혹은 경비병 말고 방문객을 공격해서 가지고 있는 짐을 빼앗은 다음 지가 방문객인 척하는 방법도 있을 것 같다. 쿠키, 세션ID 탈취랑 뭔가 비슷해보이는데 느낌이 다르다. 더 ..악랄한 느낌!

㉲ 그 밖에 장벽 위로 날아서 도망가는 경우, 경비병에게 뇌물을 주고 지나가는 경우, 일행 중 겁나 유명한 애가 있어서 신원 증명할 필요가 없는 경우 등이 있다.

 

   이상 초심자의 망상이었다. 앞으로 더 자세히 배우며 내 망상 중 어떤 부분은 비슷하고 어떤 부분은 전혀 다른지 알 수 있을 것이다. 더 해상도 높은 망상을 위해 쿠키와 세션id의 구성이나 웹서버와 사용자가 이걸 사용하는 방법 등을 추가로 알고 가면 좋을 것 같다.

 

 

 

찾아볼 것 목록

 

1. 서버가 (자기가 준) 쿠키를 확인하는 방식. (코딱지의 DNA 혹은 위치 어쩌구)

        => 내 컴퓨터는 저 서버에 내가 요청하는 걸 어떻게 알고 해당 쿠키를 넣어 요청을 보내는가가 더 정확할 듯.

        => 요청할 사이트의 도메인과 일치하는 값을 가진 쿠키만 사용. 도메인에 따라 다른 위치에 저장.

        => 아무튼 포인트는 쿠키에 저장된 도메인과 파일경로.

2. 쿠키가 보안에 위험하다면 왜 없애지 않는가, 없앨 수 없다면 왜 없앨 수 없는가

        => 편하고 쓰던 거고 단순하고 호환 잘됨. 보안적으로 도움이 되는 여러 속성들도 계속 발전 중.

3. 세션 만료, 로그인 어게인을 요청하지 않는 사이트들의 운영 방식(보안X? 1인 1세션ID? JWT? 다른거?)

        => JWT 혹은 지속 쿠키 방식 사용

4. 해시화를 인증 데이터(비번)에만 하는 건지, 아니면 아이디에도 하는지

        => 특별한 경우 제외하고 인증 데이터에만 적용

5. 무엇이 쿠키와 세션ID를 확인하는지

        => 서버가 확인. 그리고 php 등으로 걔네 처리. 요청은 변해도 이름, 값은 변하지 않을 것 같음. 

 

+

쿠키를 코딱지, 세션id를 껌에다 비유한 것은 딱 맞는 비유는 아닌 것 같다.

왜냐면 이 둘은 아주 별개가 아니라 세션id를 쿠키에 포함시켜 보내 어느정도 연관이 있기 때문이다.

하지만 꽤 즐거운 비유였다고 생각한다.

 

 

 

 

 

※  여기부터 찐 복습

 

≫ 로그인 과정과 처리 방식

≫ 쿠키

≫ 세션과 세션ID

 

 

 

≫ 로그인 과정과 처리 방식

• 로그인: 야가 갸인지 확인하는 과정                                                                                                                                           
• 로그인에 필요한 요소

1. 식별 데이터

2. 인증 데이터

 

◈ 식별

"야,야, 얘 여깄다!"

   > 수많은 데이터 중 특정 데이터를 후레시로 비추는 작업

   > 식별 데이터로 사용자가 DB에 있는지 검색.

   > 단순히 나를 구별하기 위한 데이터이므로 타인에게 노출되어도 ... 됨. 막 아이고 큰일났다 이런 건 아님.

   > 다른 데이터와 구별하기 위한 기준이 되어야 하기 때문에 중복되면 안됨. (unique)

   > 아이디

 

             

◈ 인증

"봐봐, 얘 걔 맞다니까!"

   > 본인이 맞는지 확인하는 작업

   > 인증 데이터를 비교하여 지금 로그인 시도하는 사용자가 DB에 있는 사용자가 맞음을 확인

   > 타인에게 노출되면 안됨. 서버가 야가 갸가 맞음을 인정하는데 사용해서  ..라고 추측 중.

   > 비밀번호

   > 뭔가 회원가입할 때 비밀번호 확인란도 사용할 비번을 제대로 알고 쓰는 게 맞는지 확인하는 느낌. 

      그게 맞다면 목적은 아마.. 잊어버리지 말라고..?

      잊어버리면 안되는 이유는 인증데이터가 노출될 가능성을 줄이기 위해서일까. 근데 otp는 권장하지 않나?

 

 

어라..?

실습 과제를 잘못한 것 같다.

 

나는 네가지 케이스 모두 셀렉트로 입력된 아이디와 같은 행을 추출해서

아이디, 비번을 한 if문에, 혹은 if문 안의 if문에 비교해보는 방식으로 처리했다.

 

근데 이거 아닌 것 같다!! 이건... 이건 아이디로 식별하고 아이디, 비번으로 인증하는 방식이지 않나?!?!

 

나도 모르게 아이디가 식별데이터, 비번이 인증데이터라고 퉁치고 있었던 것 같다.

근데 이건 선후 관계가 잘못되었다.

식별 과정에 사용되는 데이터를 아이디라고 부르고, 인증 과정에 사용되는 데이터를 비밀번호라고 부르는 것이다.

 

서버는 아이디와 비밀번호라는 걸 모른다. 그건 인간이 보고 구별하기 위해 붙인 이름일 뿐이다.

그니까 서버는 "이건 아이디, 저건 비번" 이렇게 구분하는 게 아니라

식별하는 과정에 사용되는 데이터를 알고 인증하는 과정에서 사용되는 데이터를 알뿐이다. 

 

그럼 식별,인증을 동시에 하는 것은 무엇이고 따로하는 것은 무엇인가.

 

식별은 나를 찾는 것이고 인증은 나를 확인하는 것이다.

식별은 내가 있는 데이터를 찾아 뽑아내는 것이고 인증은 그래서 그 데이터가 정말 나의 정보인지 확인하는 것이다.

 

식별, 인증 동시라는 것은 데이터를 찾아서 뽑으면서 확인도 하는 것이고 

식별, 인증 따로라는 것은 내 데이터 찾는 것 따로, 확인하는 것 따로라는 뜻이다.

 

나를 찾는 것은 입력된 아이디를 select문으로 받으며 이루어진다.

나를 확인하는 것은 select된 행의 인증 데이터와 입력받은 인증 데이터를 비교하며 이루어진다.

 

 

아 완전 한참 잘못 이해했네!!! 이래서 복습 정리도 실습 과제도 일단 하고 봐야하는 것 같다 아오!!!

 

               => 과제 수정함.

 

 

• 로그인 케이스 별 로직

케이스 별로 우회 방법이 다르다.

 

1. 식별, 인증 동시에 처리

2. 식별, 인증 분리해서 처리

3. 식별, 인증 동시에 처리 (인데 인증데이터가 해시처리됨)

4. 식별, 인증 분리해서 처리 (인데 인증데이터가 해시처리됨)

 

1) 식별, 인증 동시

DB 질의에서 식별 데이터와 인증 데이터를 동시에 비교하고 해당하는 데이터 뽑아옴.   

     => select문에서 id, 비번 값 비교하고 해당하는 데이터 행 뽑아와서 있으면 로그인 성공 처리, 없으면 실패 처리

 

2) 식별, 인증 분리

DB 질의에서 해당하는 id에 맞는 데이터 행을 먼저 추출 -> 식별

추출된 데이터 행에서 비밀번호 뽑아서 입력받은 비밀번호와 비교 -> 인증

 

3) 식별, 인증 동시 + 해싱

데이터 동시에 비교하고 뽑아오되 인증 데이터인 비밀번호 값이 해시함수에 의해 암호화됨.

입력 받은 인증 데이터를 해시화하여 DB에 있는 이미 해시화된 인증 데이터 값과 비교.

 

4) 식별, 인증 동시 + 해싱

입력된 식별 데이터에 해당하는 데이터 행을 추출한 후 해당 행의 인증 데이터와 입력받은 인증 데이터를 비교.

이때 입력받은 인증 데이터를 해시화하여 이미 DB에 저장된 해시화된 인증 데이터와 비교.

 

 

HASH에 대한 아주 짧은 정리

암호화 알고리즘은 크게 일방향 암호화 알고리즘과 양방향 암호화 알고리즘으로 나뉨.

일방향 -> 암호화, 복호화 중 복호화는 못 함. 평문 데이터를 암호화할 수는 있지만 암호화된 데이터를 평문으로 바꿀 수 없음.

양방향 -> 암호화, 복호화 둘 다 가능. 평문 데이터를 암호화할 수 있고 키가 있으면 다시 평문으로 바꿀 수 있음.

 

HASH는 일방향 암호화 알고리즘으로 데이터를 해시 함수에 넣어 암호화된 데이터로 바꿈.

일방향 함수를 사용하기 때문에 복호화가 불가하다. 따라서 DB 털려도 *Credential Stuffing과 같은 공격엔 비교적 안전한 편.

해시화된 입력값과 해시화된 DB 데이터를 가지고 같은지 다른지 비교.

   *Credential Stuffing: 어디서 수집한 로그인 데이터들을 마구잡이로 입력해서 때려맞추는 공격 

 

추가로 "인코딩"이라는 것이 있는데 이건 효율적으로 데이터를 보내기 위해 데이터를 부호화, 기호화하는 작업을 말한다. 암호화랑 엄연히 다른 목적을 가지고 있으며 디코딩할 때 키가 필요하지 않다고 한다.

 

 

• 로그인 유지

웹 서버는 "Stateless"하고 "connectionless"한 특성을 가지고 있다고 한다.

 

번역하자면 "무상태성"에 "비연결성"인데 이는 사용자의 각 요청을 독립적으로 취급하는 특성으로, 다시 말해 원래는 로그인을 했다고 해도 다른 파일을 요청하면 서버는 내가 이전에 로그인을 한 상황인지 아닌지 모른다는 뜻이다.

 

하지만 우리는 로그인 한 번이면 마이페이지에도 들어갈 수 있고 내 블로그도 갈 수 있고 글쓰기도 할 수 있고 글을 업로드할 수도 있다.

내가 로그인한 사용자라는 것을 서버는 알고 있다. (-> stateful)

 

원래라면 할 수 없는 이것을 가능하도록 만든 것이 "쿠키"와 "세션", 그리고 "세션ID"이다.

 

 

 

≫ 쿠키

• 쿠키 사용 흐름

㉮  사용자가 브라우저에서 url로 서버에 파일 요청 (사이트 접속) -> 로그인

 

㉯  서버에서 내가 보낸 로그인 정보 확인 -> 맞으면 브라우저로 인증 쿠키 보냄

 

㉰  웹 브라우저가 쿠키를 내부 저장소에 암호화하여 저장 (브라우저에게 할당된 내 PC 내부의 파일 시스템 등)

 

㉱  사용자가 사이트에 또다른 요청을 보냄

 

㉲  브라우저가 내부 저장소에서 해당 사이트의 도메인과 경로에 맞는 쿠키를 찾아 http 요청 헤더에 담아 서버에 보냄

 

㉳  서버는 쿠키를 확인하고 요청에 맞는 파일(페이지)을 브라우저에 보냄

 

㉴  쿠키의 종류에 따라 쿠키 수명이 결정 (사이트를 나가면 종료되는 세션 쿠키/ 특정 시간동안 지속되는 지속 쿠키)

 

• 구조

1. 이름

2. 값

3. 도메인

4. 파일 경로

5. 쿠키 만료시간

6. flag 등의 부가 속성

                (flag의 예시: Secure, HttpOnly 등)

 

=> 이름/값 쌍이 기본인 듯하다.

예시:         Cookie: loginUser=normaltic 

 

 

• 쿠키 저장 방식

브라우저는 서버에게 쿠키를 받아서 사용자 PC 내부에 브라우저마다 할당된 특정 파일에 쿠키를 저장함.

쿠키에 저장된 도메인과 경로에 따라 구조화하여 쿠키를 관리.

브라우저는 권한을 가진 파일에만 제한적으로 접근, 사용할 수 있음.

다른 애플리케이션은 해당 파일에 접근하지 못함.

 

 

 

 

크롬 개발자 도구에서 쿠키보는 법. 들어간 사이트에서 쓴 쿠키가 목록으로 나온다. f12 -> 애플리케이션 탭에서 볼 수 있음

https://developer.chrome.com/docs/devtools/application/cookies?utm_source=devtools&hl=ko

쿠키 보기, 추가, 수정 및 삭제  |  Chrome DevTools  |  Chrome for Developers

 

내가 만든 사이트에서 실행해본 모습. 해시화한 인증 데이터가 키 값인 상태인 겨?!

 

 

쿠키에 대해 더 찾아본 거 (위키피디아)

• Authentication Cookies 인증 쿠키

 

로그인 상태나 로그인 한 계정 등에 대한 정보를 담은 쿠키.

따라서 보안을 각별히 신경써야 하는데 이에 대한 보안은 해당 웹사이트나 웹 브라우저가 채택한 보안 방식에 달려있다.

      -> XSS, CSRF 공격 등과 연관됨

 

• Tracking Cookies 추적 쿠키 (?)

사용자가 웹사이트에서 일정 기간동안 활동한 기록을 컴파일한 쿠키.

사이트 사용할 때 그 "쿠키 사용에 동의하십니까" 메세지는 Tracking Cookie에서 유래될 수 있는 프라이버시 침해를 의식한 거라고 보임. 이거 동의 안하면 불필요한 쿠키가 내 장치에 저장되는 것을 막을 수 있고, 그렇다면 내 이전 활동을 어느정도 덜 기록할 수 있을 듯. 

 

 

한번 보고 넘어가자는 의미에서 최대한 정리해본 쿠키 종류

 

• Session Cookie

세션이 만료되면 사라지는 쿠키.

웹브라우저를 닫을 때 세션 쿠키가 만료되거나 삭제되고

브라우저는 이 세션 쿠키를 만료 기한의 존재 유무를 통해 식별하는 듯 하다. (세션ID랑 다른 거)

 

• Persistent Cookie

해당 쿠키 제작자에 의해 설정된 특정 기간동안 유지되는 쿠키.

expires 또는 max-age 등을 통해 설정.

이 기간동안 웹사이트의 페이지들을 방문할 때마다 수명에 대한 정보가 서버에 전달된다.

 

• Secure Cookie

암호화된 연결(HTTPS 등)을 통해서만 보낼 수 있는 쿠키.

스니핑 등 네트워크 도청에 의해 뺏길 위험이 적음. 쿠키의 flag 부분에 Secure 속성 추가

 

• Http-Only Cookie

자바스크립트 같은 클라이언트 사이드 언어(본문: Client side APIs)에 의해서는 접근이 불가한 쿠키.

크로스 사이트 스크립트를 예방. 근데 Cross-site Tracing(XST)과 CSRF(사이트 간 요청 위조)는 예방 모대.

쿠키의 flag 부분에 HttpOnly 속성 추가

 

• Same-site Cookie

크롬 51버전에서 출시한 것으로, 내가 있는 원래 도메인(?)에만 요청을 보내도록 해서 CSRF를 예방할 수도 있고

내가 있는 원래 도메인과 다른 도메인에도 요청을 보낼 수 있지만 안전한 방식으로 요청을 보내게 할 수 있음. 

(이땐 GET 방식이 POST 방식보다 안전한가 보다.)

Third-party Cookie를 허용하는 방식도 있음. Third-party Cookie는 현재 사용 중인 사이트에서 어떤 광고가 나오고 있다면 그 광고를 보내는 서버에서도 내 활동 기록이 담긴 쿠키를 추적할 수 있는 특성을 가진 쿠키인 듯하다. 근데 대부분의 웹 브라우저가 이거 말고 더 안전한 거 쓰라고 하는 듯.

 

• Super Cookie

flag 영역에 특정 도메인 이름이 아니라 .com이나 .co.kr 등이 붙은 쿠키.

super cookie를 가진 사용자가 .com이나 .co.kr로 끝나는 사이트에 접속해서 여기서 보낸 쿠키를 가짐.

-> 이 사이트를 운영하는 공격자가 이 쿠키를 이용해서 도메인이 .com이나 .co.kr로 끝나는 다른 사이트에 사용자의 요청을 보내 방해하거나 사용자인 척 할 수 있음.

Public Suffix List라는 것이 있다. 예시의 .co.kr도 여기에 포함됨. 

 

• Zombie Cookie

브라우저가 할당한 쿠키 저장소의 바깥에 만들어진 데이터나 코드.

그리고 이미 있던 오리지널 쿠키를 지우고 자동으로 새로운 HTTP 쿠키를 생성함. 박힌 돌 빼고 지 돌 굴려서 넣음.

여러 위치에 저장될 수 있는데 어디서 하나 지워지면 다른 곳에 있는 좀비 쿠키가 또 껴넣는 듯. 

뭔가 쓰고보니 무서운데 분석 업체에서 사용자들이 쿠키를 지우는 걸 방지하기 위해 사용하기도 하는가 보다.

 

 

위키피디아 쿠키 페이지에서 찾은 정보이고, 추가로 Cookie Wall이란 것도 있었다.

Cookie Wall이란 웹사이트에 뜨는 쿠키 사용에 대한 안내 팝업인데 Tracking Cookie로만 접근할 수 있는 웹사이트를 사용할 때 뜬다고 한다. 거부 선택지는 없다고 한다.

 

 

쿠키는 나도 접근할 수 있을만큼 닫힌 정보가 아니고

사용자에게 저장된 쿠키 정보를 서버가 보고 그렇구나~ 드루와~ 이거 써~ 해주는 거라

공격자가 사용자의 쿠키를 탈취해  인증된 사용자만 접근할 수 있는 데이터에 접근해서 수정까지 할 수 있다.

뿐만 아니라 HTTP 요청서의 쿠키 값을 바꿔서 사용자의 요청을 변조할 수도 있다.

 

이러한 부분을 어느정도 보완할 수 있는 것이 "세션"과 "세션ID"이다.

 

 

 

≫ 세션과 세션ID

• 사용 흐름

㉮  사용자가 url로 서버에 파일 요청 (사이트 접속) -> 로그인

 

㉯  서버에서 내가 보낸 로그인 정보 확인 -> 맞으면 랜덤 문자열로 세션 ID 생성.

                                                                           -> 서버의 파일 시스템 내부의 세션에 세션ID와 사용자 정보 저장.

                                                                                            (혹은 메모리, 데이터베이스에 저장)

                                                                           -> 이때는 저장된 세션ID가 *키가 된다고 함.

*키 값(key): 찾을 때 기준이 되는 값으로 이해함.

 

㉰  생성한 세션 ID를 응답 헤더의 쿠키에 넣어 브라우저에 보냄

 

㉱  브라우저는 이 세션ID를 사용자 PC 내부에 있는 해당 도메인 용 쿠키 저장소에 저장

                                                                                  (브라우저에게 사용 권한이 있는 파일 시스템)

 

㉲  사용자가 사이트에 또다른 요청을 보냄

 

㉳  사용자 브라우저가 해당 사이트의 도메인과 경로에 맞는 쿠키를 HTTP 요청 헤더에 보냄.

                                               -> 이때 요청 헤더의 쿠키에 세션 ID가 포함되고 서버에 저장할 때와 달리 세션ID는 키가 아니라 value가 됨.

 

㉴  서버는 요청 헤더에 담긴 세션 ID를 추출하여 서버 저장소의 전체 세션 중 해당 세션 ID가 있는지 조회하고 맞는지 비교. 

 

㉵  맞으면 해당 세션ID 정보를 응답 헤더의 쿠키에 포함하여 요청에 대한 적절한 응답을 사용자 브라우저로 보냄.

 

㉶  기본적으로 브라우저가 닫히면 서버의 세션에서 해당 세션id 삭제. 

      서버에서 세션 지속 시간 설정 가능.

 

 

• 세션

세션ID를 포함하여 이를 키값으로 연결된 사용자의 데이터 묶음을 말할 때도 있고 (엄밀한 의미)

서버에 저장된 세션 파일 자체를 얘기할 때도 있는 듯하다. 

 

편의상 전자는 개별 세션이라고 하고 후자는 전체 세션이라고 하겠다.

 

(위키피디아에선 세션은 뭔가 컴퓨터로 통신하는 특성 기간을 말하는 것 같았고 위의 의미는 HTTP session token이라는 단어로 표현하고 있는 것 같았음.)

 

구조  

 

1) 서버에서: 이름(세션ID) 값 쌍(+사용자 정보, 인증 상태 등등)

2) 브라우저에서: 이름 값(세션ID) 값 쌍(+사용자 정보, 인증 상태, 사용 flag 등)

 

사실 세션을 후자의 의미로 받아들였었는데 챗지피티와 질의하다보니 세션과 세션id라는 단어를 사용하는 상황이 내가 저 단어들을 사용하는 상황이랑 다르다는 느낌을 받았고 이에 대해 물어보니까 전자의 의미를 알려줌.

 

현재 크롬 개발자 도구에서 티스토리 사이트에 사용된 쿠키의 세션을 검색한 결과. TSSESSION이라는 이름이 키 값으로 있고 내 세션ID가 value로 저장되어 있다. 서버의 세션을 볼 수 없어서 정확히는 말할 수 없지만 대략 이 데이터 행 자체가 세션이라고 할 수 있지 않을까 싶음. 근데 서버의 세션에선 세션ID 값 자체가 키로 저장된다고 한다.

 

 

 

• 세션 ID

위 사진의 val...에 있는 값, 세션의 키 값과 쿠키의 value로 사용되는 값 자체를 의미하기도 하고 (엄밀한 의미)

경우에 따라 특정 세션ID에 연결된 사용자 데이터 묶음을 의미할 때도 있는 듯 하다. 문맥을 파악해야 할 듯.

 

랜덤 문자열로 생성하기 때문에 중복되지 않음.

랜덤 문자열 생성 알고리즘이나 UUID라는 거 사용.

 

공격자는 다른 사용자의 세션ID를 탈취해 자기가 로그인한 사용자인 양 이용한다고 하니

로그인 됐다는 증거가 세션ID에 있는 듯 하다.

 

 

• 세션의 수명

 

기본적으로 브라우저를 닫으면서 개별 세션의 데이터는 삭제되지만

서버에서 이것을 언제 삭제할지 설정할 수 있음.

 

이를테면 지속 시간을 설정해서 해당 세션ID와 연결된 사용자가 특정 시간동안 활동이 없으면 삭제하도록 설정할 수도 있음.

그럼 사용자는 다시 로그인해야 함.   => 세션 타임아웃

 

쿠키와 달리 서버가 세션ID(와 사용자 정보)를 브라우저에 보낼 뿐 아니라 서버 내부에도 저장하기 때문에 지속 시간 등을 사용자가 임의로 설정하지 못함.

 

전체 세션을 삭제하는 일도 있는데 서버를 재시작할 때, 서버 유지보수를 위해, 보안 이슈가 발생할 때 등에 전체 세션을 삭제한다고 한다. 그러면 모든 세션이 초기화된다.

 

 

• 쿠키와 가장 다른 점

쿠키는 사용자에게 저장되어 사용자가 수정할 수 있지만 세션 및 세션 ID는 사용자에게 발급한 값을 서버에도 저장함.

세션 데이터를 서버에서 관리함.

서버에서 세션 데이터를 삭제하고 연결된 사용자에게 새로 로그인할 것을 요구할 수 있음.

 

 

 

BUT !!!!

같은 네트워크 환경에 있을 때 세션ID도 쿠키처럼 탈취가 가능함. (웹쉘, XSS, MITM(중간자 공격) 등을 이용)

대신 서버에서 관리하는 데이터이기 때문에 지속 시간 등을 설정하므로써 공격자가 인증된 사용자인 척 하는 시간을 줄일 수는 있음.

 

 

그래서!!!!

모의해킹을 공부하는 입장에서 어떻게 사용자의 세션ID를 탈취할 수 있을지

세션ID 탈취 공격을 막기 위한 방법은 무엇이 있을지 고민하고 공부해야 한다!

 

 

 

 

 

 

*쿠키, 세션, 세션ID 부분은 구글링, 위키피디아 및 생성형 AI 등을 참고함.