XSS CSRF SSRF 차이

XSS CSRF SSRF 차이

XSS(Cross-Site Scripting)

XSS(Cross-Site Scripting)는 악의적인 사용자가 웹사이트에 스크립트를 삽입하여 다른 사용자의 브라우저에서 실행되도록 하는 공격이다. 이 공격은 대개 사용자가 웹사이트에 입력한 정보를 통해 이루어지며, 그 결과 악의적인 스크립트가 실행되어 사용자의 개인정보를 탈취하거나 세션 하이재킹 등의 공격을 수행할 수 있다.

CSRF(Cross-Site-Request Forgery)

CSRF(Cross-Site Request Forgery)는 악의적인 사용자가 인증된 사용자의 권한으로 요청을 보내는 공격이다. 이 공격은 사용자가 이미 인증된 상태에서 악성 웹사이트를 방문하거나 악성 이메일을 열 때 발생할 수 있다. 이 공격은 사용자가 의도하지 않은 동작을 수행하게 만들어, 예를 들어 비밀번호 변경, 계좌이체 등의 작업을 수행하게 만들 수 있다.

SSRF(Server-Side Request Forgery)

애플리케이션에서 서버 측에서 요청을 보내는 기능이 있는 경우, 악의적인 사용자가 이를 이용하여 내부 네트워크에 접근하는 공격이다.

차이점

세 개의 취약점은 공격에 있어 서로 다른 목적을 가진다.

 

XSS는 인증 정보인 세션 및 쿠키 탈취를 목적으로 하는 공격이며, 공격할 사이트의 오리진에서 스크립트를 실행시킨다.

 

CSRF는 이용자가 임의 페이지에 HTTP 요청을 보내는 것을 목적으로 하는 공격이다. 또한 공격자는 악성 스크립트가 포함된 페이지에 접근한 이용자의 권한으로 웹 서비스의 임의 기능을 실행할 수 있다.

 

SSRF(Server-Side Request Forgery)는 주로 시스템의 기밀 정보를 탈취하는 것이 목적이다. 또한 내부 네트워크에서 동작하는 서비스에 대한 정보를 탈취하거나, 내부 네트워크에서 동작하는 서비스에 대한 권한을 악용하여 공격하는 것이 가능해진다.

 

SSRF는 서버 측에서 발생하는 공격으로, 사용자의 브라우저를 이용한 XSS나 CSRF와는 달리, 직접적으로 사용자의 클라이언트 측에서는 인지할 수 없는 공격이다.

 

대응방안

XSS(Cross-Site Scripting) 대응방안:

• 스크립트 코드에 사용되는 특수 문자에 대한 이해와 필터링: 가장 효과적인 방법은 사용자가 입력 가능한 문자만을 정해 놓고 그 문자열이 아닌 경우는 모두 필터링한다. 이 방법은 추가적인 XSS 취약점에 사용되는 특수문자를 애초부터 막을 수 있다는 장점이 있다.

• 중요한 정보 쿠키에 저장하지 않기: 사용자를 식별하기 위해 쿠키에 패스워드와 같은 민감한 정보는 담지 않아야 한다.
• 스크립트 영역에 출력 자제: 이벤트 핸들러 영역에 스크립트가 삽입되는 경우 보호기법들을 우회할 수 있기 때문에 사용자의 입력을 출력하는 것을 최대한 자제해야 한다.
• HTTPOnly 쿠키: HTTPOnly 쿠키를 사용하여 자바스크립트로 쿠키에 접근하지 못하도록 한다.
• CSP(Content Security Policy): CSP를 설정하여 스크립트 실행을 제한한다. CSP 구문은 HTTP 헤더에 추가하여 적용할 수 있는 방법과 meta 태그의 속성으로 정의하는 방법도 있다. CSP 에서는 인라인 코드를 유해하다고 간주한다. 따라서 CSP를 사용할 때는 기본적으로 인라인 코드를 사용할 수 없다.따라서 <script src="alert.js" /> 이런식으로 코드를 src 속성을 통해 로드해야 한다. CSP는 기본적으로 eval함수와 같이 문자열 텍스트를 실행가능한 자바스크립트 코드 형태로 변환하는 매커니즘도 유해하다고 간주한다. 문자열 형태로 입력을 받는 함수의 실행은 모두 차단된다.

