ls-toast

1. 서론

 사실 지난번 포스팅했던 XSS(Cross-Site Scripting) 취약점 찾기 포스팅 전에 먼저 다뤘어야 했는데 깜빡해버려서 지금에서야 올립니다. 사실 크게 어려운 개념도 아니고 워낙 유명해서 이전 포스팅을 통해 XSS를 처음 접해보셨던 분들도 간단한 검색을 통해서 쉽게 개념을 이해하셨을 거라 생각합니다만 그래도 XSS에 대해 소개는 해야 될 것 같습니다 ㅋㅋ

2. XSS의 정의

2-1. XSS의 개념

 XSS(Cross-Site Scripting)은 일반적으로 자바스크립트를 이용한 공격으로 사용자가 입력한 값이 별도의 필터링 없이 서버로 넘어갈 경우 주로 발생합니다. 공격자는 자신이 입력한 값이 필터링 없이 그대로 서버로 넘어가 처리되는 점을 악용하여 공격자가 원하는 임의의 자바스크립트 명령어를 삽입합니다. 그 후 일반 사용자들이 해당 페이지에 접속하게 되면 공격자가 삽입한 임의의 스크립트가 동작하며 사용자의 쿠키 값을 공격자의 서버로 전송한다거나 좀 더 치명적인 악성코드가 삽입되어 있는 사이트로 강제 리다이렉트 되는 등의 피해가 발생할 수 있습니다. 물론, 이번 신천지 홈 페이지 사건 처럼(...) 단순히 경고 문구(?)가 담긴 경고창을 띄우고 끝나는 귀여운 장난(?)으로 끝낼 수 도 있습니다.

2-2. XSS의 종류

 XSS는 크게 Reflected, Stored 2가지 종류로 나뉩니다. Reflected는 사용자에게 악성 스크립트가 포함된 URL을 전송하여 서버에 해당 악성 스크립트를 요청하게 하는 것이고 Stored는 공격자가 게시글이나 댓글 등을 통해 서버에 악성 스크립트를 저장하고 다른 사용자들이 이를 열람하면 해당 스크립트가 동작한다는 것입니다.

3. XSS의 예시

 XSS의 예시는 Reflected XSS의 경우엔 해킹을 공부하는 사람들 사이에서 유명한 데모 사이트(http://demo.testfire.net)를 통해 예시를 들려고 합니다. Stored XSS의 경우엔 예시를 들 수 있는 데모 사이트가 기억나지 않아서 이전에 포스팅했던 XSS(Cross-Site Scripting) 취약점 찾기 를 참고해주시면 될것 같습니다. 예시의 경우 실제 악성 스크립트를 갖고 예시를 들기엔 좀 무리가 있어서 간단하게 Alert창에 현재 접속한 domain 이름이나 쿠키값을 출력하는 정도로 끝내겠습니다.

3-1. Reflected XSS

 먼저 Reflected XSS의 예시입니다. 데모 사이트에 접속을 해보면 우측 상단에 검색창이 존재합니다. 해당 검색창에 내용을 입력하고 검색 버튼을 누르면 search.jsp에 query라는 파라미터 값으로 검색 내용을 넘기는데 해당 부분에 스크립트 내용을 삽입하면 입력한 내용대로 스크립트가 동작하는 것을 확인할 수 있습니다. 이를 이용해 공격자가 query 파라미터 값에 악성 스크립트를 삽입하고 사용자에게 넘긴 후 사용자가 이를 클릭하면 공격자가 의도한 악성 코드가 실행되는 것을 확인할 수 있습니다.

URL : http://demo.testfire.net/search.jsp?query=%3Cscript%3Ealert%28document.domain%29%3C%2Fscript%3E
링크 클릭시 결과

3-2. Stored XSS

XSS(Cross-Site Scripting) 취약점 찾기 를 참고해주세요. 하단의 실사례가 Stored XSS입니다 :)
(추후 Stored XSS가 가능한 데모 사이트를 찾게 되면 수정하도록 하겠습니다.)

4. XSS 방어 기법

 방어기법은 간단합니다. 보통 XSS 공격은 특수 문자가 거의 필수로 들어가기 때문에 preg_replace나 htmlpurifier 등을 통해 특수문자에 대한 필터링을 해준다면 어느 정도 XSS를 방어할 수 있습니다.

0. 서론

 이번에 제가 포스팅할 내용은 워게임이나 데모 사이트가 아닌 실제 상용 사이트에서 XSS, 그중에서 Stored-XSS를 찾는 방법을 소개하고자 합니다. 먼저 본격적인 내용에 앞서 몇가지 말씀드릴 사항이 있습니다.

