정보보안 스터디 - 30주차 7일 - JWT exploit

 

 

☞ JWT 사용이유

access token입니다.

유저 측 헤더의 쿠키에 넣고 다니면서

쿠키처럼 증명서처럼 인증합니다.

 

안의 정보는 로그인 후 당연히 사용자를 식별하는 ID 이구요.

 

 

 

☞ 처리 과정

처음 로그인 시 서버에 요청해서 expire와 토큰을 받습니다.

 

요청:

로그인 요청 파라미터 값 마저 decode해도 안보입니다. 아마 js 에서 인코딩처리했을 듯합니다.

파라미터	파라미터값(encoding)
grant_type	password
username	~~~
password	~~~
language	~~
devversion	~
ipaddr	~

등이 있습니다.

 

 

응답:

{"access_token":"<토큰>", "expire_~":"", "token_type":"", "파라미터":"값"}

토큰, 만기일, 타입을 포함해서 받습니다.

여기서 파라미터도 암호화되는 경우도 있습니다.

 

 

이후 인증:

Authorization: Bearer <토큰>

 

토큰 그 자체입니다.

파라미터 값들이 

base64 디코더해도 암호화서 그런지 확인 불가합니다.

www.useotools.com

 

 

☞ JWT 구조

header.payload.signature

{ "alg":"none", "typ":"JWT" }{} ~

 

ey~.ey~.~

요청 패킷에서 보일 때는 이런 형태로 됩니다.

 

ey는 base64형태로 바로 디코딩하여 확인 가능합니다.(또한 만들기도 가능합니다.) www.jwt.io

JWT.IO

 

☞ exploit

 

exploit1)

따라서 쉽게 변조할 수 있습니다.

원래는 당연히 변조하지 말라고 signature에서 검증을 하지만, 만약 서버가 설정이 잘못되었거나 제대로 검증하지 않는 경우 헤더 값이 변조되어 들어갈 수 있습니다. 즉 다른 유저로의 권한 상승이 가능합니다. 

 

예측가능하거나 brute-force된다면 키 생성도 가능합니다.

 

exploit2)

alg: none 으로 바꿀 수 있는 경우

보통은 none 처리를 하지 않지만 설정 된 경우입니다.

 

exploit3)

실수로 default or placeholer secrets 바꾸지 않는 경우 

하드코딩된 secret > hashcat 툴을 이용한 brute force 가능 

 

exploit4)

헤더에 다른 파라미터가 들어올 수 있습니다. > 변조가능

jwk 파라미터 등

 

 

 

E2EE 암호화, JWT 증거를 찾아봐야합니다.

개발을 해보는 게 편하긴 합니다.