XSS와 CSRF

nathan·2022년 5월 19일
2

WEB

목록 보기
1/1

XSS와 CSRF

목차

  • 주제 선정 이유
  • XSS의 의미와 실제 사용 사례 및 코드 사례 + 방어 방법
  • CSRF의 의미와 실제 사용 사례 및 코드 사례 + 방어 방법
  • XSS와 CSRF의 차이점

왜 XSS와 CSRF를 선정하게 되었나?

  • JWT 유저인증시 refreshToken의 저장장소 - 쿠키 또는 웹 스토리지 등에 대해서 고민
    • refreshToken을 secure httpOnly 쿠키에 담아 서버와 클라이언트가 통신
    • accessToken은 JSON payload로 받아와서 웹 애플리케이션 내 로컬 변수로 이용
  • 이를 통해 CSRF 취약점 공격 방어하고, XSS 취약점 공격으로 저장된 유저 정보 읽기는 막을 수 있음
  • 하지만 XSS 취약점을 통해 API 요청을 보낼 때는 무방비하므로 XSS 자체를 막기 위해 서버와 클라이언트 모두 노력해야 함
  • XSS, CSRF가 도대체 뭐길래???

XSS

  • Cross-site scripting이 본명(CSS와의 혼동을 우려하여 XSS로 변경) - 우리 말로는 “사이트 간 스크립팅”

    • 웹 애플리케이션에서 많이 나타나는 취약점의 하나로 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점을 말한다. 주로 여러 사용자가 보게되는 전자 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어진다. 이 취약점은 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 나타난다.
  • 종류

    • Reflected-XSS

      • 대표적으로 url에 쿼리 파라미터 값으로 html 태그를 넣어 서버로 요청 → 쿼리 파라미터가 있는 상태 그대로 브라우저로 응답되어 스크립트 실행 → 웹 앱 내에 스크립트가 저장되지 않고, 1개의 요청에 대해 1개의 응답으로 공격이 진행됨
        http://127.0.0.1:8080/hello?username=<script>alert("XSS";);</script>;
        
        • 보통 변조된 URL을 통하여 Reflected-XSS가 진행되며, URL 뿐만 아니라 다른 방식도 존재
          • 사용자 계정
          • credential
          • 민감한 데이터
          • 쿠키와 세션
          • 다른 클라이언트의 컴퓨터에 빠르게 액세스
    • Stored-XSS

      • 게시판 같은 곳에 script를 심어두어(DB) 연관이 없는 이용자가 해당 script가 있는 페이지를 방문하면, 자동으로 script가 실행되는 방식으로 공격이 진행된다.
        <iframe ID="showFrame" SRC="javascript:document.write('
        <script> 
        alert(3);
        function show() {
        alert(5);
        }
        alert(4);
        </script>
        ');" width="0" height="0" frameborder="0"></iframe>
        <button id="button" onClick='document.getElementById
        ("showFrame").contenWindow.show()'>버튼</button>
    • DOM-based-XSS

      • 사용자가 제공한 데이터가 적절한 삭제 없이 DOM 객체에 제공될 때 발생한다.

