API 해킹의 모든 것

지은이·감수자·옮긴이 소개 xiii
옮긴이 머리말 xiv
베타리더 후기 xv
추천사 xvii
추천 서문(댄 바라오나) xix
감사의 글 xxii
이 책에 대하여 xxiv

PART I 웹 API 보안이 작동하는 방식

CHAPTER 0 보안 테스트 준비 3
0.1 권한 받기 4
0.2 API 테스트의 위협 모델링 4
0.3 테스트해야 할 API 기능 7
__0.3.1 API 인증 테스트 7
__0.3.2 웹 애플리케이션 방화벽 7
__0.3.3 모바일 애플리케이션 테스트 8
__0.3.4 API 문서 감사 8
__0.3.5 속도 제한 테스트 9
0.4 제한과 제외 10
__0.4.1 클라우드 API 보안 테스트 11
__0.4.2 DoS 테스트 12
0.5 보고와 개선 테스트 12
0.6 버그 현상금 범위에 관한 노트 13
요약 14

CHAPTER 1 웹 애플리케이션이 작동하는 방법 17
1.1 웹 애플리케이션 기초 17
__1.1.1 URL 18
__1.1.2 HTTP 요청 19
__1.1.3 HTTP 응답 20
__1.1.4 HTTP 상태 코드 22
__1.1.5 HTTP 메서드 23
__1.1.6 HTTP의 상태 24
1.2 웹 서버 데이터베이스 26
__1.2.1 SQL 26
__1.2.2 NoSQL 28
1.3 API의 역할 29
요약 29

CHAPTER 2 웹 API의 구조 31
2.1 웹 API가 작동하는 방식 31
2.2 표준 웹 API 타입 34
__2.2.1 RESTful API 35
__2.2.2 그래프QL 39
2.3 REST API 명세 43
2.4 API 데이터 교환 형식 44
__2.4.1 JSON 44
__2.4.2 XML 47
__2.4.3 YAML 48
2.5 API 인증 49
__2.5.1 기본 인증 49
__2.5.2 API 키 50
__2.5.3 JSON 웹 토큰 52
__2.5.4 HMAC 53
__2.5.5 OAuth 2.0 54
__2.5.6 인증 없음 56
2.6 API 실전: 트위터 API 살펴보기 56
요약 59

CHAPTER 3 일반적인 API 취약점 61
3.1 정보 누출 62
3.2 BOLA 63
3.3 사용자 인증 결함 65
3.4 데이터 과다 노출 66
3.5 리소스 부족과 속도 제한 67
3.6 BFLA 68
3.7 대량 할당 70
3.8 보안 설정 오류 71
3.9 주입 74
3.10 부적절한 자원 관리 76
3.11 비즈니스 로직 취약점 77
요약 78

PART II API 테스트 실험실 구축

CHAPTER 4 API 해킹 시스템 81
4.1 칼리 리눅스 81
4.2 개발자 도구로 웹 애플리케이션 분석 82
4.3 버프 스위트로 요청 캡처와 수정 85
__4.3.1 폭시프록시 설정 86
__4.3.2 버프 스위트 인증서 추가 87
__4.3.3 버프 스위트 모듈 88
__4.3.4 트래픽 가로채기 90
__4.3.5 침입자에서 요청 변경 92
4.4 포스트맨에서 API 요청 생성 96
__4.4.1 요청 생성기 97
__4.4.2 환경 100
__4.4.3 컬렉션 102
__4.4.4 컬렉션 실행기 106
__4.4.5 코드 조각 106
__4.4.6 테스트 패널 107
4.5 버프 스위트와 포스트맨의 조합 108
4.6 보충 도구 110
__4.6.1 OWASP 어매스로 사전 조사 110
__4.6.2 카이트러너로 API 엔드포인트 발견 111
__4.6.3 닉토로 취약점 검색 113
__4.6.4 OWASP ZAP으로 취약점 검색 114
__4.6.5 W퍼즈와 퍼징 115
__4.6.6 아르준으로 HTTP 매개변수 발견 117
요약 118
실험실 #1: REST API에서 사용자 계정 열거 118

CHAPTER 5 취약한 API 대상 설정 123
5.1 리눅스 호스트 생성 124
5.2 도커와 도커 컴포즈 설치 124
5.3 취약한 애플리케이션 설치 125
__5.3.1 crAPI 125
__5.3.2 픽시 126
__5.3.3 OWASP 주스 숍 127
__5.3.4 DVGA 128
5.4 기타 취약한 애플리케이션 추가 129
5.5 트라이핵미와 핵더박스에서의 API 해킹 130
요약 131
실험실 #2: 취약한 API 발견 132

PART III API 공격

