CHO NAM GI

개인 공부 블로그입니다.

visitor

4 분 소요

모의해킹 실무를 진행하다 보면 반복적이고 번거로운 작업 중 하나가 권한 검증이다. 타겟 사이트에 수많은 메뉴와 API가 있는데, 과연 일반 유저가 관리자 페이지에 몰래 접근할 수 있는지(IDOR, 권한 상승) 일일이 수동으로 확인하는 건 비효율적이다.

이럴 때 유용하게 사용할 수 있는 도구가 바로 Burp Suite의 Autorize 플러그인이다. 관리자 쿠키 한 번만 세팅해두면 백그라운드에서 알아서 권한 우회 가능성을 점검해주는 아주 든든한 툴이다. 이번 글에서는 Autorize의 원리부터 설치, 트러블슈팅, 그리고 실무에서 써먹기 좋은 세팅 노하우까지 한 번에 정리해 보려고 한다.

1. Autorize의 핵심 원리

Autorize의 동작 원리는 꽤 단순하고 직관적이다. 내가 웹 브라우저에서 ‘일반 유저’로 웹사이트 이곳저곳을 누르고 다닐 때, Autorize가 뒤에서 몰래 해당 요청들을 가로챈다. 그리고 미리 세팅해둔 ‘관리자 세션 쿠키’를 끼워 넣어서 한 번 더 요청을 날려본다.

결과적으로 원본(일반 유저 요청)과 조작된 요청(관리자 쿠키)의 서버 응답을 서로 비교하여, 일반 유저가 보면 안 될 데이터가 노출되고 있는지 판별하는 구조다.

2. 환경 설정과 설치

Autorize는 Python 기반으로 만들어졌기 때문에, 일반적인 Java 기반 익스텐션과 다르게 사전 세팅이 필요하다. 여기서 은근히 헤메는 경우가 있다. (나도 그랬음..)

Jython 환경 세팅

  1. Jython 공식 홈페이지에서 Installer가 아닌 Jython Standalone JAR 파일(약 30~40MB)을 다운로드한다.

    image-20260619110350503

  2. 다운로드한 파일을 C:\tools 같은 경로로 옮긴다. (주의: 경로에 한글이나 공백이 포함되면 알 수 없는 에러가 발생할 확률이 높으니 피하는 게 좋다.)

  3. Burp Suite 설정 에서 Extensions > Core extension settings > Python Environment에서 해당 JAR 파일 경로를 지정해 준다.

    image-20260619110859551

설치 중 만나는 흔한 에러 해결 (Extension class is not a recognized type)

만약 플러그인 추가 시 위와 같은 에러가 뜬다면 십중팔구 다음 중 하나다.

  • GitHub에서 코드를 받는 방법을 사용하다가 ‘다른 이름으로 저장’을 눌러서 HTML 웹페이지를 받아버린 경우.
  • 파일을 직접 Add 하면서 확장자 타입을 Java에서 Python으로 안 바꾼 경우.

가장 속 편한 해결책은 수동 추가를 피하는 것이다. Jython 세팅만 제대로 끝냈다면, 곧바로 Burp의 BApp Store 탭으로 가서 Autorize를 검색하고 Install 버튼을 누르자. 알아서 깔끔하게 설치된다.

3. 세팅 가이드

설치에 성공했다면, 실전에서 유용하게 써먹기 위한 세팅을 해보자.

3.1. 타겟 쿠키 주입 (수직적 vs 수평적 권한 상승)

우측 탭의 Users 항목에는 테스트 목적에 맞는 타겟 유저의 쿠키를 넣어주면 된다. 하단의 Fetch Cookies header 버튼을 활용하면 최근 요청에서 자동으로 쿠키를 긁어와 주기 때문에 매우 편리하다.

image-20260619132418360

초보자들은 흔히 이곳에 ‘관리자 쿠키’만 넣고 테스트를 끝내버리지만, Autorize는 목적에 따라 두 가지 강력한 취약점을 모두 잡아낼 수 있다.

  1. 수직적 권한 상승 (일반 유저 ➡️ 관리자)
    • Users 쿠키: 관리자 쿠키
    • 브라우저 조작: 일반 유저
    • 목적: 일반 유저가 관리자 전용 기능(/admin/userList)을 실행할 수 있는지 검증.
  2. 수평적 권한 상승 / IDOR (유저 A ➡️ 유저 B)
    • Users 쿠키: 일반 유저 B의 쿠키 (희생자)
    • 브라우저 조작: 일반 유저 A (공격자)
    • 목적: A가 자신의 개인정보 페이지(/profile?id=A)를 열람할 때, Autorize가 백그라운드에서 B의 쿠키로 동일하게 요청을 보내 타인의 민감한 데이터를 훔쳐볼 수 있는지 검증.

