간단한 실습을 하면서 SQL Injection으로 인증우회하는 것을 배웠는 데
직접 챌린지를 통해 해보겠습니다.
챌린지 1. normaltic1 계정으로 로그인 하기
저번 시간에 어떻게하면 SQL Injection을 사용하는지 알았으니 한번 써보자!!
오잉??? 로그인이 실패하네요... 주석이 안되나?? 생각해볼 수 있습니다. 하지만 우리에겐 다른 방법이 하나 더 있습니다.
휴.. 다행히 이 방법이 먹히네요.
챌린지 2. normaltic2 계정으로 로그인하기
오!! 주석을 사용하니 바로 로그인이 되었습니다.
챌린지 3. admin 계정으로 로그인하기
우리가 배운 방법이 안되네요...
이번 챌린지에서 알아야 할 것이 있습니다. 바로 앞에서 했던 것은 우리가 SQL Injection 이 취약점이라 생각해서 아이디를 조작해 나름 결과가 나올 것 같은 쿼리를 만드는 것이었습니다.
하지만, 실제로는 이 페이지가 어떻게 작동하는 지 우리는 모릅니다. 페이지가 SQL Inejction에 대한 취약점은 있는지! SQL Injection이 가능해도 필터링이 있는지! 도 모르면서 SQL Injection을 실시하고 있었던 것이지요.
그렇기 때문에 일단 먼저 페이지를 우리가 사용해보고 페이지에 대한 정보를 최대한 모아야합니다. 실제로는 회원가입도 해보고 가입한 아이디로 로그인 하는 것입니다.
어쩐지.. 모든 페이지마다 아이디: doldol. 비밀번호: dol1234 라는 계정이 있다고 알려줬었네요.
이제 직접 페이지를 이용해보며 페이지의 정보를 버프 스위트를 사용해서 확인해보겠습니다.
일단 SQL Injection이 가능한 페이지인지 먼저 알아보겠습니다.
우리가 아는 로그인 로직을 보면 식별과 인증을 동시에 하는 방법! 식별과 인증을 분리해서 하는 방법이 있었습니다.
select * from users where id='$userId' and password='$userPw'
// 값이 있으면 로그인 성공
select * from users where id='$userId'
// 결과의 비밀번호와 입력받은 비밀번호가 같으면 로그인 성공두 방법을 보면 입력한 비밀번호가 실별/인증 분리에는 쿼리를 만드는 데 포함하지 않지만, 아이디는 둘 다 입력한 값으로 쿼리를 만드는 것을 확인할 수 있습니다.
그렇기 때문에 아이디를 통해 확인해볼 것입니다.
아마?? 어느 페이지든 아이디를 통해 그 사람이 누구인지 확인해야하기 때문에 입력한 아이디로 쿼리문을 만들 것입니다.
그럼 이제 실제로 SQLI 가 작동하는 지 확인해봐야겠죠! 이때 사용할 수 있는 것이 doldol' and '1'='1 을 사용하는 것입니다.
이유는 바로 원래 doldol이라는 아이디를 입력했는데! 로그인이 성공했습니다.
만약, doldol' and '1'='1를 입력해서 우리가 입력한 값으로 SQL 쿼리문을 만든다면
select * from users id='doldol' and '1'='1' and password='dol1234'이렇게 만들어 지기 때문에 id가 doldol이라는 데이터가 있으니 참, 1=1이니 참, doldol의 비밀번호가 dol1234이기 때문에 뒤에 것도 참으로 정상적으로 doldol의 데이터를 가져와야합니다.
하지만 SQL Injection이 불가능하다면 우리가 입력한 값이 필터링 되어 SQL 에러가 나거나 혹은 우리가 입력한 아이디를 하나의 문자열로 생각해 아이디가 doldol' and '1'='1 인 데이터를 찾을 수도 있습니다.
즉, SQL Injection이 불가능하다면 doldol' and '1'='1로 입력 시 로그인이 실패하게 될 것입니다.
userId 부분을 doldol' and '1'='1 로 로그인을 하니 로그인이 성공하네요.
그럼 SQL Injection은 가능한 페이지라고 할 수 있습니다.
여기서 중요한 점은 페이지가 어떤 로그인 로직을 사용하는 지 모르기 때문에 우리는 이렇게 로그인을 실시할 것이다 추측을 해야합니다.
추측한 로그인로직을 통해 어떻게 SQL 쿼리문을 조작할 수 있을 까 생각해야합니다.
또 다른 정보를 확인해보겠습니다. 이때 사용하기 좋은 것이 history입니다.
우리가 정상적으로 페이지를 이용하면서 주고받은 요청,응답을 확인하는 것입니다.
음.. 보니까
request
post로 login.php를 요청하고 있으며 아이디와 비밀번호 입력한 값을 UserId, Password에 넣어 요청을 보내는 것 같습니다.
response
응답으로 302!!는 redirect한 다는 뜻으로 다른 페이지로 이동해라고 알려주는 것입니다. 그렇기 때문에 302 응답번호라면 헤더 부분에 location을 확인해야합니다.
index.php로 가라고 되어있네요!! 즉, 로그인이 성공하면 index.php로 이동시켜주는 것 같습니다.
또한, 헤더 부분에 set-cookie가 있네요 이것은 쿠키를 지정해주는 것인데 loginUser이라는 키에 값은 doldol을 넣어서 쿠키를 설정해주네요.
그럼 index.php를 확인해봐야겠죠
request
GET 메소드로 index.php 를 요청하는데 쿠키에 loginUser와 session, phpsessid 를 포함하여 요청을 보냅니다.
response
로그인에 성공하니 200 응답코드로 정상적으로 해당 페이지를 응답합니다.
여기서 보니까.. 쿠키의 loginUser 값으로 로그인을 결정하는 것 같습니다. 그럼 이 부분을 admin으로 바꾸면 admin으로 로그인이 될 것 같습니다.
역시나 loginUser를 admin으로 바꿔주니 로그인이 되네요!!!
intercept 기능으로 요청을 잡아 수정해주었습니다... 이렇게 SQLI 말고도 쿠키 변조를 통해서 인증을 우회할 수 있습니다.
챌린지 4. 최종 단계까지 가기
다음으로 넘어가기 위해선 관리자의 비밀번호가 필요하네요.. 아마 여기가 문제인것 같습니다. 일단 바로 요청,응답을 확인해볼까요?
여기서 확인을 누르면 step2.php로 이동을 하는 것 같네요 step2.php도 확인해봅시다.
여기서 비밀번호를 입력하면 다음 단계로 넘어가는 것 같습니다.
또 다른 인증 우회 방법이 나옵니다. 바로 직접 접근하는 방법인데요!!!
눈치 채신 분들도 있으실건데 바로 step1.php 다음 step2.php로 넘어갔습니다. 그럼 관리자 인증을 통과한다면 step3.php로 넘어가지 않을 까요?
step3.php를 요청하니 인증없이 바로 다음 단계로 넘어갔습니다.
이것이 바로 인증 우회의 다른 방법인 직접 접근하는 방법입니다.
예를 들면 약관동의 -> 휴대폰 인증 -> 회원가입 이렇게 단계를 밟아 다음 페이지로 넘어가는 곳에서 휴대폰 인증없이 바로 회원가입도 할 수 있게 된다고 합니다. (실제로 이러한 취약점이 발견된다고도...)
이런 우회를 막을 수 있는 방법은 간단합니다. 각 페이지 별로 토큰을 발행하여 다음 페이지에 토큰에 권한이 있을 경우에만 다음 단계로 갈 수 있게하고 아니면 전 단계로 다시 돌려버리는 방법이 있습니다.
그리고 이걸 노리고 만든 챌린지라 그런지 자세히보면 애초에 관리자 비밀번호를 받아 확인하는 곳이 없습니다...ㅎㅎ
이렇게 이번 챌린지들을 통해 실제로 우리는 페이지의 취약점을 찾기위해 논리적으로 접근해야한다는 것을 알았습니다.
페이지를 이용해보고 어떻게 설계되었는지 추측해보고! 버프 스위트를 통해 어떻게 데이터를 전송하는지도 확인 해봐야했습니다.
단순히 SQL Injection을 아무생각없이 넣는 것이 아닌 여러 방법을 생각해보고 접근하며 취약점을 찾아봐야합니다.
과제
1. 남은 챌린지들 풀어보기 (챌린지가 좀 많음...)
+ 게시판 만들기
'웹 해킹' 카테고리의 다른 글
| 웹 해킹 공부 일기장 2 - 과제 (0) | 2023.12.01 |
|---|---|
| 웹 해킹 공부 일기장 2 - 1 (SQL Injection 데이터 추출) (0) | 2023.11.30 |
| 웹 해킹 공부 일기장 1 - 과제 (챌린지) (0) | 2023.11.27 |
| 웹 해킹 공부 일기장 1 - 과제 (0) | 2023.11.26 |
| 웹 해킹 공부 일기장 1 -1 (SQL Injection) (0) | 2023.11.23 |
