7주차 과제

[Yeonnies]

Q. JWT token 에 대해 리서치해보세요.

• 유효성 검증 방식이 어떻게되는지?
• 다른 사용자가 탈취하게되면 어떻게되는지?
• refresh 처리는 무엇인지?
• ..

JWT token에 대한 조사

쿠키란?

클라이언트가 웹사이트에 접속할 때 그 사이트가 사용하게 되는 일련의 작은 기록 파일

Key Value 형식의 문자열 형대로 응답 헤더에 저장하여 전달, 예를 들어, 쿠키가 있기 때문에 최초 로그인 이후에 다시 아이디와 패스워드를 입력하지 않고 자동 로그인을 할 수 있다.

단점: 쿠키가 노출되면 다른 정보도 다 노출될 수 있으므로 보안이 좋지 않으며 조작해서 들어올 수 있고 이런 경우를 방지할 수 없다.

⇒ 이런 단점을 막기 위해 나온 것이 세션.

세션이란?

특정 세션 저장소에 민감한 정보를 저장하고 이 값을 쿠키에 담는 것.

단점: http의 장점인 statless를 위배한다. 세션 ID를 저장해야하는데, 이것은 상태를 저장하는 것이므로 stateful하게 되는 것이다. 결국 Scale out(서버를 늘리고 싶을 때)에 걸림돌이 생긴다, 또한 매번 요청할 때마다 세션 저장소를 조회해야한다.

⇒ 이런 단점을 해결하는 것이 바로 JWT.

JWT란?

인터넷 표준 인증 방식으로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 것.

그렇다면 쿠키와의 차이점은 뭐냐. 토큰은 서명된 토큰이라는 점. 서명은 뭐냐? signed token을 번역한 것. 공개/ 개인 키를 사용하여 인증하는 방식으로 사용한다.

JWT의 구성요소는 header, payload, signature로 xxxxx.yyyyy.zzzzz와 같은 형태로 사용한다.

• Header: 토큰 타입과 사용된 알고리즘 저장

• Payload: Claim(사용자, 토큰에 대한 property)을 저장

  JWT의 표준 스펙(key-value로 저장, key는 3글자)

  • iss(issuer): 토큰 발급자
  • sub(subject): 토큰 제목
  • aud(audience): 토큰 대상자
  • exp(expiration time): 토큰 만료 시간
  • nbf(not before): 토큰 활성 날짜
  • iat(issued at): 토큰 발급 시간
  • jti(JWT id): JWT 토큰 식별자

  물론 커스텀해도 됨

  payload에는 민감한 정보를 담지 않아야함(암호화 되어있지 않기 때문)

• Signature: 서명, 암호화되어 있다. 복호화할 수 없다.

JWT의 원리

JWT 토큰을 클라이언트가 서버로 전송 → 서버가 개인키로 서명을 복호화 → 헤더값, payload값이 일치하는지 확인 → 인증 허용

• 장점: 별도의 인증 저장소가 필요하지 않고, 상태를 서버가 저장하지 않아도 됨(stateless), 보안성이 좋다.
• 단점: 전달량이 많고 토큰이 탈취당하면 대처가 어렵다.

⇒ 대처 방법: 만료시간(exp)을 짧게 하기, 1시간, 30분 정도로

⇒근데 또 짧으면 사용자는 불편하지 않나?

이를 보완하기 위한 방법

1. Sliding Session
   계속 사용하고 있는 사용자에게 만료 시간 연장, 단발적으로 접속할 경우 연장시켜주지 못하고 계속 접속하고 있으면 무한정으로 Token을 사용한다는 문제점
2. Refresh Token
   Access Token을 Refresh 해주는 것을 보장한다.(7일, 30일) 만료될 경우 새로운 Access Token을 발급

Refresh Token의 원리

Access Token과 Refresh Token을 같이 발급 → 클라가 Access Token이 만료될 경우 Refresh Token으로 새로운 Access Token을 발급 요청 → 서버가 Refresh Token이 있는지 확인하고 만약 있다면 Access Token을 새로 생성해서 전달

⇒ 이럼 Session의 단점인 세션 저장소 계속 조회해야하는 단점과 비슷한 단점이 생기는 거 아닌가? Refresh Token 저장소에서 조회하는 작업이 일어나니까..

