XSS (Cross Site Scripting)

Taesoo Kim·2024년 9월 8일

본 게시물은 기록 및 학습용임을 알립니다.

"script" 가 문제

모든 웹 어플리케이션은 html, js, css로 이루어져 있다.

그리고 모든 웹 페이지들은 html이 로딩되면서 시작된다. (css를 불러온다던가, js를 불러온다던가..)

그런데! html의 가장 취약한 부분이 바로 <script>
인데, html은 <script> 태그를 만나면

그 안에 있는 모든 내용을 스크립트로 인식해 실행해버린다.

즉, 쉽게 말해서 내가 어떤 게시판에 제목에
<script> console.log("Hello World") </script> 라고 적어 놨다면, 실제로 콘솔에 Hello World가 뜰 수 있다는 얘기이다.

이런 취약점에서 시작한 해킹이 XSS가 되겠다.


(만약 댓글중 저런 스크립트가 심어져 있다면..?)

해커가 잘 조작만하면, 클라이언트에서 해커가 원하는 스크립트를 실행 할 수 있다고해서 Cross-Site Script라는 이름이 붙게 되었다.

보통 대표적으로 두가지 시나리오가 있는데, 타겟 사이트에 미리 스크립트를 심어놨다가(서버코드를 조작한다는 말이 아니다. 다른 유저도 볼 수 있는 DB 어딘가에 숨겨놓는 것이다.) 유저가 코드를 마주치게 하는 방법과, 직접 스크립트를 누르게 유도하는 방법이 있다.

Stored XSS

가장 기본적인(?) 방법으로, 사이트에 악성코드를 심는 방법이다. 게시글이나 댓글에 특정 스크립트를 실행하는 코드를 심어놓는다면, 브라우저는 아무 의심없이 그 스크립트를 실행시킨다. 당연히 출처에 상관없이..

https://junhyunny.github.io/information/security/spring-mvc/stored-cross-site-scripting/

Reflected XSS

이건 적극적으로 해커가 악성코드를 보게 만드는 것인데, 주로 이메일을 활용한다고 한다. 이메일에 특정 스크립트를 갖고있고, 타겟 사이트에 접속하게 유도하게 하여 정보를 탈취하는 식이다.

숙련된 조교의 시범

https://junhyunny.github.io/information/security/spring-mvc/reflected-cross-site-scripting/

실제사례

구글 콘솔에서 있던 커맨드 인젝션
http://www.pranav-venkat.com/2016/03/command-injection-which-got-me-6000.html

구글 클라우드에서 테스팅 중에 URL에서 패턴을 발견했다고 한다.
https://console.cloud.google.com/home/dashboard?project="name of the project"

이 패턴을 통해 https://console.cloud.google.com/home/dashboard?project=;sudo rm -rf /"도 된다는 것을 파악했다. (리눅스 기반 커맨드를 클라이언트에서 작동시킨다.)

이 버그 발견으로 6000달러 보상금 받음;;

방어코드

  1. 모든 script 태그를 먼저 필터링 합니다. (애초에 저장이 안되게 하면 되잖슴?)
  2. 저장이 꼭 필요한 서비스는 메타기호를 사용합니다. ("<" -> "<")
  3. CSP 정책을 통해서 출처가 서버인 script만을 실행하게 합니다.

CSRF와는 무엇이 다른가?

Cross-Site Request Forgery의 약어로 사이트 간 요청 위조라는 의미의 취약점으로 사용자의 의지와는 무관하게 공격자가 의도한 행위, 예를 들면 게시글 작성 또는 수정, 삭제 또는 패스워드 변경 등의 요청을 사용자의 권한으로 특정 웹 서버에 요청할 수 있는 취약점을 의미합니다.

쉽게 말해서, 해커가 원하는 방향으로 api 조작 해내는 기술!

XSS와 다른점은, XSS는 클라이언트 즉, 유저를 이용한 해킹 기법이고, CSRF는 쿠키를 사용하는데서 오는 구조적(서버측) 결함이라고한다...(근데 둘다 서버에서 충분히 막을 수 있는거 아닌가 + 일단 api 유출된거부터 노답)

profile
뭔 생각을 해. 그냥 하는 거지 뭐

0개의 댓글