2.1 쿠키에 직접 사용자 정보를 넣으면 안 되는 이유#

초보 개발자는 다음과 같이 쿠키에 사용자 정보를 직접 넣는 실수를 할 수 있다.

1
Set-Cookie: user_id=admin

이 방식은 매우 위험하다. 쿠키는 클라이언트 측에 저장되므로 사용자가 직접 수정할 수 있기 때문이다. 만약 서버가 이 값을 그대로 신뢰한다면, 공격자는 쿠키 값을 바꿔 인증을 우회할 수 있다.

1
Cookie: user_id=admin

따라서 쿠키에는 사용자의 권한이나 중요한 정보를 그대로 넣는 것이 아니라, 서버에서 관리하는 세션을 찾기 위한 식별자만 저장하는 것이 일반적이다.

4.1 HttpOnly#

HttpOnly는 JavaScript에서 쿠키에 접근하지 못하게 하는 속성이다.

1
Set-Cookie: session_id=abc123; HttpOnly

만약 HttpOnly가 없다면 JavaScript에서 다음과 같이 쿠키를 읽을 수 있다.

1
console.log(document.cookie);

이 상태에서 XSS 취약점이 발생하면 공격자가 사용자의 쿠키를 탈취할 수 있다. 반대로 HttpOnly가 설정되어 있으면 JavaScript로 쿠키를 직접 읽을 수 없기 때문에 세션 탈취 위험을 줄일 수 있다.

단, HttpOnly가 XSS 자체를 막아주는 것은 아니다. XSS가 발생하면 공격자는 사용자의 브라우저에서 요청을 보내는 등의 다른 악성 동작을 시도할 수 있다. 따라서 HttpOnly는 XSS 방어의 일부이지 완전한 해결책은 아니다.

4.2 Secure#

Secure 속성은 HTTPS 연결에서만 쿠키가 전송되도록 한다.

1
Set-Cookie: session_id=abc123; Secure

만약 HTTPS가 아닌 HTTP 환경에서 세션 쿠키가 전송된다면 네트워크 중간에서 쿠키가 노출될 위험이 있다. 따라서 실제 서비스에서는 로그인 세션 쿠키에 반드시 Secure 속성을 설정하는 것이 좋다.

4.3 SameSite#

SameSite는 다른 사이트에서 발생한 요청에 쿠키를 포함할지 결정하는 속성이다. 주로 CSRF 공격을 완화하기 위해 사용된다.

1
Set-Cookie: session_id=abc123; SameSite=Lax

대표적인 값은 다음과 같다.

일반적인 웹 서비스에서는 SameSite=Lax가 많이 사용된다. 외부 링크를 통한 일반적인 이동은 허용하면서도, 위험한 크로스 사이트 요청은 어느 정도 막을 수 있기 때문이다.

5.1 세션 탈취#

세션 탈취는 공격자가 사용자의 세션 ID를 얻어 해당 사용자처럼 행동하는 공격이다. 세션 ID는 로그인 상태를 증명하는 중요한 값이기 때문에 탈취되면 계정 접근으로 이어질 수 있다.

세션 탈취가 발생할 수 있는 원인은 다음과 같다.

• XSS로 인한 쿠키 노출
• HTTPS 미사용으로 인한 네트워크 감청
• 너무 예측 가능한 세션 ID
• 세션 만료 시간 미설정
• 로그아웃 이후 세션 무효화 누락

특히 세션 ID는 절대 예측 가능하면 안 된다. 다음과 같은 방식은 위험하다.

1
session_id = user_id + current_time

공격자가 규칙을 추측할 수 있기 때문이다. 세션 ID는 충분히 긴 랜덤 값으로 생성해야 하며, 서버 측에서 안전하게 관리해야 한다.

5.2 세션 고정 공격#

세션 고정 공격은 공격자가 미리 정한 세션 ID를 피해자에게 사용하게 만든 뒤, 피해자가 로그인하면 공격자가 같은 세션 ID로 접근하는 방식이다.

예를 들어 다음과 같은 흐름이다.

