SSPP 실습(1) - Exploiting server-side parameter pollution in a query string (PortSwigger Academy)

Lab: Exploiting server-side parameter pollution in a query string

Lab Link: Exploiting server-side parameter pollution in a query string

목표: administrator계정을 취득해 carlos계정을 삭제

정찰 과정

사이트 내 비밀번호 찾기 기능에서 찾으려는 username을 administrator 로 보낼 경우에 HTTP response 200을 반환.

administrator 외에 존재하지 않는 임의의 값을 넣게되면 HTTP Response 400 을 반환하는걸 볼 수 있음.

이 외에도 forgot-password를 전송하게 되면 /static/js/forgotPassword.js를 트리거 하게되는데, javascript 코드를 보면 reset_token이라는걸 사용하는것으로 보여짐

브라우저에 /forgot-password?reset_token 에 임의의 값을 넣어 전송

“Invalid token”을 반환한다. 여기서 부터는 이전 포스팅 에서 다뤘던 SSPP 테스팅 기법을 사용해보자.

테스팅 기법 적용

1. ‘&’ 를 사용해서 다른 파라미터 추가

%26secondParam=abc를 administrator뒤에 추가함으로써 두번째 쿼리가 삽입되는지 확인

“Parameter is not supported” 라는걸 응답을 확인할 수 있음. 이는, 내부 API가 SecondParam=abc 를 이름이 아닌, 다른 파라미터로 인식했음을 알 수 있음. 아직 서버가 어떤 파라미터를 요구하는지 모르니 넘어가자.

2. ‘#’ 을 사용해서 나머지 쿼리 자르기

%23을 adminisrrator뒤에 추가함으로써 뒤에 나머지 쿼리가 누락되는지 확인

“Field not specified” 라는걸 확인할 수 있음. 이는, 서버측에서 추가로 field라는 파라미터를 사용하고 있으며, Request에 #을 추가함으로써 해당 파라미터가 요청에서 제거됐다고 추측가능함.

field의 값을 알아보기 위해 Burp의 Intruder를 이용해 Brute-Force 진행해주자.

3. Brute-Forcing field parameter

Payload Configuration에서 Word list는 Server-side variable names로 설정, Sniper는 field= 값으로 설정해준다.

결과 값을 2xx 로 필터링 해주면, username외에 email 파라미터가 존재하는것을 찾을 수 있음

확인을 위해 Repeater에서 field=email과 field=username으로 설정 후에 전송 하게되면, 아래와 같이 성공적으로 email과 username을 반환 하는걸 확인.

field값을 email로 전송한 결과

field값을 username으로 전송한 결과

앞서 발견했던 reset_token 의 값 "0xdbixz5e0trzk6ynw9nwceyr33ptl14" 또한 반환하는것을 확인할 수 있다.

위 토큰 값을 가지고 브라우저에 /forgot-password?reset_token=0xdbixz5e0trzk6ynw9nwceyr33ptl14 를 입력하게되면

관리자 계정을 reset할수 있는 페이지가 나온다. 여기서 임의의 비밀번호를 설정해주고, 로그인 한 뒤에 Admin panel에 접속, 아래 carlos의 계정을 삭제해주면서 마무리가 된다.