XSS 방지

  • 사용자의 입력에 대해 클라이언트측과 서버측이 모두 검증을 해야한다. - 우회할 수 있는 방법이 상상이상으로 많다.

    • 어떤 검증? → HTML 태그나 자바스크립트에 사용되는 특수 문자들에 대한 필터링 또는 인코딩 by Escaping
      • 경우에 따라 허용해야만 할 때가 있는데, 이 때는 반드시 사용해야 하는 태그를 필터링하여 사용하도록 하자.
    • Cookie에 HttpOnly를 설정하면 스크립트로 쿠키를 로드할 수 없다.
    • 참고 : Cookie에 secure를 설정하면 쿠키가 암호화되어 전송되므로, 네트워크를 통한 쿠키 가로채기도 막을 수 있다.
  • 출처 : 웹 해킹 강좌 ⑦ - XSS(Cross Site Scripting) 공격의 개요와 실습 (Web Hacking Tutorial #07) - https://www.youtube.com/watch?v=DoN7bkdQBXU

  • https://cosyp.tistory.com/243


CSRF

  • csrf란? Cross-Site Request Forgery (XSRF) - 우리말로 “사이트 간 요청 위조"라고 함
    • 웹 사이트 취약점 공격의 하나로 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹 사이트에 요청하게 하는 공격을 말한다.
    • 사이트 간 스크립팅(XSS)을 이용한 공격이 “사용자가 특정 웹 사이트를 신용하는 점”을 노린 것이라면, 사이트 간 요청 위조(CSRF)는 “서버가 특정 사용자의 웹 브라우저를 신용하는 상태”를 노린 것이다. 일단 사용자가 웹 사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.

실제 유출 사례

  • XSS와는 달리 CSRF는 JavaScript가 필요하지 않은 공격 방법이다.
    • 대신 img, form 태그 등 다양한 html 태그를 활용한다.

      <form action="http://facebook.com/api/content" method="post"> 
        <input type="hidden" name="body" value="여기 가입하면 돈 10만원 드립니다." />
        <input type="submit" value="Click Me"/>
      </form>
      <script>
        document.forms[0].submit();
      </script>
  • 로그인 CSRF 공격
    • 해커의 계정으로 몰래 로그인을 시켜서, 사용자의 기록이 해커에게 그대로 전달된다.

      <form method="POST" action="http://honest.site/login">
        <input type="text" name="user" value="h4ck3r" />
        <input type="password" name="pass" value="passw0rd" />
      </form>
      <script>
        document.forms[0].submit();
      </script>

CSRF 방어

- 다른 사이트에서 요청을 보내는 공격이므로, 다른 사이트에서 온 요청을 막거나 Origin을 확인하는 작업이 필요하다.
- CORS를 적용
    - 사이트 간 요청을 불가능하게 한다.
- referer 헤더 설정
    - 어디에서 요청이 왔는지 확인할 수 있다.
- Token 검증(Synchronizer Toekn Pattern, CSRF Token)

http://itnews.inews24.com/view/324577

https://velog.io/@shroad1802/CSRF

https://medium.com/@ashifm4/protection-from-cross-site-request-forgery-csrf-9cf4f542e268


XSS와 CSRF의 차이점

  • 공격 위치가 다름
    • XSS : 유저의 클라이언트 PC
      • 유저의 정보를 탈취하여 원하는 작업을 수행할 수 있다.
    • CSRF : 서버
      • 취약한 URL이 수행하는 일만 해낼 수 있다.
  • 특징
    • XSS 공격에 취약한 사이트는 CSRF 공격에도 취약하다.
    • XSS 공격으로 부터 완전히 보호되었더라도 CSRF 공격에 취약할 수 있다.

  • 실험

    • Thymeleaf로 했을 때는 th:text 의 경우 escaping이 자동적으로 진행되어 html 태그가 실행되지 않았지만, th:utext 일 때는 escaping이 진행되지 않아 html 태그가 실행되었음

      • th:text 일 때 (<td*th:text*="${item.orderItems[0].item.name}"></td> )

      • th:utext 일 때 (<td*th:utext*="${item.orderItems[0].item.name}"></td> )

      • React에도 기본적으로 escaping 되는 기능이 적용되어 있다고 함.

      • But 방법이 매우 다양해지면서, 막기 위한 수많은 방법이 고안되었음

      • React에서 XSS 공격을 방지하는 방법 10가지 : https://snyk.io/blog/10-react-security-best-practices/

    • 템플릿 엔진을 사용하지 않을 때는 XSS 공격에 바로 노출되었음

profile
나는 날마다 모든 면에서 점점 더 나아지고 있다.

0개의 댓글