3.2. 세션 만료(Logout)의 함정 피하기

💡 주의 사항: 세션 유지하기 테스트를 위해 타겟 계정(관리자 혹은 희생자)으로 로그인해 쿠키를 세팅한 직후, 곧바로 로그아웃하고 공격자 계정으로 로그인하는 실수를 흔히 한다. 로그아웃 버튼을 누르는 순간 서버는 해당 세션을 파기해 버리기 때문에, Autorize에 넣어둔 쿠키는 ‘죽은 쿠키’가 되어버린다.

올바른 방법은 브라우저를 두 개 쓰는 것이다. 브라우저에서 타겟 유저로 로그인해 쿠키를 따온 뒤 창을 그대로 최소화해 두고, 브라우저 시크릿 모드나 다른 브라우저를 열어 공격자 유저로 테스트를 진행해야 한다.

3.3. Configuration (방어 및 탐지 세팅)

Configuration 탭에는 결과를 더 날카롭게 다듬어주는 필수 옵션들이 있다.

  • Check unauthenticated: 체크 필수. 이 옵션을 켜면 관리자/일반유저 요청뿐만 아니라, 아예 쿠키를 뺀 비인가 요청까지 총 3가지를 쏴준다. 로그인 안 한 사람이 URL만 치고 들어올 수 있는지도 동시에 체크해주기 때문에 실무 활용도가 높다.
  • Ignore 304/204 status code responses: 의미 없는 캐시 관련 응답을 무시해 결과 창이 쓰레기 로그로 더러워지는 걸 막아준다.
  • Prevent 304 Not Modified status code: 브라우저 캐시를 무시하고 서버가 전체 응답을 강제로 내려주도록 만들어, 응답 길이 비교를 통한 권한 확인을 명확하게 해준다.

4. 권한 검증 사냥 시작과 결과 해석

좌측 상단의 스위치를 Autorize is On으로 켜두고 일반 유저 계정으로 이리저리 돌아다니기 시작하면 로그가 쌓인다. 색상만 잘 해석해도 80%는 성공이다.

​ image-20260619134312686

  • 🔴 Bypassed! (빨간색): 일반 유저가 관리자 기능을 뚫었다는 의미. 단, 로그인(login.jsp)이나 로그아웃 페이지처럼 원래 누구나 접근 가능한 페이지는 길이가 같아서 빨간색으로 뜨는 ‘오탐(False Positive)’이므로 잘 걸러내야 한다.
  • 🟢 Enforced! (초록색): 일반 유저의 접근을 서버가 정상적으로 차단했다는 의미다. 방어가 잘 되고 있다는 뜻이므로 안심하고 넘어가면 된다.
  • 🟡 Is enforced??? (노란색): 여기서 취약점이 많이 나온다. 응답 길이가 미세하게 달라서 툴이 헷갈려 하는 상황이다. 이럴 땐 로그를 우클릭해서 Send to Comparer로 보낸 후, 관리자가 본 소스코드와 일반 유저가 본 소스코드를 직접 비교하며 유의미한 정보 노출이 있는지 수동으로 체크해야 한다.

Unauth. Status vs User 1 Authz. Status

Autorize 창의 두 칼럼은 각각 다른 결함을 잡아낸다.

  • Unauth. Status: 인증 누락(Authentication Bypass). 로그인도 안 한 외부인이 게시판 등 인가된 페이지를 볼 수 있는지 체크.
  • User 1 Authz. Status: 권한 상승(Privilege Escalation) 및 IDOR. 세팅한 목적에 따라, 일반 유저가 관리자 기능을 건드릴 수 있는지(수직적) 또는 타인의 데이터를 훔쳐볼 수 있는지(수평적) 체크.

둘 다 보안상 치명적인 영역이므로 테스트 시 두 칼럼 모두 꼼꼼하게 들여다봐야 한다.

5. 웹 반응속도 문제

툴을 사용하면 웹사이트 반응 속도가 눈에 띄게 느려졌다고 느낄 수 있다. 이는 툴이 고장 난 게 아니라 Check unauthenticated 옵션 때문에 트래픽이 3배로 증폭되어서 서버와 브라우저가 힘들어하고 있는 것이다. 평소 구조를 파악하며 둘러볼 때는 스위치를 Off로 꺼두고, “여긴 취약할 것 같다”는 직감이 오는 메뉴를 점검할 때만 켜서 타겟 집중 사냥을 하는 것이 필요하다.

댓글 남기기