top of page

Notification, blog

로그인했는데 남의 문서가 보인다? API 객체별 권한 검증법

2분 전
2분 분량

정상 로그인 뒤에도 데이터가 새는 이유


사용자가 자신의 주문 내역을 보려고 API를 호출합니다. 요청의 주문 번호만 다른 사람의 번

호로 바꿨는데 상세 정보가 나온다면, 로그인 절차가 있어도 데이터는 보호되지 않습니다. 토큰은 호출자가 누구인지 알려 주지만, 그 주문을 볼 자격까지 증명하지는 않습니다. Kong은 10월 22일 API 보안 지침에서 이런 사례를 객체 수준 인가 실패, 즉 BOLA로 설명했습니다. [Kong 공식 글]


OWASP API Security Top 10의 API1:2023 문서도 객체 ID를 받는 모든 API에서 요청자에게 해당 객체에 대한 작업 권한이 있는지 확인하라고 권고합니다. ID가 연속 숫자인지 예측하기 어려운 값인지는 핵심 방어선이 아닙니다. 경로, 쿼리, 본문에 담긴 ID가 서버의 권한 판단 없이 조회나 수정에 쓰이는지가 문제입니다. [OWASP BOLA 문서]


출처. ChatGPT 생성형이미지
출처. ChatGPT 생성형이미지

권한 검사는 어디에서 해야 할까요?


먼저 사용자와 객체의 관계를 정의해야 합니다. 주문이라면 소유 고객, 처리 직원, 위임 받은 담당자가 각각 어떤 조회·수정 작업을 할 수 있는지 적습니다. 같은 사용자가 조회는 가능하지만 환불은 할 수 없는 경우도 있습니다. 따라서 “로그인 여부” 한 가지 값으로 모든 요청을 통과시키면 안 됩니다. 권한이 정의되지 않은 작업은 거부하는 기준을 세우세요.


실제 판단은 객체 소유권과 업무 규칙을 아는 서비스에서 요청마다 수행해야 합니다. URL에 들어온 사용자 ID를 그대로 신뢰하지 말고 검증된 인증 정보와 서버가 가진 객체 관계를 대조합니다. 목록 조회뿐 아니라 상세 조회, 파일 다운로드, 변경, 삭제, 일괄 처리까지 살펴야 합니다. 새 API를 추가할 때도 기존 화면 뒤에 가려진 호출이 있는지 확인하세요. 게이트웨이의 인증과 호출 제한은 공통 방어에 유용하지만, 개별 주문의 소유자를 아는 서비스의 권한 검사를 대신할 수 없습니다. [Kong 공식 글]


두 계정으로 재현 가능한 시험을 만드세요


가장 작은 시험은 권한이 다른 계정 두 개와 객체 두 개로 시작합니다. A가 자기 문서를 조회할 수 있는지 확인한 다음, 같은 토큰으로 B의 문서 ID를 넣어 봅니다. 읽기만 시험하지 말고 수정·삭제·첨부파일 요청도 같은 방법으로 확인하세요. 허용되지 않은 요청의 응답과 실제 데이터 변경 여부를 함께 검사해야 합니다. 거부 응답이 나왔더라도 뒤에서 작업이 실행됐다면 실패입니다.


다음으로 관리자, 위임 사용자, 권한이 만료된 계정을 추가합니다. 권한 정책이 바뀌면 기존 권한이 즉시 회수되는지, 일괄 API의 일부 항목만 다른 소유자인 경우 어떻게 처리되는지도 결정해야 합니다. 테스트 결과에는 요청자, 객체 소유자, 허용 작업, 예상 결과, 실제 결과를 남깁니다. 권한 변경이나 API 배포 때 같은 시험을 반복할 수 있어야 합니다. [OWASP BOLA 문서]


출처. ChatGPT 생성형이미지
출처. ChatGPT 생성형이미지

출처 및 참고자료



bottom of page