1. 공격자가 특정 세션 ID를 생성하거나 획득한다.
2. 피해자에게 해당 세션 ID를 사용하게 만든다.
3. 피해자가 로그인한다.
4. 서버가 기존 세션 ID를 그대로 로그인 상태로 변경한다.
5. 공격자가 같은 세션 ID로 피해자 계정에 접근한다.

이를 막기 위해서는 로그인 성공 시 기존 세션 ID를 재사용하지 않고 새로운 세션 ID를 발급해야 한다.

1
로그인 전 세션 ID: old_session
2
로그인 후 세션 ID: new_session

즉, 인증 상태가 바뀌는 중요한 시점에는 세션을 재발급해야 한다.

5.3 CSRF#

CSRF는 사용자가 로그인된 상태라는 점을 악용해, 공격자가 의도한 요청을 사용자의 브라우저에서 보내게 만드는 공격이다.

예를 들어 사용자가 특정 사이트에 로그인한 상태에서 공격자의 페이지에 접속했다고 가정해보자. 공격자 페이지가 다음과 같은 요청을 자동으로 보낼 수 있다.

1
<form action="https://example.com/change-email" method="POST">
2
  <input type="hidden" name="email" value="attacker@example.com">
3
</form>

브라우저는 해당 사이트의 쿠키를 자동으로 포함할 수 있기 때문에, 서버가 별도의 검증을 하지 않으면 사용자가 직접 요청한 것처럼 처리될 수 있다.

CSRF를 막기 위해서는 다음과 같은 방어가 필요하다.

• CSRF Token 사용
• SameSite 쿠키 설정
• 중요한 요청에서 Origin 또는 Referer 검증
• GET 요청으로 상태 변경 금지

특히 게시글 삭제, 비밀번호 변경, 이메일 변경 같은 상태 변경 요청은 반드시 POST, PATCH, DELETE 등의 메서드를 사용하고 추가 검증을 해야 한다.

6.1 세션 쿠키 설정#

세션 쿠키는 다음과 같이 설정하는 것이 좋다.

1
Set-Cookie: session_id=random_value; HttpOnly; Secure; SameSite=Lax; Path=/

각 속성의 의미는 다음과 같다.

실제 서비스에서는 도메인 구조에 따라 Domain 설정도 신중하게 해야 한다. 너무 넓은 도메인에 쿠키를 설정하면 하위 도메인 취약점이 전체 서비스 인증에 영향을 줄 수 있다.

6.2 로그인 성공 시 세션 재발급#

로그인 전과 로그인 후의 세션 ID는 달라야 한다. 이를 통해 세션 고정 공격을 방어할 수 있다.

1
before login: anonymous session
2
after login: authenticated session

즉, 사용자가 로그인에 성공하는 순간 서버는 기존 세션을 폐기하고 새로운 세션을 발급해야 한다.

6.3 로그아웃 시 세션 무효화#

로그아웃은 단순히 브라우저의 쿠키를 삭제하는 것으로 끝나면 안 된다. 서버 측 세션 저장소에서도 해당 세션을 제거해야 한다.

1
1. 클라이언트 쿠키 삭제
2
2. 서버 세션 저장소에서 session_id 제거

서버 세션이 남아 있다면 쿠키 값이 다시 사용될 가능성이 있다. 따라서 로그아웃 시에는 클라이언트와 서버 양쪽에서 모두 세션을 정리해야 한다.

6.4 권한 검증은 서버에서 수행#

프론트엔드에서 버튼을 숨기는 것은 보안이 아니다. 예를 들어 일반 사용자에게 관리자 버튼을 보이지 않게 한다고 해서 관리자 기능이 보호되는 것은 아니다.

1
if (user.role === "admin") {
2
  showAdminButton();
3
}

이 코드는 UI 제어일 뿐이다. 실제 요청이 들어왔을 때 서버에서 다시 권한을 확인해야 한다.

1
사용자 요청 → 서버에서 세션 확인 → 사용자 권한 확인 → 기능 실행 여부 결정

권한 검증은 반드시 서버에서 수행되어야 한다.