DVWA 실습 #4-1 - CSRF(low)

2021/01/06 - [프로젝트/DVWA 실습] - DVWA 실습 #4 - CSRF

DVWA 실습 #4 - CSRF

문제 해결 방법

Low 단계에서는 GET 메서드의 파라미터로 새로운 비밀번호와 새로운 비밀번호 확인 문자열을 받아서 요청을 처리하기 때문에 다음처럼 악성 URL을 클릭하면 비밀번호가 URL에 기재된 대로 변경된다.

이를 테스트해보기 위해서 빈 페이지(about:blank)에 자바스크립트를 활용하여 링크 태그를 하나 추가한 후 href 속성을 비밀번호 변경 페이지로 설정하여 위처럼 악성 URL을 생성하였다. 위 링크를 클릭하면 비밀번호를 00000000으로 변경하는 요청이 전송되며 사용자 인증 수단이 없기 때문에 사용자가 이 악성 링크를 클릭해서 원치 않게 비밀번호를 00000000으로 변경하는 것인지 실제로 비밀번호를 00000000으로 변경하려는 것인지 서버 측에서는 구분할 수 없다. 그러므로 CSRF 공격이 성공하며 현재 로그인된 DVWA 계정(admin)은 비밀번호가 00000000으로 변경된다.

Password Changed. 문구가 출력되었다.

실제로 로그아웃 후 다시 로그인하려고 하면 로그인이 실패하는 것을 볼 수 있다.

기존 admin 계정의 비밀번호인 password를 입력했지만 Login failed라는 문구와 함께 로그인이 실패했다. 비밀번호를 00000000으로 입력하고 나서야 다시 로그인할 수 있었다. 이런 URL을 사용자의 메일이나 방명록같은곳에 삽입하면 해당 사용자가 그 사이트에 접속해있을 경우 본인도 모르게 비밀번호 변경 요청을 수행하는 것이 가능하다.

 

물론 지금처럼 a 태그에 href로 url을 삽입하는 경우 실제로 해당 페이지로 이동하기 때문에 "Password Changed."라는 비밀번호 변경 문자열을 사용자가 볼 수 있어 직접 링크를 클릭하기보다는 다른 방법으로 공격하는 것이 좋을 것이다. 그러나 이전 포스트에서 언급했듯이 CSRF 보안 대책이 점차 강화되고 CORS나 SameSite Cookie 등이 등장하면서 CSRF 무용론도 등장하고 있는 만큼 우회법을 찾기는 어려워 보인다.

Cross-Site Request Forgery is dead!

OWASP Top 10 2014에서 2017로 업데이트되면서 리스트에서 내려간 이유가 있는 것 같기도 하다. 물론 보안에서 방심은 금물이다. 취약한 브라우저를 사용하는곳이나 CSRF 방어 기법들이 적용되지 않은 곳에서는 충분히 발생할 수 있는 공격일 것이다.