[ XSS ] Cross Site Scripting

d4r6j·2025년 6월 14일
HACK

hack

목록 보기
8/11
post-thumbnail

Review

SQL Injection

SQL Query 를 삽입.

  • SQL Injection Point
  • 'and '1'='1 > 웹 페이지 에서 > SQL 질의 문을 사용하는 것.
  • 서버 측 SQL 질의 문을 추론 후 공격을 시도.
  • 이 웹페이지가 어떻게 만들어 졌는지 청사진이 그려져야 한다.
    • 이 parameter 는 어떻게 사용하고 있구나, 어느 포인트에 들어가고 있구나.
  • SQL Query 가 사용되는 곳 에서 테스트 해야 한다.
    • DB 에 데이터를 가져오는 곳
    • DB 에 데이터를 저장하는 곳
    • 회원 가입, login page 도 될 수 있고
    • id 중복 체크도 될 수 있고
    • 게시판 들어 갔을 때 글 리스트 되는 곳
  • 파라미터 구성을 생각해보자.
  • 파라미터들은 서버에서 어떻게 만들어 지는지 생각 후 시작.
  • 데이터를 넣어서 전달, parameter 에 이 데이터가 포함 되어서 나가고 있구나, 서버에서 어떻게 처리되고 있는 지를 생각을 해봐야 한다.
  • 네이버 예시. parameter 를 보자.
    https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=d4r6j&ackey=ar7ucc0o
    • search.naver.com 이라는 도메인이 있고
    • search.naver 라는 페이지가 있다.
    • parameter 의 종류
      • where=nexearch
      • sm=top_hty
      • fbm=0
      • ie=utf8
      • query=d4r6j
      • ackey=ar7ucc0o

query 파라미터가 들어가고, 전송되고 있다. full SQL Query 는 몰라도 추론은 해보자.
select 문을 사용할 것인데,

  1. 특정 데이터가 나오는 것 보니 where 문이 나온다.

  2. 검색 keyword 라는 column 이 있고 like 절이 있다.

  3. 입력한 데이터가 like 구문에 들어갈 것이다.

    SELECT ~~ FROM ~~
    WHERE (keyword) LIKE ‘%__%’

  • 내가 필요로 하는 parameter 를 찾고,
  • 그것이 어떠한 쿼리를 통해서 어디에 들어갈 것인지,
  • 여기에 맞춰서 payload 를 짜고 테스트를 해보는 것.

게시판을 예시로 본다고 가정하고, parameter 를
boardRead.php?boardIdx=65 으로 설정해서 넣어보자.

boardRead.php?boardIdx=65' and '1'='1

로만 승부하지 말자.

  • 이 parameter 가 서버에서 어떻게 들어가고 있는지
    • 게시글을 가져와야 하므로 SELECT 문이 들어갈 것이라 추측.
    • Where 문이 들어갈 것인데 index 가 들어가는데 숫자 or 문자열 추측.
      where idx=65 or idx=64+1.
      where idx='65'

숫자인데 문자열 안의 데이터가 아니라면 연산이 되므로 SQL injection point 가 된다.

  • 숫자라면 65 and 1=1
  • 문자라면 65' and '1'='1
  • idx 에서 64+1 을 했을 때 65 가 되서 먹히게 되는 경우 는 숫자로 판단, 문자면 에러.

65 AND 1=1 은 안되는데 64+1 이 될 때도 있는데...

  1. 공백 필터링 당할 수 있어서 65/**/AND/**/1=1
  2. and → aNd 로 필터링을 우회해 보는 것.
  3. 서버 측 SQL 질의문을 추론하고 공격 시도.

  • SQL Injection
    공격자가 실행하고 싶은 SQL Query를 삽입하는 공격.

    • DB 를 털고 싶다면? : SELECT * FROM MEMBER (회원 정보 빼오기)
    • SQL Query 를 바꿔서 Login 을 우회하고 싶다면 그에 맞는 Query 를 삽입.

  • SQL Injection 방법

    • SQL 질의문 데이터 화면에 출력되는 경우. ⇒ Union SQL Injection
    • SQL Error 메시지가 출력 ⇒ Error Based SQL Injection
    • Blind SQLi
      ⇒ SELECT * from member
      ⇒ 참과 거짓 조건을 삽입해서 한 글자 씩 추출하고 물어보면서 응답 결과가 다르다를 이용.

  • SQL Injection 의 대응 방안

    • Prepared Statement 를 사용하는 것
    • 예외 : order by, (column, table) 부분 등은 Prepared Statement 적용 못함.
    • White List 기준의 필터링을 해주어야 한다.

  • 모의 해킹 할 때 주의할 점.

    • DB 를 건드리는 작업은 조심히 해야 한다.
    • insert, delete, update 구문은 왠만 하면 진행하지 않는다.
    • or 금지. 회원 가입, 마이 페이지 등에서 delete 로 1=1 사용하여 모두 날리면 안됨.
    • 주석 남용 금지.
    • 데이터 변조 금지.

  • SQL Injection Payload

    sotingAd=,(case+when+ascii(substr((select+user+from+dual),1,1))=0+then+1+else+(1/0)+end)

    sortingAd : 여기에 들어가는 payload 는 어디에 들어가는지 생각해 봐야 한다. 아마도 ORDER BY !!

    sortingAd=,(
    case when ascii(
        substr(
            (select+user+from+dual),1,1
        )
    )=0 then 1 else (1/0) end
)