1. 어떠한 목적이든 사전 허가 없이 취약점을 찾는 것은 불법입니다.
 악의적인 목적이야 당연히 불법입니다. 가끔 단순 호기심, 선의의 목적을 갖고 한다면 괜찮다고 생각하시는 분들이 있는데 불법입니다. 그러니 본 포스팅의 내용을 직접해보고 싶다면 자신이 직접 구축한 사이트나 버그 바운티를 운영 중이고 해당 버그 바운티 범위 내에 있는 사이트들을 이용하거나 사전 허가를 받고 진행하시기 바랍니다.

2. 저는 아직 초보자이며, 해당 포스팅 내용도 기초에 속한 내용입니다.
 저는 저 자신을 아직 입문자 혹은 초보자의 단계에 있다고 생각합니다. 때문에 본 포스팅의 내용도 굉장히 기초적인 방법입니다. 혹시 고급 정보를 생각하고 오셨다면 다른 글을 찾아보시는 걸 추천드립니다. 본 포스팅은 저와 같이 기초 스킬을 배우고 있으면서 버그 바운티를 갓 시작하신 분들을 위해서 작성했습니다.

3. 잘못된 내용에 대한 피드백은 언제나 환영합니다. :)
 앞서 말씀드렸듯이 저는 초보자이며, 내용도 기초적인 내용이다보니 틀린 내용이 담겨있을 수 있습니다. 이에 대한 피드백은 언제나 환영하니 꼭 알려주시면 감사하겠습니다!

1. 대상 선정

 먼저 XSS를 찾으려면 대상부터 선정해야 합니다. 대부분의 해킹 입문자분들이 '이름 있는 회사라면 취약점이 없겠지' 라고 오해하고 계시는데 그렇지 않습니다. 물론 상대적으로 규모가 작은 회사들이 좀 더 취약할 수 있겠습니다만, 사람이 코딩을 하는 이상 회사의 규모와 상관없이 취약점은 존재합니다. 사람은 실수를 하기 때문이죠. 예를 들면 특수문자 필터링을 깜빡한다던가, 개발할 때 써놨던 주석을 안 지웠다던가. 그래서 대상 선정에 굳이 규모 있는 회사들을 제외할 필요가 없습니다! 합법적인 절차를 거친다는 가정하에 어디든 상관없으니 마음 편하게 선정하시면 됩니다! 만약 그게 어렵다면 제가 몇 가지 추천드리겠습니다.

1. 그누보드(Gnuboard)
 그누보드는 오픈소스 CMS(Contents Management System)입니다. 때문에 소스가 모두 공개되어 있고 패치 내역들도 모두 공개되어 있습니다. 본인 서버에 그누보드를 구축하고 여기저기 이런저런 공격들을 시도해보기 딱 좋습니다. 취약점 찾기에 어려움을 느낀다면 소스코드를 직접 분석하면서 찾아봐도 되고 그것도 어렵다면 구버전을 설치하고 패치 내역들을 살펴보면서 이미 제보된 취약점을 직접 재현해보는 것도 좋습니다.

