JWT

*JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.*

JWT.IO allows you to decode, verify and generate JWT.

보통 암호화를 통해 상호간의 보안을 강화하기 위해 사용되며, 암호화된 정보들의 무결성이 보장되도록 서명되어있다는 점이 특징이다. public/private key로 이루어진 한 쌍의 토큰이 서명되었다는 것은, private key를 갖고 있는 상대가 서명된 상대라는게 보장된다는 것을 뜻한다.

장점

1. 별도의 인증 저장소가 필요없다.(Stateless) → 서버의 부담이 적다
2. JWT는 서명과 암호화를 통해 안전한 인증을 제공한다. 때문에 토큰이 변조 여부를 판별할 수 있다.
3. JWT는 표준화되어 있기 때문에, 다양한 프로그래밍 언어와 플랫폼에서 사용할 수 있다.
4. REST 서비스로 제공이 가능하다.

단점

1. WT는 JSON 형식으로 인코딩되기 때문에, 많은 필드가 추가될수록 토큰이 커진다.
2. 거의 모든 요청에 대해 토큰이 함께 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있다.
3. 토큰이 유출될 경우 보안에 취약하다.
4. 토큰의 만료 기간을 설정할 수 있지만, 만료 기간이 지나면 사용자가 로그인을 다시 해야 하는 번거로움이 있다.
5. 클라이언트에 저장되는 토큰은 데이터베이스에서 사용자 정보가 바뀌더라도 토큰에 직접 적용할 수 없다.

결론!

암호화된 키를 별도의 인증 저장소 없이 사용할 수 있지만, 서버에서 사용자의 정보가 바뀌었을 때 클라이언트 측에서 토큰의 정보를 갱신하기 위한 별도의 장치가 필요하다.

브라우저에 저장?

우리는 JWT로 만든 access-token을 브라우저에 저장했다가, 서버에 요청을 보낼 때 header에 access-token을 담아 등록된 유저인지 판별한다. 하지만? XSS(Cross Site Scripting), CSRF(Cross Site Request Forgery) 그리고 Web Proxy Tool 등을 이용한 공격은 언제나 클라이언트-서버에서 오고 가는 request와 response를 탈취할 수 있다. 때문에 우리는 JWT를 안전한 곳에 보관해야만 한다.

💡 XSS(Cross Site Scripting)

공격자가 악성 스크립트를 웹 페이지에 삽입하여, 해당 스크립트가 사용자의 브라우저에서 실행되도록 만드는 것이다. 이러한 공격은 사용자의 쿠키, 세션 정보, 로그인 정보 등을 탈취할 수 있으며, 사용자의 브라우저를 제어하여 다양한 악의적인 행동을 수행할 수도 있다. 어떻게 막을 수 있을까?

1. 입력값 검증: 입력값을 검증하여, 사용자의 입력값이 예상한 형식과 일치하는지 확인한다.(스크립트 태그 있는지 확인)
2. 출력값 인코딩: 출력값을 인코딩하여, 스크립트 코드가 실행되지 않도록 한다. (HTML 인코딩을 수행)
3. HTTPOnly 쿠키: HTTPOnly 쿠키를 사용하여, 쿠키를 JavaScript에서 접근할 수 없도록 제한한다.
4. Content Security Policy(CSP): CSP를 사용하여, 허용된 리소스만 불러오도록 제한한다.
5. 권한 제한: 사용자의 권한에 따라, 필요한 권한만 부여한다.(관리자 권한)

💡 CSRF(Cross Site Request Forgery)

CSRF 공격은 공격자가 인증된 사용자의 권한을 이용하여, 악성 요청을 전송하도록 유도하는 것이다. 이를 통해 공격자는 사용자의 정보를 열람하거나 정보를 수정하는 등 사용자가 원치 않는 행동을 할 수 있다. CSRF 공격은 사용자의 브라우저를 통해 수행되기 때문에 웹 애플리케이션에서 추가적인 보안 기능을 제공하여 공격을 방지할 수 있다. 예를 들면?

1. CSRF 토큰: CSRF 토큰을 사용하여,요청이 인증된 사용자에 의해 생성된 것인지 검증한다.
2. SameSite 쿠키: SameSite 쿠키를 사용하여, 쿠키가 다른 도메인에 전송되는 것을 방지한다.
3. CORS: Cross-Origin Resource Sharing (CORS)를 사용하여, 다른 도메인에서의 요청을 제한한다.
4. HTTPS: HTTPS를 사용하여, 데이터를 암호화하여 전송한다.

localStorage

결론적으로 이야기하면, CSRF에는 안전하지만 XSS는 취약하다. localStorage에 접근하는 js 코드를 한줄만 추가하면 언제든지 토큰을 탈취할 수 있기 때문이다.

cookie

위와 반대로 XSS 공격에는 비교적 안전하지만 CSRF에는 취약하다. httpOnly 옵션을 사용하면 js에서 열람이 불가능하지만, 쿠키 특성상 토큰이 자동으로 헤더에 실려 요청이 전송되기 때문에 공격자가 요청 url을 알고 있다면 사용자의 권한을 이용하여 악의적인 요청을 보낼 수 있게 된다.

refresh token

refresh token을 httpOnly쿠키에 저장하여 모든 요청의 헤더에 담아 보내고, access token은 js private variable로 저장하는 방식이다. 이 경우 CSRF로 쿠키가 털려도 탈취되는건 refresh token이기 때문에 별 문제가 없게 된다.