UNION

Union은 SQL에서 서로 다른 SELECT의 결과를 하나의 결과로 합쳐주는 역할을 한다. 

예를 들어 아래와 같은 데이터를 가지는 테이블이 존재한다고 하자

tbl_member

tbl_games

게임을 조회하는 화면에서 아래와 같은 쿼리를 사용할 것으로 생각된다.

SELECT NAME, COMPANY, PRICE FROM tbl_games WHERE NAME LIKE '%디아블로%'

그럼 결과는 

디아블로, 블리자드, 50,000이라는 결과를 반환한다.

해당 쿼리에 UNION을 사용하여 tbl_member의 데이터를 추출하려면

SELECT NAME, COMPANY, PRICE FROM tbl_games WHERE NAME LIKE '%디아블로%' 
UNION
SELECT ID, PASS, CREATE_DT FROM tbl_member

쿼리를 만들면 된다.

이를 위해 입력값에 들어갈 데이터는

'%디아블로%' UNION SELECT ID, PASS, CREATE_DT FROM tbl_member WHERE '1%'='1%' 

이다

LIKE 검색으로 %가 들어있기 때문에 마지막에 '1%'='1%'를 추가하였다.

위와같이 UNION은 선행하는 컬럼의 개수와 후행하는 컬럼의 개수가 동일해야한다.

ORDER BY

ORDER BY는 데이터의 정렬을 하는 SQL 구문이다. 

SELECT ID, PASS, CREATE_DT FROM tbl_member ORDER BY ID

위와같은 구문이 실행된다면 결과는 ID가 오름차순으로 정렬된 데이터를 반환한다.

그러나 ORDER BY구문에 한가지 특징이 있는데 SELECT 구문의 INDEX(순서)를 넣을 수 있다는 것이다.

이를 사용하여 UNION에 사용하는 컬럼의 개수를 구할 수 있다.

SELECT ID, PASS, CREATE_DT FROM tbl_member ORDER BY 1

연습

위와같이 데이터를 조회 할수 있는 웹이 존재한다.

1. SQL Injection이 동작하는지 확인해보자

검색을 해보니 like 검색으로 동작하는 것 같다 즉 조건문은 아래와 같을 것이다

WHERE ID LIKE '%입력데이터%'

Ad%'  '1%'='1 로 입력해서 데이터가 나오는 것을 확인 했으며 이를 통해 SQL Injection이 동작 하는 것을 알 수 있다.

2. 컬럼 개수 찾기

order by를 사용하여 선행 되는 select의 컬램 개수를 찾아보자 

order by 2를 사용하니 level의 컬럼이 오름차순으로 정렬되었다.

이와같은 방법으로 숫자를 늘려가니 5에서 데이터의 결과가 없었다 즉 선행되는 컬럼의 개수는 4개이다.

3. 컬럼의 위치 찾기

현재는 4개의 컬럼을사용하고 4개의 컬럼 정보가 모두 화면에 나오지만 선행하는 SELECT의 컬럼이 10개고 화면에 4개만 출력된다면 출력되는 컬럼의 위치를 찾아야한다.

그 방법은 union으로 데이터를 넣고 출력해보는 것

%' union select 1, 2, 3, 4 from dual#

1,2,3,4 모두 화면에 표기 되는 것을 알 수 있다.

4. DB확인

어떠한 DB(일부 DB에서는 스키마라고 한다.)

%' union select 1, database(), 3, 4 from dual# 를 통해 DB명을 확인

sqli_1이라는 DB를 사용하고 있음을 알 수 있다.

5. 테이블 확인

information_shcema라는 곳에 Table들의 이름이 있다.

%' union select table_name, 1, 2, 3 from information_schema.`TABLES`# 

구문을 사용하여 테이블 명들을 가져올 수 있다.

해당 테이블 중 내가 사용할 테이블은 flag_table이다.

6. 컬럼 이름 확인

조회할 DB와 Table을 찾았으니 이제 어떠한 컬럼을 가지고 있는지 확인해보자

컬럼정보는 INFORMATION_SCHEMA.COLUMNS에 있으며 COLUMN_NAME을 조회하면된다.

 %' union select COLUMN_NAME, 1, 2, 3 from information_schema.COLUMNS where TABLE_SCHEMA = 'sqli_1'and TABLE_NAME   = 'flag_table' #

7. 데이터 추출

이제 위의 정보를 기반으로 flag_table의 flag컬럼을 조회해보자

SQL 삽입은 응용 프로그램 보안 상의 허점을 의도적으로 이용해, 악의적인 SQL문을 실행되게 함으로써 데이터베이스를 비정상적으로 조작하는 코드 인젝션 공격 방법이다. - 위키백과 -

즉 내가 원하는 쿼리를 실행하도록 하는 공격방법이다.

예시로 로그인 로직의 sql이 다음과 같다고 하자

SELECT COUNT(*) FROM MEMBER WHERE ID = '{$ID}' AND PW ='${PW}'

SQL Injection에 대해 조치가 없다면  ID값에  doldol'# 혹은 doldol;-- 라고 입력하면 실제 사용되는 쿼리는 다음과 같아진다.

SELECT COUNT(*) FROM MEMBER WHERE ID = 'doldol' #' AND PW ='${PW}'

즉 doldol이라는 아이디를 가진 사용자가 있다면 ID만으로 로그인이 된다. ID이후의 쿼리는 주석으로 처리되기 때문이다.