⇒ 아님. 세션은 맨날 조회해야하는데 리프레시 토큰은 만료될 경우에만 접근하는 거임.

Q. 웹 서비스의 취약점은 무엇이 있을지 리서치해보세요.

• XSS?
• CSRF?
• SQL Injection?
• File Upload/Download 간의 취약점
• Parameter Tampering
• ..

웹서비스 취약점 조사

1. 크로스사이트 스크립팅 (XSS)

CSS랑 초성이 같아서 XSS라고 함.

정의: 웹 페이지에 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되게 하는 공격으로, 이를 통해 공격자는 사용자의 세션을 가로채거나, 악성 코드를 실행할 수 있다.

공격 방식:

• 반사형 XSS (Reflected XSS): 악성 스크립트가 URL 등에 포함되어 사용자에게 전달되고, 사용자가 해당 링크를 클릭하면 스크립트가 실행되도록 함.
  (이해하기 쉽게) 악성 스크립트가 담긴 URL을 사용자에게 노출 → 사용자가 해당 URL을 클릭한다. → URL에 사용자가 정보를 입력한다. → 스크립트 실행
• 저장형 XSS (Stored XSS): 악성 스크립트가 게시판 등의 데이터베이스에 저장되어, 해당 콘텐츠를 조회하는 모든 사용자에게 스크립트가 실행된다.
  (이해하기 쉽게) 악성 스크립트를 포함한 게시글을 업로드한다. → 사용자가 게시글을 클릭한다. → 스크립트 실행
• DOM 기반 XSS (DOM-Based XSS): 클라이언트 측에서 DOM을 동적으로 조작할 때 발생하는 취약점으로, 서버를 거치지 않고도 스크립트가 실행될 수 있다.

⇒ 이 스크립트가 실행될 경우 쿠키 정보 및 세션 ID가 노출되거나, 시스템 관리자 권한을 얻게 되거나 거짓 페이지를 노출하는 등의 문제가 생길 수 있다.

방어 방법:

• 문사용자 입력을 철저히 검증하고, 특수 문자를 HTML 엔티티로 변환하여 스크립트 실행을 방지
• 출력 시에는 적절한 인코딩을 적용하고, 콘텐츠 보안 정책(CSP)을 설정하여 신뢰할 수 없는 스크립트의 실행을 제한

2. 크로스사이트 요청 위조 (CSRF)

정의: 사용자가 의도하지 않은 요청을 서버에 보내도록 유도하여, 사용자의 권한으로 비정상적인 동작을 수행하게 하는 공격

공격 방식:

• 공격자는 사용자가 특정 웹사이트에 로그인한 상태에서, 악성 스크립트가 포함된 페이지를 방문하게 유도한다. 사용자의 브라우저는 자동으로 해당 요청을 보내게 되고, 서버는 이를 정상적인 사용자 요청으로 인식하게 된다.(신뢰할 수 있는 사용자를 사칭해 웹 사이트에 원하지 않는 명령을 보낸다.)

방어 방법:

• 각 요청에 고유한 CSRF 토큰을 포함시켜, 서버에서 이를 검증하도록 한다.
• SameSite 쿠키 속성을 설정하여 크로스 사이트 요청 시 쿠키가 전송되지 않도록 한다.
• Referer 헤더를 검증하여 요청의 출처를 확인한다.

3. SQL 인젝션 (SQL Injection)

정의: 웹 애플리케이션의 입력값을 통해 악의적인 SQL 구문을 주입하여 데이터베이스를 조작하거나 민감한 정보를 탈취하는 공격

공격 방식:

• 공격자는 입력 필드나 URL 파라미터에 SQL 구문을 삽입하여, 인증 우회, 데이터 조회, 수정, 삭제 등의 행위를 수행

방어 방법:

• 준비된 문(Prepared Statements)이나 ORM(Object-Relational Mapping)을 사용하여 입력값을 쿼리와 분리하고, 사용자 입력을 철저히 검증, 데이터베이스 사용자에게 최소한의 권한만 부여하고, 에러 메시지를 통해 내부 정보가 노출되지 않도록 주의

4. 파일 업로드 취약점

정의: 파일 업로드 기능을 악용하여 악성 스크립트나 웹 셸을 서버에 업로드하고 실행하는 공격

공격 방식:

