CSRF : LAB [3]

DATE : 2024/1/21

❗CSRF where token is not tied to user session

LAB으로 접속해 wiener 계정으로 로그인 한 다음, 아래와 같이 이메일을 수정한다.

이메일을 수정할 시,

packet에 어떤 정보가 포함되어 있는 지 파악해야 이메일 수정 요청을 만들 수 있기 때문!

packet을 확인해보면 email & csrf token이 서버로 전달되고 있는 걸 볼 수 있다.

지금까지와 다르게 이번 LAB에서는 두 개의 계정을 제공하는 데,,

계정이 두 개 라는 점이 또 하나의 힌트이지 않을까 싶다.

이번엔 두 번째 계정 carlos로 로그인해봤다.

앞서 했듯이 carlos 계정으로도 이메일을 수정해볼까 하는데

우리에게 주어진 계정이 2개이니 재밌는 걸 해볼 수 있을 거 같다. 😏

우선 carlos 계정으로 이메일을 수정하는 요청을 보내고 이 packet을 잡아둔다.

그 다음, carlos가 아닌 wiener에게 발행된 CSRF token을 carlos의 CSRF token 대신 전달한다.

결과를 확인해보면..! 성공적으로 carlos의 메일이 수정된 걸 볼 수 있다!!!

즉 이번 LAB에서는 CSRF Token을 필요로 하지만 발행된 Token이 누구의 것인지 확인하는 과정은

부실한 듯하다. 그렇기 때문에 공격자가 자신의 계정을 만들어 본인에게 발행된 Token을 사용하면

다른 사용자의 메일을 수정하는 요청에 사용할 수 있게 되는 것이다.

wiener에게 발행된 CSRF Token을 가지고 사용자의 메일을 수정하는 스크립트를 작성한다.

이 스크립트를 서버로 보내게 되면 POST method로 email & csrf parameter를 보내게 되고

csrf token이 서버가 발행한 토큰이기만 하면 되기 때문에 사용자의 메일은 성공적으로 수정될 것이다.

스크립트를 저장하고 피해자에게 전달하면 이번 LAB도 해결이다. 👍