Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
본 논문은 107 건의 분류된 버그 바운티 리포트를 대상으로 한 대규모 실증 분석을 제시하여, 액션 레벨 객체 BOLA 가 지배적이면서도 과소 대표된 취약점 패밀리임을 밝히고, 플랫폼 태그에 대한 의존성이 깨진 객체 수준 권한 부여의 발생 빈도를 크게 과장하고 있음을 입증한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
거대하고 첨단 기술이 적용된 아파트 단지를 걷고 있다고 상상해 보세요. 당신은 건물에 들어갈 수 있는 키 카드 (인증) 를 가지고 있지만, 진정한 보안은 당신이 들어갈 수 있는 특정 아파트를 확인하는 데 있어야 합니다.
**Broken Object Level Authorization(BOLA)**는 건물의 보안 요원이 당신이 열려고 하는 특정 아파트 번호와 키 카드를 대조하지 않고 방심했을 때 발생합니다. 당신은 합법적인 거주자일 수 있지만, 402 호를 열려고 시도할 때 보안 요원은 402 호가 당신에게 속해 있는지 확인하지도 않은 채 "물론, 들어가세요"라고 말합니다.
이 논문은 버그 바운티 프로그램 (해커들이 이러한 허점을 찾아내면 보상을 받는 곳) 에서 나온 107 건의 실제 보안 보고서에 대한 대규모 조사입니다. 연구자들은 "이론적"인 보안 조언을 넘어 실제 세계에서 무엇이 실제로 일어나고 있는지 파악하고자 했습니다.
다음은 그들의 발견 사항을 간단한 비유로 정리한 내용입니다:
1. "레이블 노이즈" 문제 (거짓 경보)
연구자들은 HackerOne 에서 "IDOR"(이러한 유형의 버그에 대한 일반적인 이름) 로 태그된 200 건의 보고서를 먼저 살펴보았습니다.
- 발견: 해당 보고서 중 실제로 유효한 것은 **42%**에 불과했습니다.
- 비유: 화재 경보 시스템이 200 번 울린다고 상상해 보세요. 연구자들은 그중 39% 는 화재가 전혀 아니었음을 발견했습니다. 단지 누군가가 토스트를 태우거나, 뜨거운 샤워를 하거나, 센서가 고장 난 경우였습니다.
- 교훈: 시스템에 "IDOR" 태그가 붙었다고 해서 반드시 특정하고 위험한 "Broken Object" 취약점이 있다는 뜻은 아닙니다. 보안 팀은 태그를 지나치게 신뢰하기 때문에 위험을 과대평가하는 경우가 많습니다.
2. 두 명의 주요 악당 (분류 체계)
연구자들은 실제 버그를 여섯 가지 범주로 분류했습니다. 그중 두 가지가 명확한 승자로서 전체 사례의 거의 **80%**를 차지했습니다:
악당 A: "Direct Object Reference"(전화번호부 속임수)
- 정의:
website.com/invoice/101과 같은 URL 을 보게 됩니다. 숫자를102로 변경하면 갑자기 다른 사람의 송장을 볼 수 있게 됩니다. - 비유: 우편함 줄을 따라 걷는 것과 같습니다. 당신의 우편함이 101 번임을 압니다. 102 번을 시도해 보니 자물쇠가 고장 나 있어 우편함을 열고 이웃의 우편물을 읽을 수 있습니다.
- 빈도: 전체 사례의 **37%**에서 발생했습니다.
- 정의:
악당 B: "Action-Level Object"(방화범)
- 정의: 이것이 큰 놀라움입니다. 단순히 다른 사람의 데이터를 읽는 것이 아니라, 그것을 변경하거나 삭제하는 것입니다.
- 비유: 당신은 우연히 (접근해서는 안 되는) 이웃의 우편함 앞에 서 있습니다. 우편물을 읽는 대신 우편함을 벽에서 뜯어내거나, 그들의 이메일을 삭제하거나, 그들의 돈을 이체합니다.
- 빈도: 전체 사례의 **42%**에서 발생했습니다.
- 중요성: 대부분의 보안 가이드는 데이터를 "읽는" 것에 초점을 맞춥니다. 이 논문은 "해커들은 단순히 감시하는 것보다 데이터를 파괴하고 변경하는 경우가 더 많다"고 말합니다.
3. 다른 교활한 악당들
나머지 20% 의 버그는 더 복잡했습니다:
- Tenant Isolation(테넌트 격리): 당신은 공유 오피스 빌딩에 있습니다. 다른 회사의 오피스 스위트 문을 열려고 시도하지만 자물쇠가 고장 납니다.
- Workflow-Context(워크플로우 컨텍스트): 당신은 회사에서 해고되었지만, 시스템이 당신의 상태를 업데이트하는 것을 잊어버려 과거에 근무하던 프로젝트의 "아카이브" 파일에 여전히 접근할 수 있습니다.
- Chained Disclosure(연쇄적 유출): ID 를 추측할 수는 없지만, 앱의 다른 부분 (예: 영수증) 에서 ID 목록을 발견하고 그 목록을 사용하여 다른 사람의 계정으로 침입합니다.
- Object Rebinding(객체 재결합): 요청의 숨겨진 필드를 변경 (예: 문서의 "소유자" 이름 변경) 하여 시스템이 당신이 그 객체를 소유한다고 착각하게 만듭니다.
4. "수직적" 놀라움 (엘리베이터 탑승)
보통 우리는 이러한 공격을 "수평적"(사용자 A 가 사용자 B 로부터 훔치는 것) 으로 생각합니다.
- 발견: **12%**의 경우, 일반 사용자가 관리자에 속한 항목에 접근하거나 삭제하는 데 성공했습니다.
- 비유: 아파트 단지의 일반 거주자가 빌딩 관리자의 사적인 사무실로 들어가 마스터 키를 삭제하는 것입니다.
- 교훈: 이는 대부분의 보안 체크리스트가 "관리자는 안전하다"고 가정하기 때문에 무시하는 거대한 위험입니다.
5. "매직" ID 는 작동하지 않음
개발자들은 종종 "1, 2, 3 과 같은 간단한 숫자 대신 긴 무작위 코드 (UUID) 나 인코딩된 문자열을 사용하면 안전하다"고 생각합니다.
- 발견: 성공적인 공격의 **39%**는 이러한 "복잡한" ID 를 사용했습니다.
- 비유: 해커들이 우편함의 "비밀 코드"를 해독할 방법을 찾아냈고, 그것이 단지 숨겨진 숫자임을 깨닫고 다음 우편함을 얻기 위해 단순히 숫자를 증가시켰습니다.
- 교훈: ID 를 숨기는 것은 문제를 해결하지 못합니다. ID 가 어떻게 보이든 서버는 여전히 해당 객체의 소유자가 맞는지 확인해야 합니다.
6. "GraphQL" 허점
이 논문은 많은 현대 앱이 GraphQL 이라는 시스템을 사용한다는 것을 발견했습니다. 이러한 시스템은 gid://hackerone/Report/123과 같은 "Global ID"를 사용합니다.
- 발견: 공격자들은 이러한 ID 를 디코딩하면 그 아래에 있는 순차적인 숫자가 드러나 다음 ID 를 쉽게 추측할 수 있음을 발견했습니다.
- 교훈: ID 가 복잡한 문자열처럼 보인다고 해서 그것이 무작위라는 뜻은 아닙니다.
일반인을 위한 요약
이 논문은 우리에게 다음과 같은 사실을 알려줍니다:
- 태그를 신뢰하지 마세요: 시스템이 특정 버그가 있다고 플래그가 지정되었다고 해서 실제로 그 방식으로 고장 난 것은 아닙니다.
- 나쁜 놈들은 파괴적입니다: 그들은 단순히 데이터를 훔치는 것이 아니라, 우리가 생각한 것보다 데이터를 삭제하고 변경하는 경우가 더 많습니다.
- 비밀 코드는 충분하지 않습니다: 서버가 데이터 소유자를 확인하지 않는다면 복잡한 ID 를 사용해도 해커를 막을 수 없습니다.
- 일반 사용자가 관리자를 해칠 수 있습니다: 일반 사용자 계정이 때로는 "상사"의 것을 침입할 수 있습니다.
이 논문은 보안 테스트가 변화해야 한다고 결론 내립니다. 우리는 단순히 다른 사람의 데이터를 읽을 수 있는지 확인하는 것을 멈추고, 데이터를 삭제하거나 변경할 수 있는지 확인하기 시작해야 하며, 일반 사용자가 실수로 (또는 고의로) 관리자 항목에 침입할 수 있는지 테스트해야 합니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.