메인 콘텐츠로 건너뛰기
블로그보안섀도 API에 대해 잘 모르시나요?

섀도 API에 대해 잘 모르시나요?

바닥만 보일 뿐 대부분 어둠 속에 놓여 있는 불길해 보이는 방입니다. "어둠 속에서 섀도 API에 대해 알고 계십니까?"라는 문구가 적혀 있습니다.

API 개발 경험이 많은 분들에게도 섀도 API와 섀도 API 매개변수에 대한 질문을 자주 받습니다. 섀도 API는 일반적으로 API를 개발하는 과정에서 생각할 수 있는 위험이 아니기 때문에 이는 그리 놀라운 일이 아닙니다. 실제로 일부 사람들은 섀도 API가 보안 벤더가 도구를 판매하기 위해 사용하는 겁주기 전술에 불과하다고 확신하기도 합니다.

하지만 실제로 섀도 API는 비교적 쉽게 빌드하고 사용할 수 있습니다. 그렇다면 섀도 API를 더 잘 이해하는 가장 좋은 방법은 무엇일까요? 바로 실제 사례를 살펴보는 것입니다! 그래서 이 글에서 섀도 API에 대해 다뤄보겠습니다.

섀도 API란 무엇인가요?

제가 발견한 이 API 요청 예시부터 살펴보겠습니다:

웹 서비스 인증에 사용되는 일회용 비밀번호(OTP)를 생성하기 위한 GraphQL API에 대한 요청입니다. 자세히 살펴보지 않으면 문제를 발견하지 못할 수 있으므로 큰 빨간색 화살표로 표시해 두었습니다. 그 otpDigit 매개변수는 실제로 큰 문제입니다.

이 매개변수는 실제로 API를 통해 수정할 수 있다는 것을 알게 되었습니다. 이 매개변수를 수정하면 인증에 필요한 일회용 비밀번호의 길이를 조정할 수 있습니다. 어떤 의미가 있을까요? 값을 다음과 같이 변경할 수 있었습니다. 1. 이로 인해 비밀번호의 가능성은 백만 가지에서 단 10가지로 줄어들었습니다!

당연히 개발팀은 제가 이 매개변수에 대해 이야기했을 때 놀랐고, 곧바로 수정했습니다. 그럼에도 불구하고 이것은 섀도 API와 그 매개 변수의 완벽한 예입니다. 아마도 이 매개 변수는 프로토타입이나 테스트에 사용되는 초기 개발자의 편의성 때문이었을 것입니다. API가 프로덕션 환경으로 전환되었을 때 이 매개변수에 대한 지원은 제거되지 않았고 섀도 API 매개변수가 되었습니다.

이 특정 엔드포인트에서 문서화되지 않은 매개변수로 수행할 수 있는 작업을 누군가 조사하지 않았다면 이 중대한 취약점은 발견되지 않았을 것입니다. 더 중요한 것은 개발팀이 취약점을 발견하기 전까지는 이 취약점을 열심히 검색하지 않는다는 것입니다.

이 예시는 섀도 API 엔드포인트 및 매개변수에 관한 작업 가이드라인의 토대를 마련합니다: 개발자가 직접적으로 주목하지 않는 API 엔드포인트나 매개변수는 섀도우에 존재하며, 보안팀도 이를 간과할 가능성이 높기 때문에 위험합니다.

섀도 API는 어떻게 하나요?

이제 섀도 API 엔드포인트와 매개변수가 무엇인지 알았으니 다음 질문은 이들에 대해 무엇을 할 수 있는지입니다. 개발자가 실제 작업에서 강조하지도 않는 것들에 대해 보안 팀에게 더 경계하라고만 말할 수는 없습니다.

대부분의 경우 API의 보안을 평가하는 데 도움이 되는 도구나 프로세스가 필요할 것입니다. 필요한 도구의 유형은 비즈니스 규모와 배포한 API의 수에 따라 달라집니다. API 게이트웨이 또는 API 보안 도구를 사용하면 필요한 수준의 보안을 확보하는 데 큰 도움이 될 수 있지만, 필요한 것보다 더 많은 도구가 필요할 수도 있습니다. API 소비자가 사용할 수 있는 엔드포인트가 몇 개밖에 없는 경우 스택 전반에서 트래픽을 추적하고 의심스러운 활동을 알려주는 강력한 도구 세트를 배포하는 것은 분명 과잉입니다.

더 간단한 접근 방식은 API가 잘 문서화되어 있는지 확인하는 것입니다. 이것도 시작하기에 좋은 방법입니다. API 문서화를 위해 OpenAPI 표준을 채택하는 것부터 시작하세요. 엔드포인트와 매개변수에 주의를 기울이지 않을 때 섀도 API가 존재한다는 사실을 기억하세요. OpenAPI 표준의 핵심은 API 전반에 걸쳐 모든 엔드포인트와 매개변수를 지정하고 이에 대해 알 수 있는 모델을 제공하는 것입니다.

또한 배포할 때 개발자에게 이 API 문서를 보안 팀에 제공하도록 요청할 수도 있습니다. 그런 다음 보안팀은 문서와 비교하여 API를 테스트하여 부정확하거나 부족한 부분을 찾습니다. 이렇게 하면 사각지대를 방지할 수 있습니다.

결론

그 공간에 빛을 비추면 그림자 속에 숨어 있는 것은 없습니다. 결국 배포한 API의 세부 사항을 알고 있다면 섀도 API는 존재할 수 없습니다. 세상에서 가장 흥미로운 작업은 아니지만 API를 문서화하면 악의적인 공격자에게 API가 공개되는 것을 방지하는 데 도움이 됩니다.

이 포스팅을 통해 섀도 API의 정의와 위험성에 대해 알게 되었기를 바랍니다. Go 보안 침해를 방지하기 위해 API 인프라의 어두운 구석에 빛을 비추세요!

내용

댓글 남기기

이메일 주소는 게시되지 않습니다. 필수 필드가 표시됩니다 *