mypage.php
DATE : 2024/2/12
오늘부터 작성될 SELF TEST Section에서는
지금까지 스스로 개발한 웹 서버를 대상으로 취약점을 찾아보는 내용을 다룰 것이다.
개인적으로 PHP + MySQL + Apache 환경에서 개발을 했기 때문에
우선 localhost로 접근하는 경로에서 실습을 해볼 것이다.
1_mypage.php
로그인 한 사용자에게 제공되는 index 페이지에서는 mypage로 접근할 수 있는 버튼이 제공된다.
mypage로 이동하면 위와 같은 화면을 볼 수 있는데 이를 공격자가 생성한 계정 정보라 가정할 것이다.
현재 공격자는 개인 정보 수정 요청을 통해 자신이 아닌 다른 사용자의 정보를 수정하고자 한다.
회원 가입 이래에 수정할 수 없는 Username이 어떻게 사용될까 고민해본 결과,
사용자를 구분하기 위한 식별 정보로 쓰일 거라 예측했다.
그렇다면 각 사용자의 username을 가져다가 서버는 아래와 같이 Query를 작성하게 될 것이다.
예측 Query를 위와 같이 작성해봤을 때,
공격자는 단순히 username만 바꿔치기 해버리면 다른 사용자의 개인 정보를 자신이 입력한 대로
수정할 수 있을 거라 판단하게 된다!
과연 예측한 대로 피해자의 개인 정보를 수정할 수 있을지 확인해 보자.
위와 같이 비밀번호까지 포함한 수정할 정보를 입력한 뒤, EDIT 버튼을 눌러 준다.
이때! burp suite로 packet을 잡아다가
hanhxx라 적혀 있는 username 값을 공격 대상인 딜뭉씨의 이름으로 바꿔준다. (hanhxx -> dilmung)
공격자가 본인 계정을 생성할 수 있다는 건, 다른 사용자처럼 서비스를 이용할 수 있다는 의미로
이때 게시판 기능을 제공하는 index 페이지에서 작성자 내용을 보고 다른 사용자의 username을
쉽게 알아낼 수 있다.
정보가 성공적으로 수정되었다는 문구를 본 뒤, 공격자는 자신의 계정에서 로그인을 한다.
자! 이제 이후에 일어날 수 있는 상황을 상상해보자.
계정의 주인인 딜뭉이 로그인을 하기 위해 자신의 계정을 입력하게 되면 안타깝게도
로그인에 실패하게 된다. 이는 공격자가 조작한 요청이 성공적으로 딜뭉씨의 비밀번호까지
수정해버렸음을 뜻하다.
따라서 로그인 하지 않은 상태에서 비밀번호를 수정할 수 있는 기능이 제공되지 않는 이상,
딜뭉씨는 바꿔 버린 비밀번호를 모르기 때문에 다시는 자신의 계정으로 로그인을 하지 못하게 된다.
한편, 자신이 원하는 대로 딜뭉씨의 비밀번호를 바꿔 버린 공격자는
곧바로 비밀번호를 입력해 딜뭉의 계정으로 로그인했다.
상단 헤더를 보면 성공적으로 dilmung 계정에 로그인 되었음을 확인할 수 있고
mypage에서는 비밀번호를 제외한 나머지 정보 또한 수정되어있음을 볼 수 있다.
이렇게 해서 mypage에서 찾은 취약점으로 다른 사용자의 개인 정보를 수정해보았다.
자신의 비밀번호가 바꿔 버린 피해자 입장에서는 서비스를 이용하지 못하게 되는 것 뿐만 아니라
공격자가 수정하지 않았다면 이메일이 노출될 수도 있고 결제 정보가 포함되어 있었을 수도 있다!
개발할 때는 생각을 못했는데,, 이번 계기를 통해
수정 요청을 보낸 사람이 정보를 수정할 계정 주인인지 확인하는 절차도 필요할 듯하다..!
Last updated
