CSRF
공격자로 인해서 피해자는 자신의 의도와는 다르게 서버로 어떤 요청을 하게 만드는 것
CSRF와 XSS와 다른 점
XSS는 클라이언트 측에서 스크립트로 실행하는 공격
CSRF는 피해자가 클라이언트에서 서버로 임의로 어떤 요청을 하게 만드는 공격
CSRF는 단독으로 취약점이 발생할 수 있지만 요청 링크를 잘 활용하게 위해서
CSRF 취약점이 있는 경우 XSS 취약점을 찾으면 시너지를 낼 수 있다.
CSRF는 어디에서 일어나나?
요청을 위조하는 공격이고 요청을 하게 만드는 공격이기 때문에 모든 요청에서 일어난다
하지만 모든 요청을 보호해야 할 필요는 없다고 한다.
예를 들어 공지사항 수정에서 일어나는 요청으로는 위험하다고 판단이 안되면 주관에 따라 강력하게 보호를
하지 않아도 문제없지만 비밀번호 수정 같은 요청에서 일어나는 CSRF는 보호를 해야 한다.
비밀번호 수정에서 일어나는 CSRF는 어떻게 보호하나?
공격자가 전에 쓰던 비밀번호는 알기 힘들기 때문에 전에 쓰던 비밀번호를 인증정보에 포함시키면 된다고 한다.
CSRF 취약점이 GET 요청으로 일어나는 경우
링크를 바로 활용할 수 있다.
CSRF 취약점이 POST 요청으로 일어나는 경우
XSS 취약점이 있어야 활용할 수 있다.
폼 태그 안에 인풋 태그를 활용해서 요청을 보낼 수 있고
자바스크립트를 통해서 자동으로도 요청을 보낼 수 있다.
document.getElementById('form').submit();
CSRF Token
CSRF 공격을 막기 위해 만든 랜덤 한 토큰
서버에서 생성해서 클라이언트에게 보내준 토큰과
클라이언트가 서버로 요청을 보낼 때 그 토큰 값을 대조해서 요청을 확인한다.
이런 특성 때문에 공격자가 랜덤하게 생성한 토큰을 탈취하기만 한다면 우회를 할 수 있다.
CSRF 대응방법
referrer check
CSRF 대응방법 중 referrer check란 비밀번호 변경하는 페이지가 있으면 해당하는 페이지의 referrer 헤더 요청이 들어있어야 하는데 referrer에 다른 페이지가 들어있으면 이 요청을 보고 대응을 할 수 있다. 그렇기 때문에 제대로 구현을 해놓으면 우회할 수 없다고 한다.
하지만 referrer 체크를 사용하면 확장성이 떨어질 수 있다. 예를 들어 사용자가 비밀번호 바꾼 지 1년이 지나서 비밀번호 창을 띄우고 싶은데 이렇게 하려면 referrer 을 확인해야 하기 때문에 이런 기능은 사용하지 못한다.
그렇기 때문에 개발자들은 예외 처리라는 걸 하는데 referrer 헤더가 들어있지 않아도 예외 처리를 해 요청을 허용한다고 한다.
CSRF 공격 문구를 작성할 때 메타태그에 이렇게 작성하면 referrer 요청이 없어진다.
<meta name =”referrer” content=”no-referrer”>
근본적인 방법
폼 태그 안에 위조할 수 없게 이전 비밀번호 같은 인증정보를 포함해서 보내게 한다. 그리고 상황상 CSRF 토큰이나 레퍼러 체크가 필요한 경우는 게시판 같은 경우인데 이런 경우 게시판을 사용할 때 계속 비밀번호를 요구할 수는 없기 때문에 CSRF 토큰이나 레퍼러 체크를 넣어둔다.
