CSRF : LAB [3]
DATE : 2024/1/21
Last updated
DATE : 2024/1/21
Last updated
LAB으로 접속해 wiener 계정으로 로그인 한 다음, 아래와 같이 이메일을 수정한다.
이메일을 수정할 시,
packet에 어떤 정보가 포함되어 있는 지 파악해야 이메일 수정 요청을 만들 수 있기 때문!
packet을 확인해보면 email & csrf token이 서버로 전달되고 있는 걸 볼 수 있다.
지금까지와 다르게 이번 LAB에서는 두 개의 계정을 제공하는 데,,
계정이 두 개 라는 점이 또 하나의 힌트이지 않을까 싶다.
이번엔 두 번째 계정 carlos로 로그인해봤다.
앞서 했듯이 carlos 계정으로도 이메일을 수정해볼까 하는데
우선 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이 서버가 발행한 토큰이기만 하면 되기 때문에 사용자의 메일은 성공적으로 수정될 것이다.
우리에게 주어진 계정이 2개이니 재밌는 걸 해볼 수 있을 거 같다.
스크립트를 저장하고 피해자에게 전달하면 이번 LAB도 해결이다.
