Signature Validation Mistakes → JWT
payload = jwt.decode(token, self.secret, algorithms=["HS256", "HS384", "HS512", "RS256", "RS384", "RS512"]) 이렇게 HS와 RS 구분을 안 해두면 대칭키에서 비밀키를 사용하는 방식으로 key를 활용할 수 있다. 공개키로 제공된 걸 비밀키로 넣고, 대칭키로 사용했을 때 이를 필터링해주지 못하면서 로그인이 뚫릴 수 있다.
Token LifeTime
토큰을 검증하기 전에, 토큰의 수명부터 체크해야 한다. → exp (expiration time)
curl -H 'Content-Type: application/json' -X POST -d '{"username":"user", "password": "password2"}' http://10.201.1.79/api/v1.0/example5
→ Authenticate the API
curl -H 'Authorization: Bearer [JWT Token]' http://10.201.1.79/api/v1.0/example5?username=user → authenticated, then verify the user.
Cross-Service Misconfiguration(교차 서비스 오구성)
JWT는 여러 applicatino에 서비스를 제공하는 중앙 집중식 인증 시스템에서 자주 사용하게 되는데, 특정 application에서만 유효해야 하는 claim이 있을 때가 있다. → 이를 위해 audience claim을 사용
이게 올바르게 사용되지 않으면 Cross-Service Relay 공격이 발생하여 권한 상승 공격으로 이루어질 수 있다.
claim : JWT 안에 있는 정보(데이터 조각) → payload 안에 있는 key-value 형태의 Info
JWT : Header + Payload + Signature
A application에서는 모든 사용자가 "admin": true라는 claim이 포함될 수 있는데 B application에서는 안 그럴 수 있다. 그렇게 됐을 때, A에서 B로 넘어갈 때 검증을 제대로 하지 않으면 B application에서 사용자가 admin 권한을 가지고 있다고 잘못 판단할 수 있다.