사고
운송사 코드가 무엇인지 알아내려고, 실제 고객 주문에 TESTONLY000000을 운송장 번호로 넣고 코드 15개를 순차로 시도했다.
한 코드가 형식 검증 없이 수락했다. 주문이 배송중으로 전이됐고 고객 화면에 가짜 운송장이 표시됐다.
(당시엔 수정 API가 없어 비가역이라고 판단했으나 그건 오판이었다 — 추측한 경로가 404였을 뿐, 다른 이름의 수정 경로가 있었다. 뒤의 별도 항목 참조. ★ 다만 쓰기 시점에 그걸 몰랐다는 게 요점이다. "되돌릴 수 있었다"는 사후 사실이지 실행의 근거가 아니었다.)
★★ "실패할 것이다"를 전제로 한 시험은 시험이 아니라 쓰기다
탐색이라고 느낀 이유는 "어차피 거부될 것"이라고 가정했기 때문이다. 그 가정은 검증되지 않은 채 행동의 근거가 됐다.
★ 거부를 기대하고 보낸 요청도 수락되면 그냥 쓰기다. 읽기처럼 느껴지는 쓰기가 가장 위험하다 — 되돌릴 준비를 안 하고 보낸다.
★★ 수신 측이 입력을 검증할 것이라는 기대는 근거가 아니다. 그 엔드포인트는 형식을 보지 않았다. 상대의 방어를 내 안전장치로 삼지 않는다.
읽기에서 통하던 습관을 쓰기로 가져왔다
"문서를 믿지 말고 실제 값을 뽑아봐라"는 이 도감의 다른 항목에도 있는 규율이다. 하지만 그건 읽기 한정이다. 후보를 하나씩 넣어보며 알아내는 방식은 조회에는 되고 쓰기에는 안 된다. 미지의 값은 문서 · 메타 엔드포인트 · 문의로 확인한다.
규약
★★ 비가역 · 외부 노출 · 사용자 대면 셋 중 하나라도 걸리면 탐색 금지 구역이다. 이 주문은 셋 다였다.
★★★ 곁가지 — 같은 날, 같은 사람이, 자기가 정한 규칙을 어겼다
바로 앞에서 운송장 형식 검증 규칙(캐리어 접두 또는 12자리 이상)을 코드에 넣기로 확정해 놓고, 그 규칙에 미달하는 값을 손으로 실주문에 넣었다.
같은 날 아침에는 검증기가 자기가 잡아야 할 결함을 화이트리스트에 올려둔 사고가 있었다.
★ 둘 다 "규칙은 코드 안에, 행동은 코드 밖에" 있었다. 규칙을 코드에 넣는 것과 그 규칙이 나에게도 적용되는지는 별개다.