XSS, CSRF
October 20, 2021
XSS(Cross Site Scripting)
- 악성 스크립트가 클라이언트에서 실행됨
- 공격 대상 : 클라이언트
- 목적 : 쿠키ㆍ세션 갈취, 웹사이트 변조 등
XSS는 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법입니다. 주로 의도치 않은 행동을 수행시키거나 쿠키나 세션, 토큰 등의 민감한 정보를 탈취합니다.
<script>…</script>와 같은 JS 코드를 삽입하여 코드가 실행되게 하는 방식으로 공격을 합니다.
해결 방법
- 입력값 치환
- 쿠키 HttpOnly 옵션 사용
등
CSRF(Cross Site Request Forgery)
- 권한을 도용당한 클라이언트가 가짜 요청을 서버에 전송
- 공격 대상 : 서버
- 목적 : 권한 도용
CSRF는 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격입니다.
인증된(권한을 가진) 사용자가 자신의 의도와 무관하게 공격자가 의도한 행위(수정, 삭제 등)를 하도록 유도합니다. 즉, 자기도 모르게 권한이 있어야만 수행할 수 있는 위험한 요청을 서버에 보내도록 하는 것입니다.
이름에서도 볼 수 있듯이 “Request” 즉, 요청만 조작 가능합니다. 응답에는 접근이 불가능합니다.
CSRF 작동 조건
- 쿠키로 로그인이 다루어짐 (유저가 로그인했을 때 쿠키로 어떤 유저인지 알 수 있어야 함)
- 예측할 수 있는 요청 / parameter를 가지고 있어야 함 (Request에 해커가 모를 수 있는 정보가 있으면 안 됨)
공격 예시
현재 bank.com에 로그인되어있다고 가정해 봅시다. 해당 사이트에서 사용되는 인증 쿠키가 브라우저에 저장되고, 브라우저는 bank.com에 요청을 보낼 때마다 인증 쿠키를 함께 전송할 것입니다. 서버는 전송받은 쿠키를 이용해 사용자를 식별하고, 보안이 필요한 재정 거래를 처리합니다.
이제 (로그아웃하지 않고) 다른 창을 띄워서 웹 서핑을 하던 도중에 뜻하지 않게 evil.com에 접속했다 가정해 봅시다. 이 사이트엔 해커에게 송금을 요청하는 폼(form) <form action=“https://bank.com/pay”>이 있고, 이 폼은 자동으로 제출되도록 설정되어 있습니다.
폼이 evil.com에서 은행 사이트로 바로 전송될 때 인증 쿠키도 함께 전송됩니다. bank.com에 요청을 보낼 때마다 bank.com에서 설정한 쿠키가 전송되기 때문입니다. 은행은 전송받은 쿠키를 읽어 (해커가 아닌) 계정 주인이 접속한 것이라 생각하고 해커에게 돈을 송금합니다.
이런 공격을 크로스 사이트 요청 위조라고 부릅니다.
실제 은행은 당연히 이 공격을 막을 수 있도록 시스템을 설계합니다. bank.com에서 사용하는 모든 폼에 “CSRF 보호 토큰(protection token)“이라는 특수 필드를 넣어서 말이죠. 이 토큰은 악의적인 페이지에서 만들 수 없고, 원격 페이지에서도 훔쳐 올 수 없도록 구현되어 있습니다. 따라서 악의적인 페이지에서 폼을 전송하더라도 보호 토큰이 없거나 서버에 저장된 값과 일치하지 않기 때문에 요청이 무용지물이 됩니다.
하지만 이런 절차는 구현에 시간이 걸린다는 단점을 수반합니다. 모든 폼에 보호 토큰을 세팅해줘야 하죠. 또한 요청 전부를 검수해야 합니다.
해결 방법
- Security Token(CSRF Token) 사용
- SameSite 설정 Cookie 사용
등
XSS와 CSRF의 차이점
XSS가 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, CSRF는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것입니다.
XSS와 CSRF는 사용자의 브라우저를 목표로 하는 비슷한 공격이지만,
XSS는 사이트변조나 백도어를 통해 클라이언트에 대한 악성공격을 하고, 인증된 세션이 없어도 공격을 할 수 있으며, 자바 스크립트를 실행 시키는 공격이고,
CSRF는 요청을 위조하여 사용자의 권한을 이용해 서버에 대한 악성공격을 하고, 인증된 세션을 악용하며, 특정한 행동을 실행 시키는 공격이라는 점에서 차이가 있습니다.
