얼마 전에 퀘이사존에서 특정 글을 보면 회원이 탈퇴되는 일이 있었다고 합니다. 금방 조치가 되긴 했지만 도대체 이걸 어떻게 했을까 싶기도 하고, 왜 사이트에서는 이걸 막지 못했을까 생각하면서 XSS와 CSRF에 대해서 알아보게 되었습니다.

 

목차


    0. XSS

    XSS(Cross-Site-Scripting)웹사이트에서 의도치 않은 스크립트를 넣어서 실행시키는 기법을 말합니다.

     

    보통 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어집니다. 그리고 스크립트가 포함된 글을 열어보게 되면 브라우저에서 원치 않는 스크립트가 실행되는 방식이죠.

     

    이걸 통해 유저의 쿠키 정보를 탈취하거나, 유저 비밀번호를 변경하는 api를 호출하는 행위를 할 수 있습니다.

     

    그림을 통해 과정을 더 자세히 살펴보겠습니다!

     

    출처 : https://nascenia.com/why-cross-site-scripting-is-detrimental-and-how-to-prevent/

     

    1. Perpetrator(침입자)는 사이트의 취약점을 찾습니다.

    2. 취약점을 찾아서 세션 쿠키를 탈취하는 스크립트를 사이트에 삽입합니다.

    3. 사용자가 그 웹사이트에 접근할 때마다 스크립트가 작동합니다

    4. 스크립트를 통해 침입자에게 사용자의 세션 쿠키가 전달됩니다.

     

    위는 가장 기초적인 방식이고, XSS의 종류는 크게 세 가지로 나눌 수 있습니다.

     

    0.0. Stored XSS

    XSS 공격 스크립트를 웹 사이트의 방명록이나 게시판에 삽입하고, 다른 사용자들이 그 글을 확인할 때 스크립트 코드가 사용자에게 전달되고 세션 쿠키가 침입자에게 전달되는 방식입니다.

     

    스크립트를 웹 서버에 저장하기 때문에 Stored라는 이름이 붙게 되었습니다.

     

     

    0.1. Reflected XSS

    공격 스크립트가 삽입된 URL을 사용자가 클릭하도록 유도하는 방식입니다.

     

    클릭 요청이 발생하면 바로 스크립트가 반사되어 돌아온다고 해서 Reflected라는 이름이 붙었습니다.

    보통 피싱공격에 많이 

     

     

    0.2. DOM-based XSS

    사용자의 브라우저에서 DOM 환경을 수정하면 스크립트가 실행되는 방식입니다.

    페이지 자체는 변경되지 않지만 DOM에서 발생한 수정으로 인해 페이지에 포함된 클라이언트쪽 코드가 다르게 실행됩니다.

     

    조금 더 쉽게 말하면 스크립트는 HTML페이지가 구문분석이 될 때마다 실행됩니다. 그렇기 떄문에 다른 XSS 방식과는 다르게 서버와는 전혀 관계가 없습니다.

     

     

    0.3 XSS의 방지 대책

    쿠키에 중요한 정보를 담지 않고 서버에 중요 정보를 저장하는 방식을 사용할 수 있습니다.

    그리고 httponly 속성을 다는 방식을 사용할 수 있습니다. (document.cookie를 이용해서 쿠키에 직접 접근하는 것을 막는 옵션입니다!)

    마지막으로 보안과 관련된 함수를 사용한 Secure coding을 통해 XSS를 방지할 수 있습니다.

     


    1. CSRF

    CSRF 공격(Cross-Site-Request-Forgery)은 웹 어플리케이션 취약점 중 하나로 사용자가 자신의 의지와는 무관하게 침입자가 의도한 행위를 서버에 요청하게 만드는 공격입니다.

     

    XSS가 사용자가 특정 사이트를 신뢰하기 때문에 발생하는 문제라면, CSRF는 특정 사이트가 사용자를 신뢰하기 때문에 발생하는 문제입니다.

     

    XSS는 클라이언트의 브라우저에서 발생하는 문제라면 CSRF는 서버에서 발생하는 문제입니다.

    침입자가 XSS를 사용하면 사용자의 쿠키를 탈취할 수 있고, CSRF를 사용하면 서버로부터 권한을 탈취할 수 있습니다.

     

    이번에도 그림을 통해 과정을 더 자세히 살펴보겠습니다!

    1. Perpetrator(침입자)는 서버로 넘어가는 자금 전송에 대한 요청을 조작하려고 합니다.

    2. 침입자는 하이퍼링크에 자금 전송 요청에 대한 스크립트를 삽입하고 사이트에 로그인할 사람들에게 전송합니다.

    3. 사용자는 링크를 누르고, 의도치않게 서버로 요청을 보내게 됩니다.

    4. 서버는 로그인 되어있는 사용자의 요청이기 떄문에 정상으로 인식하고 침입자에게 돈을 전송합니다.

     

    출처: https://rusyasoft.github.io/java/2019/02/15/spring-security-csrf-from-context/

     

    다른 예시를 보면 사용자는 mybank에 로그인하고 침입자의 url에 접근하면 CSRF코드가 실행되고, 브라우저는 mybank에게 사용자가 원하지 않는 요청을 보내게 됩니다. mybank는 이 요청을 사용자가 보낸 요청이라 생각하고 정상적으로 처리되고, 침입자에게 돈이 전달되는 것이죠.

     

    1.0 CSRF의 방지 대책

    Request header에 있는 요청을 한 페이지의 정보가 담긴 referrer 속성을 검증하여 차단하는 방법을 주로 사용합니다.

    같은 도메인상에서 요청이 들어오지 않으면 차단하도록 하는 방법입니다. (엉뚱한 곳에서 해당 URI에 접속하려고 하는 것을 차단하는 것을 의미합니다!)

     

    또한 (많은 사람들이 귀찮아하는) CAPTCHA를 사용할 수 있습니다. 정말 많은 사이트들에서 요구하는 CAPTCHA가 바로 이 CSRF를 막기 위한 하나의 방법입니다!!

     

    마지막으로 CSRF Token을 사용할 수 있습니다. 랜덤한 UUID와 같은 임의의 난수를 세션에 저장해두고 해당 난수가 전달되지 않는다면 요청을 거부하는 방법이 있습니다.

    반응형
    • 네이버 블로그 공유하기
    • 네이버 밴드에 공유하기
    • 페이스북 공유하기
    • 카카오스토리 공유하기