CHAPTER 6 발견 139
6.1 수동적 사전 조사 140
__6.1.1 수동적 사전 조사 절차 140
__6.1.2 구글 해킹 141
__6.1.3 프로그래머블웹의 API 검색 디렉터리 143
__6.1.4 쇼단 146
__6.1.5 OWASP 어매스 147
__6.1.6 깃허브에 노출된 정보 150
6.2 능동적 사전 조사 153
__6.2.1 능동적 사전 조사 절차 154
__6.2.2 Nmap을 통한 기본 스캔 156
__6.2.3 Robots.txt에서 숨겨진 경로 발견 157
__6.2.4 크롬 개발자 도구로 민감한 정보 발견 157
__6.2.5 버프 스위트로 API 검사 162
__6.2.6 OWASP ZAP과 URI 크롤링 162
__6.2.7 고버스터를 사용한 URI 무차별 대입 165
__6.2.8 카이트러너로 API 콘텐츠 검색 166
요약 168
실험실 #3: 블랙 박스 테스트를 위한 능동적 사전 조사 169

CHAPTER 7 엔드포인트 분석 175
7.1 요청 정보 찾기 176
__7.1.1 문서에서 정보 찾기 176
__7.1.2 API 명세 임포트 180
__7.1.3 API 리버스 엔지니어링 182
7.2 포스트맨에 API 인증 요건 추가 185
7.3 기능 분석 187
__7.3.1 의도에 맞는 사용인지 테스트 188
__7.3.2 권한이 필요한 작업 수행 189
__7.3.3 API 응답 분석 191
7.4 정보 누출 191
7.5 보안 설정 결함 192
__7.5.1 자세한 에러 메시지 192
__7.5.2 빈약한 전송 암호화 193
__7.5.3 문제가 있는 설정 193
7.6 데이터 과다 노출 194
7.7 비즈니스 로직 결함 195
요약 196
실험실 #4: crAPI 컬렉션 구축과 데이터 과다 노출 발견 196

CHAPTER 8 인증 공격 201
8.1 고전적 인증 공격 202
__8.1.1 비밀번호 무차별 대입 공격 202
__8.1.2 비밀번호 리셋과 다중 인증 무차별 대입 공격 203
__8.1.3 비밀번호 스프레이 205
__8.1.4 무차별 대입 공격에 base64 인증 포함 208
8.2 토큰 위조 209
__8.2.1 수동 분석 210
__8.2.2 실시간 캡처 분석 212
__8.2.3 예측 가능한 토큰 무차별 대입 213
8.3 JWT 악용 216
__8.3.1 JWT 분석 216
__8.3.2 none 공격 219
__8.3.3 알고리즘 스위치 공격 219
__8.3.4 JWT 크랙 공격 221
요약 221
실험실 #5: crAPI JWT 서명 크랙 222

CHAPTER 9 퍼징 225
9.1 효과적인 퍼징 225
__9.1.1 퍼징 페이로드 선택 227
__9.1.2 이상 감지 229
9.2 넓은 퍼징과 깊은 퍼징 231
__9.2.1 포스트맨과 넓은 퍼징 232
__9.2.2 버프 스위트와 깊은 퍼징 235
__9.2.3 W퍼즈와 깊은 퍼징 237
9.3 W퍼즈로 요청 메서드 테스트 241
9.4 입력 유효성 검사를 우회하는 ‘더 깊은’ 퍼징 242
9.5 퍼징과 디렉터리 순회 244
요약 244
실험실 #6: 부적절한 자원 관리 취약점 퍼징 245

CHAPTER 10 권한 공격 249
10.1 BOLA 찾기 249
__10.1.1 ID 탐색 250
__10.1.2 A-B 테스트 252
__10.1.3 부채널 BOLA 252
10.2 BFLA 찾기 253
__10.2.1 A-B-A 테스트 254
__10.2.2 포스트맨에서 BFLA 테스트 254
10.3 권한 부여 해킹 팁 257
__10.3.1 포스트맨의 컬렉션 변수 257
__10.3.2 버프 스위트의 찾아 바꾸기 257
요약 258
실험실 #7: 다른 사용자의 자동차 위치 발견 258

CHAPTER 11 대량 할당 265
11.1 대량 할당 대상 발견 265
__11.1.1 계정 등록 266
__11.1.2 권한 없는 접근 266
11.2 대량 할당 변수 발견 267
__11.2.1 문서에서 변수 발견 267
__11.2.2 알 수 없는 변수 퍼징 268
__11.2.3 맹목적 대량 할당 공격 269
11.3 아르준, 버프 스위트 침입자로 대량 할당 공격 자동화 270
11.4 BFLA와 대량 할당 조합 271
요약 272
실험실 #8: 온라인 상점의 아이템 가격 변경 273

