순차적 ID 대신 암호화된 키 사용하기
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
보안
대상자
- 대상: API 개발자, 웹 애플리케이션 개발자, 보안 전문가
- 난이도: 중급~고급 (보안 취약점 분석 및 리팩토링 경험이 필요)
핵심 요약
UUIDs
사용으로 IDOR 공격 예방 →sequential IDs
대체- 예측 가능한 URL 및 데이터 크롤링 위험 감소 →
UUID
적용 - 내부 ID 비공개 및 외부 UUID 공개 → 캡슐화 강화
섹션별 세부 요약
1. IDOR 취약점과 예측 가능한 ID 문제
IDOR (Insecure Direct Object Reference)
공격: 순차적 ID로 인한 객체 직접 참조 가능성 증가Predictable URLs
: URL에 포함된 순차적 ID로 인한 사용자 정보 유출 위험Data Scraping
: 자동화된 크롤러가 순차적 ID를 활용한 데이터 수집 가능성 증가
2. 리팩토링 단계
Step 1
: API, URL, UI에서 사용 중인sequential IDs
식별Step 2
: 데이터 이전 또는 생성 시UUIDs
생성 (예:generate_uuid()
함수 사용)Step 3
: 외부 인터페이스에서sequential IDs
→UUIDs
로 대체Step 4
: 내부 시스템에서UUID
↔original ID
매핑 (프라이버트 룩업 테이블 또는 서비스 사용)Step 5
: 모든 서비스 및 데이터베이스에서UUIDs
일관성 유지
3. 리팩토링의 이점
Encapsulation
개선: 내부 ID 비공개 → 시스템 구조 유출 방지API 설계 정리
: 명시적 매핑을 통한 명확한 인터페이스 설계RESTful API
및마이크로서비스
에서 효과적 적용 가능404 리소스
에 대한Rate Limiting
적용 가능 (공격 시 시도 제한)
4. 추가 고려사항
Dual Access
유지: 리팩토링 중UUID
및ID
동시 접근 허용 (단계적 업데이트 지원)Client-Facing Integration
업데이트: 일부 시스템이 수치 ID에 의존할 수 있음
결론
UUIDs
적용을 통해IDOR
취약점 방지 및데이터 유출
위험 최소화 → 보안 강화- 리팩토링 시
단계적 접근
과테스트
수행 필수 →백워드 호환성
유지 UUID
일관성 유지 및내부 매핑 테이블
사용 → 시스템 확장성과 안정성 향상