일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- python flask
- 해커팩토리 10번
- 해커팩토리 7번
- 리버싱 기초
- Burp Suite
- 리버싱
- 포렌식
- 해커팩토리
- 디스크 포렌식
- 시스템 해킹
- union sql injection
- 부트스트랩
- 레나 튜토리얼
- CTF-d
- ftz
- SANS
- 해커 팩토리 6번
- 웹해킹 실습
- 보안
- SQL Injection
- 게시판 만들기
- 파일 다운로드 취약점
- 해커팩토리 8번
- 해커 팩토리
- 웹 해킹
- Blind Sql Injection
- 네트워크 포렌식
- 테이블명 수집
- 로그 분석
- Burp Suite Intruder
- Today
- Total
Cha4SEr Security Study
[Web] - JWT를 이용한 사용자 인증 본문
쿠키/세션을 이용한 인증방법과 함께 JWT를 이용하는 방법도 있습니다.
JWT(Json Web Token)는 인증에 필요한 정보들을 암호화 시킨 토큰을 의미합니다.
쿠키/세션 방식과 유사하게 토큰을 HTTP 헤더에 실어서 서버에 보내게 됩니다.
https://jwt.io 사이트에서 jwt의 형태를 볼 수 있습니다.
* jwt 토큰의 구성요소
- Header
- Payload
- Verify Signature
각각 들어있는 데이터는
Header : 서버로 보내기 전 인코딩할 방식과 타입
Payload : 서버에 전송할 데이터(ID, 유효기간 등)
Verify Signature : Base64로 인코딩한 Header,Payload, Secret_Kye)
입니다.
실제로 토큰을 보낼 때는
Encoded Header + "." + Encoded Payload + "." + Verify Signature 로 보내지게 됩니다.
Header와 Payload는 암호화하지 않고 인코딩만 되기 때문에 Header와 Payload는 누구나 디코딩해서 확인할 수 있습니다. (민감한 정보가 포함되어 있으면 쉽게 노출될 수 있음)
하지만 Verify Signature는 Secret_Key를 알지 못하면 복호화 할 수 없습니다.
예를들어, "Cha4ser" 와 "Attacker" 사용자 두명이 있고 각각의 jwt 토큰은 다음과 같다고 했을 때,
"Attacker"는 "Cha4ser"의 정보를 훔쳐보기 위해 jwt 토큰을 가로챈 다음 Pyload의 ID를 Cha4ser로 바꾸고, 다시 인코딩
하여 서버로 보냈습니다.
하지만 서버에서 토큰을 검증할 때 먼저 암호화된 Verify Signature를 검사하게 되는데, 여기서 Payload는
Cha4ser의 사용자 정보가 들어가 있지만, Verify Signature는 Attacker의 Payload를 기반으로 암호화되었기 때문에
유효하지 않는 토큰으로 간주하게 됩니다.
즉, Secret_key를 알지 못하면 토큰을 조작할 수 없다는 뜻입니다.
* JWT를 이용한 인증 절차
1. 사용자는 ID와 PW를 입력하여 로그인
2. 서버에서 계정정보를 읽어 사용자 확인 후, 고유한 ID 값을 부여하며, 기타 정보와 함께 Payload에 넣는다.
3. JWT의 유효기간을 설정한다.
4. 암호화할 Secret_Key를 이용해 Access Token을 발급한다.
5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어서 보낸다.
6. 서버에서는 해당 토큰의 Verify Signature를 Secret_Key로 복호화한 후, 조작 여부와 유효기간을 확인한다.
7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.
*jwt 인증 방식의 장단점
쿠키/세션 방식은 별도의 세션 저장소가 필요하기 때문에 자원을 많이 소모할 수 있지만
jwt 방식은 별도의 저장소 관리가 필요없으며 토큰 발급 후 검증만 하면 되기 때문에 좋은 장점을 가지고 있습니다.
하지만 jwt 방식이라고 해서 모두 안전한 것은 아니며
이미 발급된 JWT에 대해서는 돌이킬수 없다 라는 단점이 있습니다.
세션/쿠키의 경우 쿠키가 악의적으로 이용된다면 해당 세션을 지워버리면 그만이지만, jwt는 한번 발급되면 유효기간이
만료될 때 까지는 계속 사용이 가능합니다.
이 말은 즉, 악의적인 사용자는 유효기간이 지나기 전까지는 지속적인 정보 탈취가 가능하다는 뜻입니다.
이를 해결하기 위해서는 Access Token의 유효기간을 짧게 하고, Refresh Token이라는 새로운 Token을 발급 하는 것이
안전합니다.
*Refresh Token : 처음에 로그인 했을 때 Access Token과 동시에 발급되고, 긴 유효기간을 가지면서
Access Token이 만료됐을 때 새로 발급해주는 열쇠가 되어주는 역할을 하는 토큰
ex) Refresh Token의 유효기간 : 2주 / Access Token의 유효기간 : 1시간 일 때, 사용자는 1시간이 지나게 되면 Access Token이 만료가 되지만 Refresh Token의 만료 전 까지는 Access Token을 새로 발급 받을 수 있음.
(Access Token의 유효기간을 줄일 수 있기 때문에 좀 더 안전함)
*jwt 저장 위치 (Web Storage)
쿠키/세션 방식과 마찬가지로 jwt을 쿠키에 저장할 수도 있지만, Web Storage 라는 것도 있습니다.
Web Stroage 의 특징은 다음과 같습니다.
- 쿠키에 비해 보안이 좀 더 뛰어나ㅈ고, 웹사이트의 성능 영향 없이 더 많은 데이터를 저장할 수 있는 장점이 있다.- 각 도메인과 프로토콜 단위로 저장되어 있다.
Web Storage는 크게 Local Storage와 Session Storage로 나눌수 있는데, 가장 큰 차이점은 Session Storage는 브라우저 창이 꺼지면 데이터가 삭제된다는 것 입니다.
크롬 개발자 도구에서 직접 값을 추가/삭제 가능하며
위와 같이 콘솔창에서 자바스크립트를 통해 제어가 가능합니다.
JS로 제어 가능하다는 말은 그만큼 XSS 공격에 취약할 수 있음을 의미하기 때문에
쿠키/세션 방식과 마찬가지로 XSS 공격에 대한 대비는 항상 해야될 것 같습니다.
(이미지 출처 : https://tansfil.tistory.com/58)
'Web > Web_etc' 카테고리의 다른 글
[Web] 게시판 만들기_03.Flask페이지 이동(글쓰기 페이지 1) (2) | 2021.03.21 |
---|---|
[Web] 게시판 만들기_02.Python Flask, Mysql 연동 (9) | 2020.07.18 |
[Web] 게시판 만들기_01. 부트스트랩 적용 (1) | 2020.07.18 |
[Web] - HTTP / 쿠키와 세션 (0) | 2020.07.13 |