이러한 SQL Injection을 막는 방법은 여러가지 방법이 있다.

1. java에서의 mybatis같은 SQL Mapper 의 사용으로 입력 받는 값이 쿼리가 아닌 문자열로 인식하도록 할 수 있다.

  - 단 mybatis에서도 #{} 를 사용해야자 ${}를 사용하게 된다면 위와같은 SQL Injection에 취약하다.

2. 입력받은 문자열의 공백을 모두 trim 처리한다. SQL은 띄어쓰기로 구문을 분석하기 때문에 입력받은 값들이 SQL일지라도 띄어쓰기가 되어 있지 않다면 하나의 문법으로 인식하기 때문에 문법에러(syntaxerror invalid syntax)를 반환할 것이다.

3. 특수문자들을 치환한다. 이를 이스케이핑이라고 부르며 SQL에서의 특수한역할을 하는 특수문자들을 다른 방법으로 치환하고 다시 사용할 때 역치환하는 방식으로 사용한다.

이외에도 일부 사이트에서 비밀번호 입력 시 사용 할 수 없는 특수 문자가 있기도 하다 #, $ 등등

일부 특수문자나 단어를 입력할 수 없도록 하는 방법도 있을 수 있을 것이다.

Burp Suitte(버프 슈트)

Burp Suite는 웹 애플리케이션의 침투 테스트에 사용되는 소프트웨어 보안 애플리케이션입니다.

-위키백과-

버프 슈트는 proxy의 형태로 웹 요청과 응답을 모니터링 및 변조할 수 있으며 그 외에도 다양한 유틸리티 기능이 있는 소프트웨어이다.

프록시 서버(영어: proxy server, 문화어: 대리봉사기)는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다.

-위키백과 - 

즉 내 pc에서 요청을 proxy로 전달하고 proxy는 다시 원래의 목적지로 전달한다.

이러한 과정에서 요청과 응답을 변조 및 모니터링을 할 수 있는 구조다.

버프 슈트 사용법

상단의 Open browser 클릭 후 intercept is off를 클릭하여 -> on으로 변경한다.

이후 특정 url(스크린샷에서는 https://portswigger.net로 연결함) httpRequest를 볼 수 있다.

현재의 상태는 request를 요청하기 전  proxy에서 일시 정지 상태로 상단의 Forward를 눌러 요청을 본래의 요청지로 전달 할 수 있으며 하단의 Raw의 내용을 수정하여 전달 할 수 있다.

http history 탭에서 오고간 데이터를 확인할 수 있다.

상단의 Decoder탭으로가면 Web에서 자주 사용되는 인코딩 처리를 복호화 할 수 있다.

Base63, Url인코딩등 다양한 인코딩 디코딩을 테스트 할 수 있으며 위와같이 단계적 인코딩 디코딩도 가능하다.

그 외에도 두 요청, 응답을 비교하는 compare 특정 요청을 변경하여 반복적으로 보낼 수 있는 repeat탭도 존재한다.

식별/인증

식별: 수 많은 사용자 데이터 중 1개의 사용자를 특정(ID)
인증: 식별한 사용자가 실제 그 사용자가 맞는지 확인(PW)

식별정보: 로그인에서 ID가 식별정보이며 식별정보는 특정 1명의 사용자를 찾을 수 있어야하므로 유니크해야 한다.
인증정보: 로그인 시도한 사용자가 정말 그 사용자인지 확인하기 위해 사용자만 알 수 있는 값을 받아야한다 (PW)

Hash

Hash는 단방향 암호화 로직으로 (A ===HASH 처리 ===> B) 가능하지만 ( A <========= B)가 불가능하다
이러한 특징을 가지고 있기 때문에 BD가 탈취되어도 평문을 알 수 없다.

로그인 시 입력받은 비밀번호를 Hash처리하여 DB에 저장된 값과 비교만 하면되기 때문에 사용자의 비밀번호를 알 필요가 없다.

로그인 로직 방법들

1. 식별/인증 동시처리: DB에서 동시에 식별정보 and 인증정보를 조회한다.
2. 식별/인증 별도처리: DB에서 식별정보를 조회 후 Back-End의 if문으로 확인한다.
3. 식별/인증 동시처리 + Hash : DB에 입력된 PW는 해쉬 처리가 되어 있으며 쿼리의 조건문에도 해쉬처리된 데이터로 조회한다.
4. 식별/인증 별도처리 + Hash : DB에 입력된 PW는 해쉬 처리가 되어 있으며 비교는 Back-End의 로직에서 확인한다.

로그인의 유지

• 쿠키: Client에 저장되며 데이터 요청시 전달하여 사용 Ex) setcookie(useId, 김만기)
  단 클라이언트에 저장되는 값으로 변조가 쉽다.
• 세션: 쿠키와 다르게 데이터의 값은 Server의 파일로 저장되며 Client는 Cookie에 SessionId를 보내어 사용자를 특정하고 해당 사용자의 정보를 확인 할 있다.

HTTP의 특징

Stateless

Http는 무상태성(Stateless)로 Server와 Client가 항시 연결되어 있는 상태가 아니다. 요청한 데이터에 대한 응답을 전달하게 되면 연결이 끊어지는 방식으로 이전에 어떠한 요청을 했는지 알 수 없다.

이러한 Stateless의 특성을 가지고 있기 때문에 Cookie, Session_id 혹은 JWT와 같은 로그인 한 사용자라는 것을 증명 할 수 있는 데이터를 요청시마다 전달해야한다.