본문 바로가기
Lecture/JSP & Java

[본격 웹보안 Part 1.4] XSS(Cross Site Scripting) 공격이란?

by cusmaker 2012. 11. 15.
반응형

2012/09/19 - [Lecture/Jsp] - [본격 웹보안 Part 1.1] 웹 해킹도 로그인부터

2012/09/19 - [Lecture/Jsp] - [본격 웹보안 Part 1.2] SQL Injection이란 ?

2012/09/20 - [Lecture/Jsp] - [본격 웹보안 Part 1.3] 폼 변조 공격이란?

안녕하세요 cocy입니다. 이번시간에는 XSS(Cross Site Scripting)공격에 대해 알아보겠습니다.

방금 경고창이 뜨셨나요? 공격이라고 하기엔 뭐하지만 티스토리에서 부분적으로 스크립트를 허용하기때문에

스크립트 코드를 삽입해 보았습니다. 이것이 바로 XSS의 예가 되겠습니다.

그런데 여담이지만 Cross Site Scripting인데 CSS가 아니고 XSS인 이유는

디자인에 사용되는 CSS(Cascading Style Sheets)와 이름이 겹치기때문이라고 합니다.

그럼 XSS가 무엇이냐! 이름에 들어있듯이

데이터에 스크립트를 삽입하여 정상적인 기능외의 동작을 하게끔 만드는 해킹 유형입니다.

쉽게 말해서 게시판에 일반 텍스트가 아닌 자바스크립트와 같은 스크립트 코드를 삽입하여,

해당 게시글을 열람하면 삽입한 스크립트가 실행되어 개발자가 고려하지 않은 기능이 작동하게끔 하는것이죠!

고로 이러한 공격 유형은 서버가 아닌 클라이언트를 대상으로 합니다.

그림 1. XSS 공격 형태

이러한 해킹 공격이 가능한 이유는 데이터의 검증에 소홀히 했을때 나타나는데요,

이렇게 되면 스크립트로 가능한 모든 코드가 공격자가 악의적으로 의도한대로 실행 될 수 있는

심각한 취약점 중 하나입니다.

대표적으로 해당 스크립트를 포함한 정보를 조회하는 사용자의 쿠키정보를 빼내오거나,

마찬가지로 조회하는 사용자에게 특정 사이트로 접속하게 하여 해당사이트에서 악성코드를 심을 수도 있습니다.

이메일을 통해 스크립트를 삽입하는 방법도 XSS공격유형중 하나입니다.

그럼 이제 직접 시도해보겠습니다.

로그인을 하시고 게시판을 띄웁니다.

이후 글쓰기에서 다음과 같은 데이터를 넣어보겠습니다.

title:

XSS 테스트

- 스크립트가 아닌 html태그를 삽입하여 소심한 공격을 해보았습니다.

writer :

- 작성자에는 input 태그를 넣어보죠

content :

- 내용은 스크립트를 삽입하여 경고창과 새창을 띄웁니다.

그림 2. 데이터에 스크립트 삽입

결과를 한번 볼까요?

그림 3. 소심한 XSS 공격 결과

스크린샷에선 확인 할 수 없지만 입력후에 리스트에서 게시글을 보니 제목이 왓다리 갓다리 하는걸 보실 수 있습니다.

marquee태그가 동작하고 있다는 것이구요, 작성자의경우 아무것도 없는 버튼이 하나 생긴것을 확인 하실 수 있습니다.

그리고 글을 조회해보면 경고창이 나타나고, 윈도우가 하나 열리지만 크롬에서 팝업창을 차단해버렸네요. (크롬 짱!!)

이와같이 html이나 스크립트가 그대로 동작하는것을 확인 하셨습니다.

이외에도 자바스크립트에 능통하게 되면 위에서 말씀드린대로 쿠키를 가로채거나,

과도하게 메모리를 사용하여 브라우저를 먹통으로 만들 수 할 수 있습니다.

그리고 방금 새창을 띄운것처럼 피싱사이트나, 세션도 가로챌 수 있습니다.

이런 공격적인 방법들은 따로 다루지 않겠습니다. 저희는 막는 입장이니까요!!

그럼 이러한 공격은 어떻게 막아야할까요?

널값 체크, 유효성 검사 뿐만아니라 데이터내에 스크립트 코드가 들어있는지 체크해주면 됩니다.

더쉽게 생각하면 < 기호와 > 기호를 무력화 시키면 됩니다.

이를 체크하는 부분은 유효성검사와 마찬가지로 크게 세군데인데요,

- 먼저 글을 입력받는 클라이언트측에서 자바스크립트를 활용하여 데이터에 대해 스크립트 코드를 제거하거나,

- WAS단에서 JAVA코드를 이용하여 데이터의 검증,

- 마지막으로 데이터베이스 측에서도 이를 걸러낼 수 있습니다.

하지만 첫번째방법의 경우 저번에도 보셨듯이 클라이언트측의 자바스크립트 코드는 사용자에 의해 쉽게 무력화가 가능하기때문에

두번째 방법을 이용하여 데이터를 검증합니다. 데이터베이스에서는 하지 않겠습니다.

자 그럼 입력값을 받는 insert.jsp로 갑니다. 보실부분은 파라미터를 받는 부분입니다.

String content = request.getParameter("content"); // 컨텐츠에 대해서만 보겠습니다.

content = content.replaceAll("<","<"); // 태그를 무력화시킵니다.

content = content.replaceAll(">",">") // 이렇게 바꾸게되면 코드가 실행되지 않고 그대로 출력됩니다.

// 개행이나 문단정렬에 관련된 html태그는 허용해줍니다.

content = content.replaceAll("<p>","

");

content = content.replaceAll("<P>","

");

content = content.replaceAll("<br>","
");

content = content.replaceAll("<BR>","
");

빨간 부분이 추가된 부분입니다. 좀 무식하게 코딩했는데 메서드로 따로빼는 것도 좋은 방법이죠.

replaceAll 메소드는 해당 스트링에서 첫번째 인자로 넘긴 값을 두번째 인자로 바꿔줍니다.

해당 코드를 각 파라미터에 전부 걸어주면 되는 것입니다. 참 귀찮은 일이죠?

스프링 프레임워크에서는 이러한 일련의 작업들을 빈에 셋팅할때 애초에 유효성검사를 추가할 수 있습니다.

그럼 결과를 확인해 보겠습니다.

(컨텐츠에만 걸었으니 컨텐츠에만 스크립트를 넣겠습니다!)

그림 4. 대비후 스크립트 삽입

결과는?

그림 5. 예상범위의 정상출력

보시는 바와같이 스크립트는 실행되지않고 그대로 텍스트로 출력되는것을 보실 수 있습니다.

하지만 p태그와 br는 허용하였기때문에 적용이 되었구요

그럼 이상으로 XSS 공격에 대한 포스팅을 마치도록 하겠습니다.

수고하셨습니다.