[WebGoat] Broken Access Control

위지웅·2025년 11월 25일

멀티캠퍼스IT부트캠프 부트캠프후기 토스뱅크 사이버보안 엔지니어 부트캠프(공격&방어 기술)

Broken Access Control이란 권한이 없는 사용자가 다른 사용자 데이터 또는 관리자 기능에 접근할 수 있는 취약점을 말한다.

사용자 권한 검증을 예측 불가능한 난수 형태의 로그인 세션이나 access 토큰을 사용하지 않고 HTTP 요청 헤더 및 파라미터를 사용해 대처한 경우 많이 발견된다.

1) Hijack a session

정상 사용자의 세션 ID를 공격자가 훔치거나 강제로 주입하여 사용자의 로그인 상태를 그대로 탈취하는 공격

Access 버튼을 누르고 Proxy의 HTTP Histroy에서 http response를 보면 hijacked_cookie값을 볼 수 있다.

intruder로 보내서 쿠키 값이 어떻게 변하나 관찰하기위해 10회 반복하여 보내보았다.

쿠키값이 아래와 같이 보내지는데 - 앞에는 1씩 증가하고 - 뒤에는 UNIX Timestamp 값이다.
1씩 증가하다가 중간에 2가 증가한 케이스가 있다. 이때 이 사이에 누군가 로그인을 했다고 생각할 수 있다. 3→ 5
그럼 4를 넣고 뒤에 Timestamp 값은 3,5 사이에 값을 브루트포스로 넣어서 보내보면 해당 세션으로 로그인이 될 것이다.

540146443458788412-1763698119667
540146443458788413-1763698119972
540146443458788415-1763698120320

버프슈트 화면과 설명이 다른데 원리는 같다. intruder로 timestamp값을 하나씩 대입하여 보내면 문제가 해결된다.

2) Insecure Direct Object References(IDOR)

Direct Object Refereneces(직접 개체 참조)란 클라이언트가 URI Path나 파라미터 등으로 값을 서버에 전달하면 서버의 애플리케이션에서 전달 받은 값을 참고해 특정 데이터와 객체에 접근하는 것을 말함

클라이언트가 특정 데이터/객체에 접근 시 접근 권한이 있는지 검증 과정이 필요한데 이것을 접근 제어라고 함

IDOR은 이 접근 제어가 잘못 구현되어 권한 없는 특정 데이터나 객체에 접근하는 경우를 말함

IDOR은 수평적 권한상승과 수직적 권한 상승을 야기함

2번

권한 없는 데이터나 객체에 접근하기 위해선 접근이 인가되지 않은 사용자가 필요한데 2번이 해당 사용자로 로그인하는 내용이다. 설명대로 tom/cat을 입력해 로그인하자

3번

view profile을 눌러 웹에서 보는 프로필 정보와 raw response결과를 비교해보면 role, userId attribute가 웹에선 보이지 않는 것을 알수있다.

4번

RESTful API에서 직접 객체 참조를 어떻게 수행할 것인지를 묻는 문제이다. RESTful API를 통해 로그인한 tom의 프로필을 조회하기 위한 URI Path를 완성하면 된다.

3번에서 프로필을 조회할때 GET 메소드를 이용해 /WebGoat/IDOR/profile 로 요청을 보냈다.

응답에선 userId 정보가 있었다. 이걸 조합해서 요청을 보내면 될것같다.

Tom 계정으로 로그인하여 Tom userId를 이용해 프로필을 조회했다. userId를 변경하여 다른 사용자의 프로필을 조회할 수 있을 것 같다.

입력값: WebGoat/IDOR/profile/2342384

5번

view profile을 눌렀을때 GET 요청을 보면 %7buserId%7D로 요청을 보낸다.

%7B, %7D는 {}를 URL 인코딩한 값이다. 따라서 %7buserId%7D는 {userId}이다.

Repeater로 이동해 해당 영역에 이전에 알아냈던 Tom의 userId를 넣어보자

피드백으로 다른 사용자 프로필에 접근하도록 다시 시도하라고 나온다. repeater의 기능을 이용해 userId에 1씩 값을 더하며 요청을 보내보자 intruder를 이용해도 된다.

성공적으로 다른 사용자의 프로필에 접근했다.

"{role=3, color=brown, size=large, name=Buffalo Bill, userId=2342388}"

다른 사용자의 프로필을 변경해야한다. 프로필을 조회할때는 GET 메소드를 이용했다. 프로필 내용 변경을 위해서는 PUT 메소드를 사용할 것이다.

문제에서 Buffalo Bill의 프로필에 권한을 높이고(작은 숫자로 변경), color를 red로 변경하라고 한다.

Response에서 Content-Type: application/json 이였다. PUT 메소드를 이용해 JSON 형태로 값을 넘기면 될 것 같다!

HTTP Method
GET - 자원을 받아올 때 사용
POST - 새로운 자원을 추가할 때 사용
PUT -존재하는 자원을 변경 할 때 사용
DELETE - 자원을 삭제할 때 사용

JSON으로 어떤 값들을 넣어야 할지는 이전 프로필 조회 응답내용을 참고하자

