XSS, CSRF

웹 어플리케이션 보안 이슈에서 자주 언급되는 공격에 대해 알아보자

Cross-Site Scripting (XSS) 공격

• 약자로는 CSS 가 맞지만 CSS 는 이미 Cascading Style Sheets 의 약자로 사용되고 있어 XSS 라고 한다.

• 공격자가 클라이언트 코드에 악의적인 스크립트를 주입하는 공격이다. 공격자는 사용자를 가장하여, 쿠키와 세션 토큰, 사이트에 민감한 정보들에 접근이 가능해진다

• 실수로 외부로부터 입력되는 파라미터에 대한 적절한 검증을 거치지 않고 페이지 내부에 포함하는 경우 발생

• 대부분의 웹 해킹 공격 기법과 다르게, 사용자를 대상으로 한 공격이다.

• Reflected XSS, Stored XSS, DOM-based XSS 로 나뉜다

  • Stored/Persistent XSS: 공격자가 악성 스크립트를 웹 어플리케이션의 데이터베이스에 저장한 후, 이 스크립트가 웹 페이지에 표시될 때 희생자에게 전달됩니다. 이 유형의 XSS는 브라우저에서 저장된 스크립트가 계속해서 실행되므로, 사용자들이 공격자가 주입한 스크립트를 볼 때마다 공격이 발생합니다.

    • e.g. 댓글에 공격자가 스크립트를 주입하여 실행되는 경우

  • Reflected/Non-Persistent XSS: 악성 스크립트를 링크, 폼, 또는 쿼리 문자열과 같은 웹 어플리케이션에 직접 주입한다. 이 스크립트는 사용자가 특정 링크를 클릭하거나 특정 폼을 제출할 때, 서버를 통해 다시 사용자에게 반환된다.

    • e.g. https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

• DOM 기반 XSS: Document Object Model (DOM)을 조작하여 실행된다. 서버로 전송되는 것이 아니라, 클라이언트 측에서 스크립트를 사용하여 DOM을 조작하거나 변조하는 방식으로 공격이 수행됩니다.

XSS 방어 기법

• 입력 검증 및 이스케이핑: 사용자 입력값을 받을 때 반드시 입력값을 검증하고 안전한 형태로 이스케이핑(escaping)하여 웹 페이지에 표시

• Set-Cookie 응답헤더에 HttpOnly 추가: JavaScript 에서의 document.cookie 에 대한 접근을 차단하는 정책

• 보안 헤더 사용: Content Security Policy (CSP)와 같은 헤더 사용. 실행되는 자바스크립트의 출처 도메인을 제한할 수 있음

  • SOP (Single Origin Policy), CORS (Cross-Origin Resource Sharing) 와의 차이점
    • CORS는 동일 출처 정책(Same Origin Policy)을 도메인에 대해 완화할 수 있도록 허용한다.
      
      예를 들어, 보통 사용자가 example.com 및 example.org에 모두 로그인한 경우, 동일 출처 정책은 example.com이 example.org/current_user/full_user_details에 대한 AJAX 요청을 만들어 응답에 액세스하는 것을 방지한다.
      
      CORS를 사용하면 example.org 는 example.com 원본이 AJAX로 만든 응답을 읽을 수 있도록 정책을 설정할 수 있다.
      
      반면에 CSP(Content Security Policy)는 현재 사이트에서 실행될 내용을 설정하는 정책. 예를 들어, 인라인으로 JavaScript를 실행할 수 있는지 또는 어떤 도메인에서 .js 파일을 로드 할 수 있는지를 지정

Cross-Site Request Fogery (CSRF)

• 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위 (수정, 삭제, 등록 등) 을 특정 웹사이트에 요청하게 하는 공격
• XSS 는 브라우저가 특정 사이트를 신용하는 것을 노린 것인 반면, 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것
• 조건 :
  • 1. 위조 요청을 전송하는 서비스에 희생자가 로그인 상태여야 함
  • 2. 희생자가 공격자가 만든 피싱 사이트에 접속 해야 함

CSRF 방어 기법

• Referrer 검증: 백엔드 단에서 request 의 referrer 를 확인하여 도메인이 일치하는지 검증

  • 도메인 내의 타 페이지에 XSS 취약점이 있는 경우 CSRF 공격에 취약해질 수 있음

    • 더 세밀하게 페이지 단위까지 일치하는지 검증하면 이러한 취약점도 방어 가능

• CSRF Token (Security Token): 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청 마다 해당 난수 값을 포함 시켜 전송. 이후 백엔드에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증

  • 이 방법 또한 페이지에 XSS 취약점이 있을 경우 CSRF 공격에 취약해짐

• 두 방법 모두 XSS 취약점이 발생하면 CSRF 공격에도 취약해질 가능성이 높음

SQL Injection (추후 작성 예정)

Spring JPA 에서 SQL Injection 을 방지하는 방법

• Prepared Statement: 데이터와 쿼리를 따로 보냄
  • e.g.
    db->prepare("SELECT * FROM users where id=?"); $db->execute(data);
  • 쿼리를 하나의 프로그램으로 두고, 데이터를 건내줌