CSRF

임정환·2023년 5월 12일
0

사이트 A가 당신을 신뢰하고 있는 상태에서. 악의적 해커가 보낸 악성 URL을 클릭하였다. change_pw 엔드포인트에서 id와 pw라는 인자를 전달받으면 해당 pw로 비밀번호를 변경한다고 하자.
"www.site_A/change_pw/?id=lim&pw=1234" ....
사이트 A는 당신을 당신이라고 신뢰하고 있으므로, 군말없이 비밀번호를 변경할 것이다. 당신이 모르는 사이에..

Cross Site Request Forgery

사이트 간 요청 위조

위에서 서술한 방식 그대로, 만약 amazon에 로그인되어 있는 상태로
hack.com에 접속했다고 치자. 이때, hack.com의 img태그에는 amazon의 회원탈퇴 엔드포인트가 src로 첨부됬다면. 안타깝게도, 나의 의지와는 상관없이 나의 amazon 아이디는 삭제될 것 이다!

client가 server에 id와 pw를 통해서 접속하게 되면, session 등을 이용하여
'내'가 '나'임을 증명할 수 있는 수단을 browser에 발급하게 된다.
이후에 server에게 어떠한 http 요청을 할때마다 '내'가 '나'임을 증명할 수 있는 수단인 '세션'등을 같이 헤더에 첨부하여 보낸다면 server는 해당 client임을 알 수 있게된다.

예방법?

  • Http헤더의 referer를 참고한다
    • 사실 조작이 가능한 부분이여서 그리 쓸만해 보이지는 않는다
  • GET / POST 의 구분
    • img태그는 get / form은 post 일테니 이를 구분해주는 것도 유용
  • 민감한 정보를 다룰 때, 임의 난수 Token 발급

이러한 예방법들이 존재할 것이다.

GET/POST... 이렇게 중요한 것이 었다니...
CSRF자체는 원래 알고 있었지만 이로 인한 get과 post의 구분이 유용하다는 것이 참 신기하다.

profile
CS 박제

0개의 댓글

관련 채용 정보