• 공격자는 허용되지 않은 확장자의 파일을 업로드하거나, 우회 기법을 사용하여 악성 파일을 서버에 저장하고, 이를 통해 서버 권한을 획득하거나 악성 코드를 실행

방어 방법:

• 업로드 가능한 파일의 확장자를 제한, 업로드된 파일의 이름을 난수화하여 저장하며, 업로드 디렉토리의 실행 권한을 제거
• 파일 업로드 시 MIME 타입과 파일 내용을 검증하여 악성 파일의 업로드를 방지

5. 파일 다운로드 취약점

정의: 파일 다운로드 기능에서 입력값 검증이 미흡하여, 공격자가 임의의 파일을 다운로드할 수 있다.

공격 방식:

• 공격자는 파일 경로를 조작하여 시스템의 중요한 파일이나 소스 코드를 다운로드 할 수 있다. 예를 들어, 경로 이동 문자(../)를 이용하여 상위 디렉토리의 파일에 접근하는 방식.

방어 방법:

• 파일 경로 입력값을 철저히 검증하고, 허용된 디렉토리 내의 파일만 접근할 수 있도록 제한
• 파일 다운로드 시 경로 조작을 방지하기 위해 경로 이동 문자를 필터링하거나, 화이트리스트를 사용하여 허용된 파일만 다운로드할 수 있도록 설정

6. 파라미터 변조 (Parameter Tampering)

정의: 클라이언트와 서버 간의 통신에서 파라미터를 조작하여, 권한 상승이나 부정한 행위를 수행하는 공격

공격 방식:

• 공격자는 URL, 쿠키, 폼 데이터 등의 파라미터를 수정하여, 예를 들어 상품 가격을 변경하거나, 다른 사용자의 정보에 접근하는 등의 행위를 할 수 있다.

방어 방법:

• 서버 측에서 중요한 데이터나 권한 정보를 신뢰하지 않고, 세션이나 데이터베이스를 통해 검증
• 파라미터의 무결성을 확인하기 위해 HMAC 등의 기법을 사용하여 파라미터 변조를 감지한다.

Q. Spring Security Filter 들이 뭐가 있고, 각각 어떤 역할을 하는지 리서치해보세요.

Spring Security Filter 조사 내용

1. SecurityContextPersistenceFilter

요청이 시작될 때 SecurityContext를 복원하고, 요청이 종료될 때 이를 저장

세션 간에 인증 정보를 유지

2. UsernamePasswordAuthenticationFilter

사용자의 아이디와 비밀번호를 통한 인증 처리.

주로 로그인 요청을 가로채어 사용자의 자격 증명을 검증.

3. BasicAuthenticationFilter

HTTP 기본 인증 헤더를 통해 전달된 자격 증명을 처리

간단한 인증 방식을 지원

4. BearerTokenAuthenticationFilter

Bearer 토큰을 이용한 인증을 처리

주로 OAuth2 등의 토큰 기반 인증에서 사용

5. SecurityContextHolderAwareRequestFilter

SecurityContextHolder에 저장된 인증 정보를 기반으로 보안과 관련된 요청 래퍼를 생성

보안 컨텍스트에 접근한다.

6. AnonymousAuthenticationFilter

인증되지 않은 사용자를 익명 사용자로 간주하고, 이에 대한 인증 객체를 생성

인증되지 않은 사용자도 일정한 권한을 가질 수 있음

7. SessionManagementFilter

세션 관리와 관련된 작업 처리

예를 들어, 동시 세션 제어나 세션 고정 보호 등을 담당

8. ExceptionTranslationFilter

인증 또는 인가 과정에서 발생하는 예외를 처리하고, 적절한 응답을 반환

예를 들어, 인증이 필요한 경우 로그인 페이지로 리다이렉트하는 등의 작업을 수행

9. FilterSecurityInterceptor

최종적으로 요청에 대한 인가를 결정

URL, 메서드 등과 같은 정보를 기반으로 접근을 허용할지 말지를 판단

⇒ 이러한 필터들은 FilterChainProxy에 의해 관리됨. 각 필터는 설정된 순서에 따라 실행, 필요에 따라 커스텀 필터를 추가하거나 기존 필터의 동작을 변경할 수 있음. 이를 통해 애플리케이션의 보안 요구 사항에 맞게 필터 체인을 구성한다.