# comma 가 들어가는 이유는, order by title [asc/desc] (,) 위치에 들어가서 comma 가 들어간다. 
# 참이면 1 거짓이면 논리 error 로 유도. Oracle 에서는 논리 error. 1/0 은 MySQL 에서는 Syntax error.

    Time Based Blind Sql Injection

       sortingAd=ASC;if+substring((select%20user_name()),1,1)=%27a%27+waitfor+delay+%270:0:1%27&endDt=&keyword=
    sortingAd=ASC; if substring(
    (
        select%20user_name()
    )
    ,1,1
)=%27a%27 waitfor delay %270:0:1%27&endDt=&keyword=
    • ; 으로 문단을 끊고,
    • username() 의 select 가 `_a 로 참이면waitfor delay`

    → 참인 경우에는 5초 있다가 응답해라.
    → 거짓인 경우에는 바로 응답해라.

    이런 식으로 해서 서버에서 전달되는 응답시간을 가지고 SQL Injection 을 하는 것.

    → 실제 업무에서 막 다른 길이 될 때는 어쩔 수 없지만, DB 에 sleep 을 가해져 자체 부담이 들어간다.

  • filtering
    사이트 들 마다 여러 가지 filtering 이 적용 되어 있을 수 있다. 공백 필터링.

    : and 1 = 1

    공백 제거 후 옮겨야 하는데 : and1=1 로 하면 오류가 되니 : and/**/1=1, and%0a1=1, and(1=1) 등등

XSS

Cross Site Scripting

→ 클라이언트 측 (이용자) 스크립트를 삽입.

XSS 의 피해자 = 이용자. ( 클라이언트 )

= 이용자 브라우져에서 실행. 클라이언트 측 스크립트. ( HTML, CSS, Javascript )

  • <input> 이라고 tag 를 넣으면 browser 가 이것을 해석하고 화면에 그려준다.
  • CSS 로 input 상자를 띄워주기도 하고 움직이기도 하고 색을 칠해주기도 한다.
  • XSS 의 취약점이 어떤 위험을 가져다 줄지, 그 취약점이 나온 위치마다 다를 수 있다. 위험한 이유가 중요.

이런 스크립트를 삽입하는 공격이라고 해석하면 된다.

그럼 악성 스크립트는 어디서 실행될까?

→ 이용자의 browser 에서 실행된다.

  • 공격 방식 : 크사 (XSS) 는 클라이언트 측 스크립트를 삽입할 것.
  • 목적 : 현 웹사이트를 방문하는 컴퓨터 browser 가 실행할 악성 스크립트를 삽입하여 이용자의 브라우저에서 실행되게 만드는 것.
  1. browser 에 접속하는 log 를 빼온다.
  2. session 을 빼온다.
  3. browser 에서 원하는 코드를 실행하게 하는 것.

등을 할 수 있다.

어떻게 스크립트를 삽입할 것인가? 크게 두 가지를 다뤄보자.

스크립트 삽입 : 삽입하여 이용자의 browser 에서 실행되게 만드는 공격. ( HTML, CSS, Javascript )

Stored XSS

서버에 스크립트를 저장.

→ 저장하는 곳, 출력 되는 곳이 다를 수 있다.

악성 스크립트를 서버에 저장해 두고, 이 사이트를 접속하는 사람들이 이 payload 를 가져가게 만드는 것.

  • 서버에 데이터를 기록하는 기능에 무엇이 있는지 생각해보자.

    • 회원 가입, 게시판 등 글 작성 등 서버에 저장하는데, 악성 스크립트 일 수 있다.
    • 모든 데이터를 저장하는 곳에서 크사가 일어나는 것이 아니다.
    • 데이터가 저장되고 그 데이터가 출력 되는 곳에 크사 취약점이 일어난다.

  • 게시판 글 작성.

    • Browser 가 아닌 Burp-Suite 에서 테스트 해봄.
    • 게시판 글을 작성할 때, 넘어가는 글을 보고 어떤 데이터가 날라가고 있구나 를 먼저 확인함.
    • 예를 들어 d4r6j 이라는 데이터를 먼저 썼으면, 화면에 찍히는 것도 Burp-Suite 에서 봐야함.
    • 서버 응답에 d4r6j 가 찍혀 오는 지를 돌아다니면서 찾아보고 있으면 거기서 크사를 확인 가능.
