XSS

XSS

Cross Site Scripting

공격자가 웹 사이트에 악성 스크립트 코드를 삽입해서 개발자가 의도하지 않은 명령을 실행시키거나 세션 등을 탈취할 수 있는 취약점

게시판이나 웹 메일 등에 스크립트 코드를 삽입하여 개발자가 고려하지 않은 기능이 작동하도록 함

고려하지 않은 기능을 작동하게 하는게 CSRF와 비슷한데...? CSRF

위의 사진처럼 XSS에 취약한 페이지에 스크립트 코드를 삽입하면 별다른 필터링 없이 실행이 됨

=> 여기에 악성 스크립트 코드를 삽입한다면...?

 

XSS 공격은 크게 Reflected XSS, Stored XSS와 DOM Based XSS로 분류

Reflected XSS

공격자가 악성 스크립트를 클라이언트에게 직접 전달하여 공격하는 방식

웹의 지정된 변수를 이용할 때 발생하는 취약점을 이용

 

공격자가 미리 XSS 공격에 취약한 사이트를 탐색하고 XSS 공격을 위한 스크립트를 포함 한 URL을 사용자에게 노출

사용자가 해당 URL을 클릭하는 경우, 취약한 사이트의 서버에 스크립트가 포함된 URL을 통해 요청을 전송하고 웹 서버에서는 해당 스크립트를 포함한 응답을 반환

 

서버에 스크립트를 저장하지 않기 때문에 서버에서 이루어지는 필터링을 피할 수 있는 공격 방식

Stored XSS

공격자가 악성 스크립트를 서버에 저장시킨 다음 클라이언트의 요청/응답 과정을 통해 공격하는 방식

=> 스크립트 서버에 저장하는 행위란 게시글 쓰기 등의 행동을 지칭

 

공격자가 악성 스크립트를 저장한 뒤 사용자가 해당 스크립트가 포함된 요청을 한다면 서버에 저장된 악성 스크립트가 사용자 측에서 동작

 

대부분의 서버에서는 필터링을 하기 때문에 공격을 우회하기는 어렵지만 한번 성공하면 불특정 다수에게 노출되는데다가 관리자 입장에서는 눈치채기 힘듦

=> 피해가 확산될 수 밖에...

DOM Based XSS

사용자의 브라우저가 html 페이지를 분석하여 DOM을 생성할 때 악성 스크립트가 DOM의 일부로 구성되어 생성되는 공격

악성 스크립트가 서버와 상호작용 없이 브라우저 자체에서 실행되는 취약점을 이용한 공격

 

서버의 응답 내에서는 악성 스크립트가 포함되지 않지만 브라우저 응답 페이지에 정상적인 스크립트가 실행되면서 악성 스크립트가 추가되서 실행

 

위의 두 XSS 방식은 서버에서 악성 스크립트의 공격이 이루어지기 때문에 위험 징후를 발견 할 수도

반면 DOM Based XSS는 브라우저에서 바로 공격하기 때문에 취약점 발견이 더 어렵다...

XSS 대처 방법

악성 스크립트가 삽입되는 것을 방지하고 무효화 시키는 과정 필요...!!

입력 값 필터링

악성 스크립트가 삽입되어도 동작하지 않도록 스크립트에 사용되는 특수문자를 &lt, > rkxdms HTML Entity로 치환해서 입력

=> 그럼 스크립트가 실행될 수 없음! 사용자가 <script>를 입력할 경우 서버로는 &lt;script;&gt;로 입력값이 넘어가니까!

WhiteList 필터링

게시판과 같이 html 태그 사용이 필요한 경우에는 사용할 태그를 지정하여 해당 태그만 허용하는 WhiteList 필터링 방식 적용

라이브러리 이용

XSS 필터 관련 외부 라이브러리를 활용하여 악성 스크립트가 삽입되는 것을 방지

• Lucy-XSS-Filter : WhiteList 방식으로 공격을 방어하는 Java 기반의 오픈 소스 라이브러리
• OWASP ESAPI : OWASP에서 제공하는 무료 오픈 소스 라이브러리로 JAVA, PHP 등 다양한 언어 지원

Cookie 보안 설정

Cookie를 생성할 때 HTTP ONLY로 생성하면 JS로 탈취가 불가능