[SK쉴더스 Rookies 19기] 클라우드 기반 스마트 융합보안 과정
01. Cookie
: Stateless한 HTTP 프로토콜에서 요청과 요청 간의 관계를 유지하기 위해서 도입된 개념
어플리케이션이 복잡해지면서 인증과 인가가 적용되기 시작
→ 요청할 때마다 인증을 받아야하는 번거로움 발생
→ 상태를 유지시키기 위해 '쿠키' 등장
ex.
로그인 후 서버가
set cookie로 보내주면
Set-Cookie: username=hong; role=user
다음 요청 시에
브라우저가 같이 전달
GET /data
Cookie: username=hong; role=user
전달 받은 쿠키를 이용해서 서비스를 제공
요청 헤더와 응답 헤더를 통해서 값을 주고 받음
→ 전달 과정에서 쉽게 노출, 유출되며 탈취나 변조가 가능함
안전하게 사용하려면?
서버에서 해야하는 것들..
- 중요 정보가 쿠키에 포함되지 않게 설정
포함되어야 한다면, 암호화(안전한 알고리즘 + 키 길이) / HTTPS(보안 채널)을 통해서 전달 - secure 속성 활성화
- 하드디스크에 지속적으로 남아있지 않게 지속 시간, 유효 기간을 최소로 설정
- 쿠키에 임의로 접근, 조작하지 못하게 HttpOnly 속성을 활성화
02. Session
서버에 의해서 보호됨
ex.
로그인 후 서버는
사용자 정보 대신 이를 식별할 수 있는 키를 발급, 전달
sid: 1234
다음 요청 시에
브라우저가 같이 전달
GET /data
Cookie = sid: 1234
전달된 키로 사용자 정보에 접근해서 서비스 제공
요청/응답 과정에서 정보 유출이 발생하지 않음
→ but.. 키가 유출 되는 경우에는 서버를 속여 정보에 접근이 가능해짐
→ 키 설정과 관리가 중요
세션 id를 잘못 사용하는 경우..
- 인증 전과 인증 후 동일한 세션 ID를 유지하는 경우 → 세션 ID 고정
공격자가 1234 라는 세션 id를 받으면, 1234를 세션 id로 고정시키는 스크립트를 활용해서 사용자가 1234라는 세션 id를 갖게 함
사용자가 로그인하면 1234라는 세션 id가 로그인 된 권한을 가지고, 이는 공격자도 갖게 되는 것..
- 세션 ID 생성 규칙을 유추할 수 있는 경우 → 세션 ID 추측
1234 /1235 /1236 ⋯ 이면 공격자가 언젠가 1240이 되겠다 추측하고
1240으로 설정하고 기다리다 세션 id가 발급되는 순간 사용자와 공격자가 같게 인식됨
- 스크립트 코드를 이용해서 브라우저에 저장된 세션 ID를 탈취할 수 있는 경우 → 세션 ID 훔치기 → XSS 공격
728x90