2. 네이버
 네이버는 공식적으로 버그 바운티 프로그램을 운영하고 있습니다. (https://bugbounty.naver.com/ko/) 자세한 내용은 해당 페이지에 들어가서 살펴보시면 됩니다. 워낙 이름 있다보니 취약점이 없을 거라 생각하기 쉽지만 제공하는 서비스가 많다 보니 잘 찾다 보면 툭툭 나오기도 합니다. 특히 새로운 기능이나 서비스 쪽에서는 꼭 1,2개 이상은 나오니까 한번 시도해보는 것도 나쁘지 않습니다.

3. 리디북스
 리디북스 역시 공식적으로 버그 바운티 프로그램을 운영하고 있습니다. (https://ridi.dev/bounty.html) 역시 자세한 내용은 해당 페이지에 들어가서 살펴보시면 됩니다. 버그 바운티 운영 초창기에는 꽤 많은 취약점이 나왔지만 화이트해커분들의 수 많은 관심(?) 덕분에 지금은 찾기가 꽤 어려워졌습니다. 한 가지 제가 느낀 점을 추가하자면 리디북스가 네이버보다 리워드 금액도 높고 첫 제보 시 RIDI PAPER PRO를 준다는 점이 아주 좋습니다! :)

4. 자신이 구축한 사이트
 이건 본 포스팅 주제(실제 상용 사이트에서 XSS 찾기)와 좀 맞지 않은 대상이긴 한데 공부하기엔 꽤 좋습니다. 본인이 직접 사이트를 구축하면서 기본적인 웹 지식을 쌓을 수 있고 그걸 직접 테스트 해보면서 기초적인 보안 기법을 적용해보고 그걸 또 우회해보고 더 좋은 보안 기법을 적용해보고 반복하는 겁니다. 만약 큰 도움이 되지 않는 다고 생각된다면 자신과 뜻이 맞는 친구들과 함께 서로가 구축한 사이트를 서로가 취약점을 찾아보는 것도 괜찮습니다.

2. 공격할 곳 찾기

 대상은 선정했으니 이제 본격적으로 공격할 곳을 찾아야합니다. 공격 시도할 곳을 간단하게 말씀드리면 '값을 넘길 수 있는 곳 어디든' 입니다. 예를 들어 게시판이라고 했을 때 사용자가 서버에 값을 넘길 수 있는 곳은 게시글 제목, 내용, 태그, 첨부파일, 첨부파일명, 닉네임 등이 있는데 이 부분이 전부 공격 시도할 곳이라고 보시면 됩니다. 이 외에도 개발자 도구를 띄워서 <input type="hidden"> 인 친구들도 value 값을 직접 수정해서 넘기는 방법도 있습니다.

3. XSS 찾는 방법

 이제 대상과 공격할 곳은 다 정했으니 공격 시도만 하면 됩니다. XSS 기초를 공부하고 오신 분들이라면 사용자 입력값으로 <script> alert(1) </script> 같은걸 넣고 시도해보실 텐데 틀린 건 아닙니다. 실제로 저 구문이 먹히는 곳도 꽤 있습니다. 다만 워낙 기초적인 공격법이다 보니 안 먹히는 경우가 꽤 많습니다. 물론 제가 소개해드릴 방법도 기초적인 방법이지만.. <script> alert(1) </script>에 비하면 쪼오오끔 더 효율적인 방법입니다. 일단 필요한 게 2가지가 있습니다.

1. 개발자 도구(F12) 콘솔 탭

2. " ' < > [ ] ; : , . / ? ! @ # $ % ^ & * ( ) _ + | \ ` ~ { } (이 외의 특문을 추가해도 괜찮습니다.)

 이제 공격할 사이트로 이동 한 뒤 개발자 도구 콘솔 탭을 열고 2번에 있는 특수문자들을 복사해서 사용자 입력 값 부분(제목, 내용, 댓글 등)에 붙여 넣기 한 뒤 서버에 전송해봅니다.

 전송 후 위의 사진처럼 콘솔에 아무것도 안찍히는 경우라면 특수문자에 대한 필터링이 존재한다는 뜻이고 이럴 경우 제가 설명드리는 기초적인 방법으로는 XSS가 불가능하다고 보시면 됩니다. 그럼 만약에 특수문자에 대한 필터링이 존재하지 않을 경우엔 어떻게 될까요?

 위와 같은 화면을 보실 수 있을겁니다. 위 사진은 제가 실제로 제보한 XSS 취약점 내용입니다. 보시면 SyntaxError와 함께 우측에 회색으로 링크가 걸리는데 해당 링크를 타고 넘어가 보면 아래와 같은 사진이 나옵니다.

 위 처럼 링크를 클릭하면 SyntaxError가 발생한 부분을 보여줍니다. 보시면 제가 입력한 특문이 그대로 들어갔고 맨 앞에 있는 더블 쿼터(")로 인해 title="" 이 되면서 뒷부분이 전부 SyntaxError가 난 것을 볼 수 있습니다. 그렇다면 사용자 입력값을 "; 임의의 코드 로 고친다면 사용자가 입력한 임의의 코드가 실행됩니다. 이걸 악용한다면 공격자는 해당 페이지를 조회한 모든 사용자의 세션 값을 탈취하거나 특정 사이트로 리다이렉트 시키는 등 다양한 공격을 시도할 수 있습니다. 아니면 이번 신천지 사이트 해킹 사건처럼 아래와 같이 alert를 발생시킬 수 도 있겠죠. :)

 글을 다 쓰고 보니 XSS에 대한 내용도 안쓰고 포스팅을 했네요. XSS에 대한 내용은 다음 포스팅 때 다루기로 하겠습니다. 너무 기초적인 방법이라서 실망하신 분들도 많았을 것 같은데.. 의외로 이 방법만 갖고도 취약점이 제법 나오는 편입니다! 저처럼 버그 바운티를 갓 입문하신 분들은 이 방법을 한번 써보시면서 좀 더 고급 스킬들을 익히신다면 아마 나름 쏠쏠한 용돈벌이가 가능하지 않을까 싶습니다 ㅋㅋ 다들 버그 바운티로 쏠쏠한 용돈 벌이에 도전해보세요 :)