CSRF(Cross-Site Request Forgery) 대응방안:

• CSRF 토큰 사용: 사용자의 세션에 임의의 난수값을 저장하고 사용자의 요청마다 해당 난수값을 포함시켜 전송한다. 이후 Back-end에서 요청을 받을 때마다 세션에 저장된 토큰값과 요청 파라미터에서 전달되는 토큰값이 같은지 검증하는 방법. 이 또한 XSS 취약점이 있는 경우 방어가 불가능해질 수 있다.
• Referer 검증: Back-end에서 request의 referer를 확인하여 Domain(saleson.com)이 일치하는지 검증한다. 대부분의 CSRF공격 방어가 가능하다. 하지만 XSS 취약점이 있는 경우 방어가 불가능해질 수 있다.
• Double Submit Cookie 검증: 웹브라우저의 Same Origin 정책으로 인해 자바스크립트에서 타 도메인의 쿠키값을 확인, 수정하지 못한다는 것을 이용한 방어 기법이다. script 단에서 요청시 난수를 생성하여 쿠키에 저장하고 동일한 난수 값을 요청 파라미터에 저장하여 서버에 전송한다. 서버단에서 쿠키의 토큰 값과 파라미터의 토큰값이 일치하는지만 검사하면 되고 서버에 토큰값을 저장할 필요가 없어 세션 검증보다 가볍다. 아래는 샘플 코드이다.

• 사용자 인증 및 권한 검사: 인증된 사용자만 요청을 보낼 수 있도록 하고, 권한이 없는 요청은 거부한다.
• Security Token 사용: Referer 검증이 불가한 환경이라면, Security Token를 활용할 수 있다. 우선 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청 마다 해당 난수 값을 포함 시켜 전송시킨다. 이후 Back-end 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는 지 검증하는 방법이. 이 방법도 결국 같은 도메인 내에 XSS 취약점이 있다면 CSRF 공격에 취약해진다. 아래는 간략한 샘플 코드이다.

SSRF(Server-Side Request Forgery) 대응방안:

• 네트워크 계층 기반의 대응 방안을 수립: SSRF 공격의 구조를 파악해 보면 내부 서버와 연결된 DMZ망의 웹 서버가 사용자와 통신을 하는 과정이 존재하므로 발생하며 이런 상황에서 SSRF 취약점이 존재할 경우 내부 서버의 데이터 탈취 우려가 존재한다. 이때 탈취되는 데이터가 민감하거나 중요한 데이터라면 SSRF 공격의 파급력이 높아지게 된다. 그렇기 때문에 중요한 데이터는 DMZ망의 웹 서버와 연결되지 않은 고립된 내부 서버에 저장하는 것이 중요하다.
• Snort와 같은 침입 모니터링 시스템을 배치하고 SSRF 탐지 정책을 반영: 웹 서버와 내부 서버 사이의 트래픽을 탐지, SSRF 공격을 모니터링 함으로써 SSRF 공격을 실시간으로 탐지하고 차단하여 신속하게 대응할 수 있는 시스템을 구축하는 것도 중요하다. 다음 그림은 SSRF 공격 탐지가 가능한 Snort Rule 중 하나의 예시이다.

• Whitelist 방식의 필터링: 사용자가 입력한 데이터에 대해 허용할 List(URL, Scheme 등)에 속하는 경우에만 처리하고, 속하지 않는 경우에는 에러 페이지로 연결한다.
• Blacklist 방식의 필터링:
  •  192.168.x.x, 10.x.x.x 등의 Private IP가 입력 값으로 주어지면 에러 페이지로 연결
  • Localhost, 127.0.0.1 등의 loopback 주소가 입력 값으로 주어지면 에러 페이지로 연결
  • sftp://, file://, http:// 등 불필요한 schema가 입력 값으로 주어지면 에러 페이지로 연결
  • @, %0a 등의 불필요한 특수문자가 입력 값으로 주어지면 에러 페이지로 연결