CSRF와 XSS
CSRF(Cross-Site Request Forgery)와 XSS(Cross-Site Scripting)은 웹 애플리케이션 보안과 관련된 취약점이다.
이 두가지는 웹 애플리케이션 보안 이슈에서 가장 자주 언급된다.
CSRF 공격
CSRF(Cross Site Request Forgery, 사이트간 요청변조)는 웹 애플리케이션의 취약점으로, 인증된 사용자가 자신의 의지와 무관하게 악의적인 요청을 보내는 공격이다. 이 공격은 사용자의 브라우저가 인증된 상태로 웹사이트에 접근할 때 발생할 수 있다. 해커는 이를 이용하여 사용자의 계정을 악용하거나 중요한 동작을 수행하도록 요청을 위조할 수 있다.
예를 들어, 사용자가 은행 웹 사이트에 로그인한 상태에서 해커가 제적한 악성 웹 페이지를 방문했다고 가정해보자. 악성 웹 페이지에는 은행 계좌 이채를 위한 요청이 포함되어 있다. 사용자가 악성 웹 페이지를 방문하면 자동으로 이체 요청이 발생하게 되어 해커의 의도대로 동작하게 된다.
이메일을 열어보거나 악성 사이트에 접근했을 때 특정한 요청을 하는 CSRF 스크립트를 실행하는 방식이다.
대응 방안
CSRF(Cross-Site Request Forgery)에 대한 대응 방안은 다음과 같다.
CSRF 토큰 사용
웹 애플리케이션에서 각 사용자에게 고유한 CSRF 토큰을 발급하여, 모든 중요한 요청에 이 토큰을 포함시킨다. 이 토큰은 사용자의 세션과 연결되어 있으며, 요청이 유효한지 검증하는 데 사용된다. 해커가 CSRF 공격을 시도할 때는 해당 사용자의 CSRF 토큰이 필요하므로, 공격을 성공적으로 수행하기 어렵게 만든다.
난수(Random Number)를 서버쪽 사용자의 세션에 저장하고 요청할 때 난수를 CSRF 토큰으로 지정하여 사용자에게 전송한다. 이후 요청부터 토큰이 일치하는지 확인하여 검증한다.
SameSite 쿠키 속성 설정
SameSite 쿠키 속성을 Strict 또는 Lax로 설정하여, 동일 출처에서만 쿠키를 전송하도록 제한할 수 있다. 이를 통해 외부 사이트에서의 요청에 대한 쿠키 포함을 방지할 수 있다.
요청의 Origin 검증
서버는 요청의 Origin을 검증하여, 동일 출처가 아닌 요청에 대해서는 처리를 거부할 수 있다. Origin 검증은 Referrer 헤더를 사용하거나, CSRF 토큰과 함께 검증하는 방식 등으로 구현할 수 있다.
추가적인 사용자 인증
중요한 동작에 대해서는 추가적인 사용자 인증 절차를 요구할 수 있다. 예를 들어, 비밀번호나 2단계 인증 등을 요구하여 사용자의 동의를 받을 수 있다.
HTTP 메서드 검증
서버는 특정한 HTTP 메서드(GET, POST 등)로만 중요한 동작을 허용하도록 구성할 수 있다. 예를 들어, POST 메서드를 통한 요청에 대해서만 중요한 동작을 수행하도록 설정한다.
Referrer 검증 VS Origin 검증
Referrer 검증과 Origin 검증은 유사한 개념이지만 약간의 차이가 있다.
-
Referrer 검증은 요청이 발생한 페이지의 주소(Referrer)를 검증하는 것을 의미한다.
웹 서버는 요청 헤더의 Referrer 필드를 확인하여 요청이 유효한 출처에서 온 것인지 확인할 수 있다. 이 방법은 보안상의 이슈가 있을 수 있으며, Referrer 헤더가 누락될 수도 있다. 따라서 단독으로 사용하기 보다는 다른 검증 방법과 함께 사용하는 것이 좋다. -
요청의 Origin 검증은 요청이 발생한 출처(Origin)를 검증하는 것을 의미한다.
Origin은 프로토콜, 호스트, 포트 번호로 구성되며, 요청이 유효한 출처에서 온 것인지 확인하는 역할을 한다. 이를 통해 동일 출처 이외의 요청을 차단할 수 있다. Origin 검증은 CSRF 토큰과 함께 사용하여 요청의 유효성을 검증하는 데에 일반적으로 사용된다.
요약하면, Referrer 검증은 요청이 발생한 페이지의 주소를 확인하는 것이고, 요청의 Origin 검증은 요청이 발생한 출처를 확인하는 것이다. 두 가지 방법 모두 CSRF 공격을 방지하기 위해 사용되지만, Origin 검증이 더 강력하고 안전한 방법으로 알려져 있다.
XSS 공격
XSS(Cross Site Scripting, 사이트간 스크립팅)는 웹 애플리케이션에서 발생하는 취약점으로, 해커가 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되도록 하는 공격이다. 이를 통해 해커는 사용자의 쿠키, 세션 등의 정보를 탈취하거나 사용자의 브라우저를 제어하여 악성 동작을 수행할 수 있다.
XSS 공격은 주로 사용자 입력을 적절하게 필터링 또는 이스케이프하지 않은 경우 발생할 수 있다. 예를 들어, 웹 애플리케이션에서 사용자의 입력을 그대로 출력하는 경우, 해커가 악성 스크립트를 입력하여 해당 스크립트가 실행되게 할 수 있다.
-
저장 XSS: 웹 사이트에 취약점이 있는 웹 서버에 스크립트를 저장시켜서 해당 웹사이트를 요청하는 사용자로 하여금 스크립트를 실행하게 하는 기법이다.
-
반사 XSS: 검색을 사용할 때 결과가 없으면 브라우저에서 입력한 값을 문서에 포함하여 응답하는데 이를 사용하여 스크립트를 실행하는 기법으로 악성 URL을 배포하여 클릭하도록 유도하는 방법을 사용한다.
-
DOM 기반 XSS: 공격 스크립트가 DOM 생성의 일부로 실행되면서 공격하는 기법으로 반사 XSS와 마찬가지로 악성 URL을 배포하여 클릭하도록 유도한다.
사용자로부터 받은 입력을 제대로 검증하지 않을 때 나타나며 사용자의 정보를 탈취하거나 비정상적인 기능을 실행할 수 있다.
대응 방안
XSS (Cross-Site Scripting) 공격에 대응하기 위해 다음과 같은 대응 방안을 사용할 수 있다.
입력값 검증 및 이스케이프 처리
사용자 입력값을 검증하고, 적절한 이스케이프 처리를 통해 사용자가 입력한 스크립트 코드를 실행하지 못하도록 방지한다. 이스케이프 처리는 입력값을 브라우저에서 안전하게 출력될 수 있는 형태로 변환하는 작업을 말한다.
콘텐츠 보안 정책(Content Security Policy, CSP)
CSP를 사용하여 웹 애플리케이션에서 실행 가능한 리소스의 출처를 제한한다. 이를 통해 외부 스크립트의 로드 및 실행을 제한하여 XSS 공격을 방지할 수 있다.
HTTP Only 쿠키 사용
중요한 정보를 담은 쿠키는 HTTP Only 속성을 설정하여 JavaScript로 접근할 수 없도록 한다. 이를 통해 XSS 공격자가 쿠키를 탈취하여 세션을 위장하는 것을 방지할 수 있다.
내용 콘텐츠 필터링
사용자가 입력한 내용에 대해 허용되지 않은 태그나 스크립트를 필터링하는 방법을 사용한다. 이를 통해 악성 스크립트의 삽입을 방지할 수 있다.
세션 관리
적절한 세션 관리를 통해 인증된 사용자만이 웹 애플리케이션에 접근할 수 있도록 한다. XSS 공격에 의해 세션 탈취가 발생하더라도 유효한 세션을 갖지 않으면 공격자는 해당 세션으로 접근할 수 없다.
사용자 교육
사용자에게 안전한 웹 사용법을 교육하고, 알려진 피싱 공격이나 악성 사이트에 접근하지 않도록 유도한다.
