이번 문제는 이메일 변경에 CSRF 취약점이 있고 특정 유형의 요청에서만 방어한다고 한다.
우선 이메일 변경 방식은 저번문제랑 동일하고
저번 문제와 같은 형식의 코드를 전송했더니
csrf 파라미터가 없다고 오류 메시지가 출력된다.
이는 csrf 토큰을 의미하는데
csrf 토큰이란?
서버에 들어온 요청이 실제 서버에서 허용한 요청이 맞는지 확인하기 위한 토큰으로 서버 측 애플리케이션에서 생성되고 클라이언트와 공유되는 인증 값이다.
이번 문제에서는 문제 이름에서 힌트를 얻을 수 있는데 특정 유형의 요청에서만 방어하는 csrf이므로
요청 방식을 postdptj get으로 바꿔봤다.
어라? 이메일이 변경되었다.
왜 get방식에서는 csrf토큰이 없어도 이메일이 변경되는 것일까?
왜냐하면 CSRF 토큰 필터는 GET방식의 데이터 전송에는 관여하지 않는다. 만약 GET방식까지 막아버리면 다른 사이트에서 링크를 타고 들어오는 요청이나 RESTful API 등을 처리할 수가 없게 된다.
그럼 csrf토큰이 존재해도 get으로 보내면 다 변경돼서 보안이 취약한 거 아니냐는 생각이 들 수 있지만
사실 이러한 개인정보와 시스템 변경 같은 정보를 get방식으로 받는 것은 매우 위험하기 때문에 애초에 get으로 받지 않는다.
이번 문제만 문제 풀이를 위해 get으로도 받을 수 있게 만들어 놓은 것 같다.
문제를 풀면서 또 다른 풀이를 발견했는데
이메일 변경 페이지 코드를 보면
이렇게 csrf코드가 숨겨져 있다.
이걸 복사해서 요청을 보내면 post방식으로도 이메일을 변경할 수 있다.
이메일이 변경되는 걸 볼 수 있다.
근데 이상하게 문제 의도와는 달라서 그런지 정답처리는 되지 않는다.