GET → PUT, {userId} → Buffalo Bill의 userId, Content Type은 json, body에는 json 형식의 프로필 정보를 넣어 보내면 문제 해결

3) Missing Function Level Access Control

사용 불가능한 기능을 사용할 수 있는 경우를 말한다.

IDOR과의 차이점은 IDOR의 경우 권한이 없는 객체/데이터에 접근하는 것이고 Missing Function Level Access Control은 권한 없는 기능을 사용하는 것이다.

예를 들어 모든 사용자가 접근 가능한 내 정보 보기 기능을 이용해 다른 사용자의 정보를 조회하면 권한이 없는 개체/데이터에 접근한 것이기에 IDOR 취약점이 존재하는 것이고 관리자 권한이 있는 사용자만 사용할 수 있는 공지사항 작성 기능을 일반 사용자가 이용하게 된다면 Missing Function Level Access Control 이다.

2번

개발자도구로 소스코드를 보니 Messages 메뉴 옆에 보이지 않지만 코드상으로 존재하는 영역이 있다.

CSS를 보면 visivility: hidden으로 설정되어있다. 그리고 html 코드를 보면 해당 메뉴 내부에 Users, Config가 있는데 이게 답인것 같다.

css에서 hidden-menu-item을 더블클릭해 들어가서 삭제해주자

그럼 숨겨져있던 Admin 메뉴가 보이고 안에 문제에서 요구하는 답인 Users, Config가 있다

3번

Jerry의 hash값을 얻어야한다. 2번에서 얻은 정보를 사용하라 하였으니 2번의 Admin 메뉴에 Users와 Config와 연관이 있을것이다. 사용자의 정보가 필요한 것이니 Users와 연관이 있을것같다.

Users를 클릭했을때 415 상태코드가 나온다. 415는 지원되지 않는 미디어 유형을 의미한다. 클라이언트가 서버로 보낸 요청의 페이로드(본문 데이터) 형식이 서버에서 지원하지 않는 형식일 때 발생하는 클라이언트 측 오류다. Content Type이 틀린것 같다. response를 보면 Accept에 json을 받는다 되어 있다.

Repeater로 보내서 수정하여 다시 시도해보자

403 에러가 뜬다. 서버가 클라이언트의 요청을 이해했지만 접근 권한이 없어 거부되었음을 의미하는 오류이다.

개발자를 위한 웹해킹 책이나 다른사람들의 풀의를 보면 html에서 users 메뉴가 보였어야 하는데 내 화면에는 users가 없다… WebGoat가 업데이트 되면서 푸는 방법이 바뀐건지 누락된건지 모르겠다.

기존 풀의대로라면 users로 GET요청을 날렸을때 Content-Type이 맞지 않아 에러가 나고 json으로 Content-Type을 맞춰주면 해시값을 얻게 된다.

users-admin-fix를 users로 바꾸고 Content-Type을 json으로 바꿔 보내보니 이전 풀이들처럼 정상적으로 사용자들 정보가 보인다.

문제를 수정해서 게싱으로 때려맞추게끔 만든건지 다른 정보가 있는건지 모르겠다.

어쨋든 이 문제에서 알수있는 점은 users는 Admin 메뉴 아래에 있었다. 즉 users는 Admin만 사용가능한 기능이다. 그래서 모든 사용자의 정보를 응답으로 받은 것이다.

4번

관리자만 모든 사용자 목록을 볼 수 있게 수정했다고 한다.

이 문제에서 users-admin-fix를 이용하는것 같다… admin… fix… 수정한버전….. 진짜 admin 그냥 누락된거 같은데….

3번에서 설명한것처럼 Content-Type를 추가하여 403 에러 나는 위치까지 가자

계정 목록에 실제로 webgoat에 로그인한 내 정보는 없는걸 확인할 수 있다. 그렇기에 권한이 부족해 목록을 볼 수 없는 것이다. 그럼 내 계정을 admin으로 추가하면 목록을 볼 수 있지 않을까?

GET을 POST로 바꾸고 body에 json형태로 admin: true로해서 내 정보를 넣어주자

해시값은 아무거나 넣었다.

추가 후 다시 목록을 확인해보면 내 계정이 admin으로 추가되어 전체 유저 목록이 다시 확인 가능한 것을 볼 수 있다.

접근 제어를 위해 생성한 다른 사용자의 쿠키값을 유추하는 것을 의미한다. 접근 제어를 위해 발행한 쿠키값이 쉽게 유출할 수 있는 알고리즘으로 만들어져 있을때 문제가 생기는 것을 볼 수 있다.

2번

주어진 계정 webgoat와 admin으로 로그인하면 cookie값을 볼 수 있다. webgoat 쿠키값 뒤에 보면 =이 보이는게 뭔가 base64같다 decode 해보자

raw
webgoat: NzM1MDUyNGQ0ODYzNjM2YzQyN2E 3NDYxNmY2NzYyNjU3Nw==
admin: NzM1MDUyNGQ0ODYzNjM2YzQyN2E2ZTY5NmQ2NDYx