STEP 1: 어떤 데이터를 서버에 저장하면 
STEP 2: 그 데이터가 화면에 나와야 하고
STEP 3: web browser 에서 나오는 것이 아닌 서버의 응답에서 나와야 한다.

  1. 어떤 데이터를 저장한다.

  2. 그리고 위 데이터가 화면에 나와야 한다. (크사를 적용해 볼 수 있다 : 취약점을 확인해 봐야 한다.)

  3. 서버의 응답에서 나와야 한다.

    • 화면에 나온다는 것은 웹 브라우저 에서 나온다는 것이 아니다.

따라서 취약점 포인트가 너무 많다.

  1. 작성한 데이터가 화면에 응답 되는거 확인.

  2. 특수문자 체크 : 스크립트를 삽입할 예정.
    → HTML 특수 문자를 사용할 수 있는지 체크 <'"> 이 4가지 를 확인하면 된다.

  3. 저장하는 페이지에서 위의 특수 문자를 넣어보면 된다.

  4. 응답 되는 곳이 다르므로, 확인 되는 곳으로 찾아 가서 확인한다.

    <'"> 가 모두 다 있다. 따라서 전부 사용 가능하다.

  5. javascript 를 삽입할 수 있다.

    대표적으로 client HTML 문법에서 JS 를 가장 많이 사용한다.
    일반적으로 악성코드가 들어가지만, 알림을 위해서, alert, prompt, confirm, console.log, onbutton 등을 사용하여 알림을 준다.

  • 요청 시

  • 응답 시

    응답에 확인 되었다. 그리고 전혀 다른 브라우저로 테스트 시에

    Store XSS 가 확인 되었다. XSS 크사 포인트도 중요하지만 JS 개발도 중요하다.

Reflected XSS

서버의 에코 기능을 이용. ( 반사 )

→ 데이터를 삽입 하는 곳, 출력하는 곳이 같다. 그리고 서버에서 튕겨져 나온 데이터를 이용할 것.

  • 파라미터로 데이터를 날리면 데이터가 에코처럼 그대로 응답에 박혀오는 경우가 있다.
  • 이것을 이용해서 스크립트를 삽입한다.
  • 파라미터 데이터가 서버 응답에 삽입되어 오는 곳.

아이디 중복 체크를 생각해보면

  • d4r6j → d4r6j 는 사용할 수 있는 아이디 입니다.
  • test → test 는 사용할 수 없는 아이디 입니다.

내가 입력한 데이터를 그대로 이야기 해주는 곳이 있다.

  1. 파라미터 데이터가 서버 응답에서 삽입되어 오는지를 확인한다.

    XSS-Reflected 에서 test 라고 하고 Submit 을 하면 test 가 나오게 된다.

  • burp-suit 에서 확인해보자.

    • 파라미터에 test 라는 글자가 요청 되는 것을 확인할 수 있다.

    • 응답에 있는지 확인해보자.

      이 의미는 현재의 검색 창 뿐만 아니라 모든 parameter 에서 확인해 보면 좋다.

    • 새로운 테스트 요청 d4r6j

    • 응답

      내가 입력한 데이터를 요청하여 응답에 나오면 된다. Reflected XSS 의 특징이다.

      Stored XSS 는 내가 script 를 삽입하는 요청과 화면에 출력되는 곳이 다를 수 있다.

  1. 특수 문자 체크 <'"> 를 한다.

  • 요청

  • 응답

  1. script alert 을 넣는다.

  • 요청

  • 응답

    이 url 을 전달하면 script 를 포함해서 넘겨준다. 따라서 copy url 을 하고 응답을 하면 alert 이 뜬다.

Reflected XSS 는 Link 를 전달 하면서 공격하는 기법이다.
→ payload 는 Link 를 클릭 해서 XSS 공격을 유발할 것이므로 GET method 를 사용할 것.
→ post method 는 parameter 가 넣어지지 않으므로 공격에 활용할 수가 없다.

profile
d4r6j
이전 포스트

[ SQLi ] Find SQL Injection point

다음 포스트

[ XSS ] Exploiting XSS

0개의 댓글