API 보안테스트 범위를 정하기 위해서는 방법론, 테스트 규모, 대상 기능, 테스트 제한, 보고서 작성 요건, 개선 테스트 진행 여부같은 몇 가지 요인을 결정해야한다.
API 침투 순서
1. 권한 받기
API 공격하기 전 공격범위를 명확히 정하고 정해진 시간동안 클라이언트를 공격해도 된다는 권한 부여 계약서에 서명을 받아야한다. 즉 해커가 아닌 보안태스트를 위한 침투계획에는 명확히 대표혹은 챔임자와 상의하에 권한을 부여받고 어떤일이 벌어질지 어떻게 침투할지에 대한 조율 및 협의가 이루어져야한다.
2. API 테스트의 위협 모델링
위협 모델링은 API 공급자에 대한 위협을 모델화하는 프로세스입니다. 관련된 위협을 기반으로 API 침투 테스트모델을 만들어 해당 공격에 대응책을 마련할 수 있도록 위협들을 모델링하는것이다.
API에 할 수 있는 최선의 테스트는 API 공급자에게 가해지는 위협에 대한 테스트이다. API 보안에 도움이 되도록 테스트하려면 공격할만한 적들을 찾고 그들의 해킹태크닉까지 상정하는게 이상적이다.
침투테스트의 접근방식
- 블랙 박스
- 소스코드나 내부 문서나 표면 정보가 공개되지 않은 상태에서 오는 공격
- 우연히 찾아온 공격자의 위협을 모델
- 공격자는 오픈소스 인텔리전스를 통해 조직에 대한 정보를 가능한 확보할것
- 그레이 박스
- 블랙박스 보다는 보다 많은 정보를 제공받아서 더 많은 정보를 가진 공격자 흉내를 낸다.
- API문서도 제공받고 때로는 계정을 받을때도 있다. 아님 일부 네트워크 보안을 건너뛰도록 권한을 부여받아서 상황을 연출한다.
- 화이트 박스
- 가능한 모든 정보를 제공받아서 소프트웨어의 설계도를 보고 공격을 하는것이다. 정보가 많을수록 공격포인트를 철저히 테스트할 수 있다
위 접근방식중 어떤것을 선택할지는 위협 모델과 위협 인텔리전스를 근거로 결정해야한다. 즉 공격자 후보 프로파일을 만들어 그에 적합한 사이즈의 모델을 구성한다. "닭 잡는데 소잡는칼"쓰지말라는 뜻인 것 같다. 이 부분은 프로그래머라면 중요한 역량이라 생각한다.
3. 테스트해야할 API 기능
보안 테스트 범위를 정하며 해야 할 일의 양을 산정해보는것도 중요하다.
API 인증/권한부여 테스트
API 약점중 상당수는 인증/권한 부여과정에서 발견된다.
웹 애플리케이션 방화벽(WAF)
WAF는 API에 도달하는 트레픽을 제어하는 장치다. 그레이 박스나 화이트 박스 테스트에서는 클라이언트가 WAF 존재를 공개할 가능성이 높고 이때 효율적으로 보호를 위해서는 방어를 여러 겹으로 구성해야한다. 즉 하나에 의존했다가 하나가 뚫리면 큰일이 난다는 예기가 된다. 테스트를 할때는 경계 보안 수준을 다소 낮춰서 API 사용자에게 노출되는 보안 컨트롤을 테스트할 수 있게 하는게 이상적이다. 너무 WAF를 빡빡하게 해버리면 API공급자가 API보안을 잘 유지했는지 테스트를 하는게 아니라 WAF만 테스트하다가 끝날 수 있다.
모바일 애플리케이션 테스트
직접 분석과 동적분석이 있는데 직접분석은 소스코드를 직접 읽고 잡재적 취약점을 찾아내는 작업 동적 분석은 실행중인 애플리케이션을 테스트하는 것이다. API응답을 가로채 악용할 수 있는 약점이 있는지 찾아보는 시도가 된다.
속도 제한 테스트
RateLimit의 목표는 크게 두가지가 있는데 API를 통한 수익창출, 둘째는 공급자의 자원을 지나치게 소모하는 것을 막는 목적을 가진다. DOS테스트와는 다른데 DOS테스트는 서비스를 방해하고 사용자가 소프트웨어를 사용할수 없게만드는 의도가 있지만 속도 제한테스트는 규칙을 우회하는 방법을 찾는것이다.
4. 제한과 제외
위 방법들 중 권한 부여 문서에 DoS 공격이나 DDoS공격이 명시되지 않으면 실행해선 안된다. 시스템에 직접적 영향을 주기때문. 대부분의 침투테스트에서는 사용자의 데이터, 소셜 엔지니어링, DoS,DDoS, 고객에대한 공격에 대한 부분들은 허용하지 않는다.
5. 보고, 개선, 테스트
침투이후 발견된 취약점, 개선점들을 보고하고 개선시켜나가서 보안적인 완성도를 높여나간다.