[Spring Security] 웹 보안 공격 #2 세션 고정 공격, JWT 토큰 탈취 + 대응 전략

1편: https://syleeblog.tistory.com/51

[Spring Security] 웹 보안 공격 #1: CSRF공격과 XSS 공격 + 대응 전략

 

 

 📌세션 고정 공격

세션 고정 공격은 공격자가 세선 ID를 미리 정해놓고, 피해자가 그 세션을 사용하게 만든 뒤,

피해자가 같은 세션으로 로그인했을 때 피해자의 권한을 탈취하는 공격입니다.

 

즉, 세션 ID를 먼저 만든 사람이 로그인 후에도 계속 그 세션을 사용할 수 있다면,
공격자는 피해자의 로그인 세션을 그대로 탈취할 수 있어요.

 

---

• 공격자가 웹 서버에 접속하여 세션ID(ABC123)를 부여받습니다.
  • 웹 서버는 로그인 여부와 관계 없이 브라우저를 구분하기 위해 세션ID를 부여합니다.
• 이 세션 ID가 있는 로그인 링크를 피싱 이메일 등을 통해 사용자에게 보내고,
  • 피해자에게 http://example.com/login;jsessionid='ABC123' 링크를 보내고, 피해자가 모르고 이 링크를 클릭하여 로그인합니다.
  • 이 경우는 쿠키 기반이 아니라 URL에 세션 ID를 붙이는 방식입니다.
• 사용자가 이 링크로 로그인을 하게 되면, 이 세션ID(ABC123는 로그인된(인증된) 상태가 됩니다.
• 공격자는 같은 세션 ID를 가지고 있으므로 피해자의 계정으로 로그인된 상태로 웹사이트를 이용할 수 있습니다.

 

💉 대응 전략

공격자가 가지고 있던 세션 ID가 로그인 이후에도 그대로 유지될 때,

즉 세션이 고정될 때 이 공격이 유효합니다.

 

따라서 로그인 때마다 세션을 바꾸는 식으로 방어할 수 있습니다.

Spring Security의 SecurityFilterChain에서 sessionManager에 세션 고정 공격 방어 설정을 추가할 수 있습니다.

http.sessionManagement(s -> s
     .sessionFixation(sf -> sf.changeSessionId()));  // 세션 ID만 변경하는 모드 선택

 

다음과 같은 옵션이 가능합니다.

• none: 아무것도 하지 않고, 세션 ID를 유지합니다. 세션이 보호되지 않습니다.
• newSession: 로그인 시 새로운 세션을 생성하여 사용합니다.
• migrateSession: 로그인 시 새로운 세션을 생성하고, 세션 ID를 제외하고 이전 세션의 속성들(로그인한 사용자의 이름 등)을 새로운 세션으로 복사합니다.
  • 현재 기본값
• changeSession: 세션 자체는 유지하고 세션 ID만 변경됩니다.

---

📌JWT 토큰 탈취

JWT 토큰을 이용한 인증 방식을 쓰는 사이트가 있습니다.

이 사이트에 사용자가 정상적으로 로그인하면 유효한 JWT 토큰을 발급 받습니다.

 

이때 공격자가 XSS 공격 등 어떤 방벙으로 JWT 토큰값을 알아내고

공격자가 이 토큰을 자신이 보내는 요청의 Authorization 헤더에 넣어서 서버에 보내면

서버에서는 유효한 토큰이므로 요청을 수행합니다.

💉 대응 전략

토큰 자체를 탈취를 막기 위해서 HTTPS 사용, XSS 공격 방어 등을 할 수 있습니다.

아니면 JWT 토큰을 쿠키에 저장하고, CSRF 공격을 막도록 신경쓸 수 있습니다.

 

그러나 탈취를 완전히 막기 어려우므로, 탈취된 토큰이 오래 사용되지 않도록 설계해야 합니다.

유효한 토큰이 탈취된 동안에는 공격자의 행동을 막기 어렵습니다. 그러나 공격자가 탈취한 토큰이 금방 쓸모 없어지도록은 할 수 있습니다.

 

Access Token과 Refresh Token을 같이 쓰는 2단 구조는

• Access Token의 수명은 짧게 설정하고(ex 5-30분)
• Refresh Token의 수명을 길게 설정하여(ex 1-30일)

Access Token이 금방 만료되어도 Refresh Token을 이용해 새로운 AccessToken을 다시 발급할 수 는 구조입니다.

 

탈취된 Access Token은 곧 만료되어 사용이 불가능해지고, Refresh Token은 서버에서만 저장하거나, 안전하게 보호되므로 재발급도 어렵습니다.

 

Refresh Token 자체도 탈취될 수는 있지만, 반드시 모든 요청마다 포함할 필요가 없고 Access Token이 만료될 때만 사용되기 때문에 노출 기회가 적어 Access Token 보다는 탈취될 확률이 낮습니다.

 

---

참고자료

https://velog.io/@ckdwns9121/%ED%86%A0%ED%81%B0token%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%83%88%EC%B7%A8-%EB%8B%B9%ED%95%98%EB%8A%94%EA%B0%80