CSRF
Cross Site Request Forgery
불특정 다수를 대상으로 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 하도록 만드는 공격
사용자가 인증한 세션에서 웹이 정상적인 요청과 비정상적인 요청을 구분하지 못하는 점을 악용하는 공격방식
=> 공격자의 요청이 사용자의 요청인 것 처럼 속인다...!
요청의 주체를 속이는 방식이고 공격자에게 데이터가 반환되지는 않으므로 데이터를 탈취하기 위한 공격은 아님
Q. XSS와 다른점이 뭔가요?
일반적으로 XSS가 사용자가 특정 사이트를 신뢰한다는 점을 공격하는거라면, CSRF는 특정 사이트가 사용자의 브라우저를 신뢰한다는 점을 공격한다는 것이 가장 큰 차이
그래서 대부분의 XSS는 클라이언트에서 악성 코드가 발생하고 CSRF는 서버에서 악성코드가 발생
더 자세한 내용은 XSS
CSRF 공격 과정
CSRF는 특정한 조건에 만족되야 성공할 수 있음
- 사용자가 공격자가 만든 피싱 사이트에 접속할 것
- 피싱 사이트에 접속 할 때 사용자는 위조 요청을 보낼 사이트에 로그인이 되어 있을 것
=> 만약 XSS가 성공한 사이트가 있다면 피싱 사이트에 접속하지 않아도 CSRF 공격 실행 가능
CSRF는 서버에 직접적으로 공격을 가하는 방식이 아니기 때문에 둘 중 하나라도 만족하지 않는다면 공격 불가
최근 대부분의 사이트가 자동 로그인 기능을 사용하기 때문에 생각보다 저 조건에 해당되는 경우가 많다...

- 사용자가 서버에 로그인하면 세션 정보를 사용할 수 있는 session ID가 사용자의 브라우저 쿠키에 저장
- 사용자가 서버에 로그인이 되어있는 상태로 피싱 사이트에 접속
- 피싱사이트에서 쿠키에 저장된 session ID를 이용해서 서버에 위조된 요청 전송
- 서버는 session ID를 통해 해당 요청이 인증된 사용자로부터 온 것이라고 판단하고 처리
CSRF 대처 방법
가장 중요한 점은 공격자의 요청과 실제 요청을 구분하는 것
Referer 검증
HTTP 요청헤더 정보에서 referer을 확인하여 domain이 일치하는지 검증하는 방법
일반적인 referer 검증 만으로도 대부분의 CSRF 공격을 방어할 수 있음
=> 같은 도메인 내의 페이지에 XSS 취약점이 있는 경우 제외
CSRF 토큰 사용
사용자 세션에 임의의 값을 저장하여 모든 요청마다 해당 값을 포함하여 전송하도록 함
서버에서 요청을 받을 때마다 세션에 저장된 값과 요청과 함께 전송된 값이 일치하는지 검증
=> 이 방법 또한 같은 도메인 내에 XSS 취약점이 있다면...
CAPTCHA

요청 시 CAPTCHA를 이용해서 CAPTCHA 인증코드가 없거나 틀리면 요청을 거부
그럼 항상 CSRF로부터 취약한건가요?
클라이언트 기반 인증방식을 사용하는 경우는 요청마다 인증하니까 괜찮아...!
RestAPI 또한 JWT 등 토큰 기반 인증방식을 사용하기 때문에 괜찮아...!!
RestAPI와 JWT토큰 인증방식이 궁금하다면?
이런 경우에는 CSRF 대처방법을 사용하지 않아도 괜찮다!
'FE Study' 카테고리의 다른 글
| [FE] Flex vs Grid (0) | 2024.07.28 |
|---|---|
| XSS (0) | 2024.07.15 |
| [FE] Reflow / Repaint (0) | 2024.07.09 |
| [FE] 브라우저 렌더링 (0) | 2024.07.03 |
| HTTP vs TCP (0) | 2024.06.22 |