CHAPTER 12 주입 279
12.1 주입 취약점 발견 280
12.2 사이트 간 스크립팅(XSS) 281
12.3 API 간 스크립팅(XAS) 282
12.4 SQL 주입 284
__12.4.1 메타 문자 직접 전송 285
__12.4.2 SQL맵 286
12.5 NoSQL 주입 288
12.6 운영 체제 명령어 주입 290
요약 292
실험실 #9: NoSQL 주입을 사용한 쿠폰 위조 293

PART IV 실전 API 해킹

CHAPTER 13 우회 기술과 속도 제한 테스트 299
13.1 API 보안 컨트롤 우회 300
__13.1.1 보안 컨트롤의 작동 방식 300
__13.1.2 API 보안 컨트롤 탐지 301
__13.1.3 버너 계정 사용 302
__13.1.4 우회 기술 303
__13.1.5 버프 스위트로 우회 자동화 305
__13.1.6 W퍼즈로 우회 자동화 307
13.2 속도 제한 테스트 309
__13.2.1 느슨한 속도 제한에 대한 노트 310
__13.2.2 경로 우회 312
__13.2.3 출처 헤더 위조 313
__13.2.4 버프 스위트에서 IP 주소 순환 314
요약 318

CHAPTER 14 그래프QL 공격 319
14.1 그래프QL 요청과 IDE 320
14.2 능동적 사전 조사 321
__14.2.1 스캐닝 321
__14.2.2 브라우저에서 DVGA 사용 323
__14.2.3 개발자 도구 사용 323
14.3 그래프QL API 리버스 엔지니어링 325
__14.3.1 그래프QL 엔드포인트에 디렉터리 무차별 대입 325
__14.3.2 쿠키 변조를 통한 그래피클 IDE 활성화 328
__14.3.3 그래프QL 요청 리버스 엔지니어링 330
__14.3.4 스키마 확인을 통한 그래프QL 컬렉션 리버스 엔지니어링 332
14.4 그래프QL API 분석 333
__14.4.1 그래피클 문서 탐색기를 통한 요청 작성 333
__14.4.2 버프 스위트 애드온 InQL 335
14.5 명령어 주입을 위한 퍼징 338
요약 344

CHAPTER 15 데이터 침해와 버그 현상금 345
15.1 침해 346
__15.1.1 펠로톤 346
__15.1.2 USPS Informed Visibility API 348
__15.1.3 T-모바일 API 침해 349
15.2 현상금 351
__15.2.1 API 키의 가격 352
__15.2.2 비공개 API 권한 부여 문제 353
__15.2.3 스타벅스: 전례 없는 침해 355
__15.2.4 인스타그램 그래프QL BOLA 357
요약 359

마치며 360

부록 A API 해킹 체크리스트 362
부록 B 추가 자료 364
찾아보기 368

예제 1-2는 트위터 웹 서버가 성공적인 인증 요청에 302 응답을 보낸 결과입니다. set-cookie 헤더의 auth_token은 hAPI_hacker라는 트위터 계정과 연결된 데이터에 대한 접근을 승인합니다. / 웹 서버는 요청에 응답할 때 응답 메시지와 함께 상태 코드를 보냅니다. 응답 코드는 웹 서버가 요청을 어떻게 처리했는지 나타내는 방법이며, 간단히 말해 클라이언트가 데이터에 접근할 수 있는지 없는지 나타냅니다. 또한 요청한 자원이 존재하지 않거나, 웹 서버에 문제가 있거나, 요청한 자원이 다른 위치로 이동했음을 나타내기도 합니다.

BOLA(broken object level authorization, 객체 수준 권한 부여 결함)는 API에서 가장 흔한 취약점 중 하나입니다. BOLA 취약점은 API 공급자가 접근 권한이 없는 데이터에 대한 접근을 허용할 때 발생합니다. API 엔드포인트에 객체 수준 접근 제어가 없다면 사용자가 권한 있는 데이터에만 접근하도록 제한할 수 없으므로 사용자 A가 사용자 B의 데이터를 요청할 수 있게 됩니다. / API는 이름이나 숫자로 일종의 값을 만들어 객체 식별에 사용합니다. 이런 객체 ID를 발견하면 인증되지 않은 상태, 또는 다른 사용자로 인증된 상태에서 그 자원에 접근할 수 있는지 확인해봐야 합니다. 예를 들어 클라우드 스트라이프(Cloud Strife)라는 사용자가 있다고 합시다. 클라우드가 httpss://bestgame.com/api/v3/users?id=5501에 GET 요청을 보내고 다음과 같은 응답을 받았습니다.