코더 컨커 시큐리티 OWASP Top 10 API 시리즈 - 리소스 부족 및 속도 제한
리소스 부족과 속도 제한으로 인해 API 취약점은 제목에서 설명한 것과 거의 동일하게 작용합니다.모든 API는 환경에 따라 사용 가능한 리소스와 컴퓨팅 성능이 제한되어 있습니다.또한 대부분은 원하는 기능을 수행하도록 요청하는 사용자나 다른 프로그램의 요청을 처리해야 합니다.이 취약성은 동시에 너무 많은 요청이 들어오고 API에 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않을 때 발생합니다.그러면 API를 사용할 수 없게 되거나 새 요청에 응답하지 않을 수 있습니다.
속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 API는 이 문제에 취약해집니다.그러면 예를 들어 비즈니스가 특히 바쁜 시기에 있을 경우 API에 과부하가 걸릴 수 있습니다.하지만 이는 보안 취약점이기도 합니다. 위협 행위자가 의도적으로 보호되지 않은 API에 요청을 과부하시켜 DDoS (서비스 거부) 공격을 수행할 수 있기 때문입니다.
그나저나, 지금까지의 API 게임화 과제는 어떻게 다루고 계신가요?속도 제한 취약점을 처리하는 기술을 지금 바로 시험해보고 싶다면, 다음 단계로 들어가 보세요.
이제 좀 더 깊이 들어가 보겠습니다.
리소스 부족 및 속도 제한 API 취약점의 몇 가지 예는 무엇입니까?
이 취약점이 API에 침투할 수 있는 두 가지 방법이 있습니다.첫 번째는 코더가 API의 스로틀 속도를 간단히 정의하지 않는 경우입니다.인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만, 이에 의존하는 것은 좋은 정책이 아닙니다.대신 각 API의 속도를 개별적으로 설정해야 합니다.API는 사용 가능한 리소스뿐만 아니라 기능도 크게 다를 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 서비스를 제공하도록 설계된 내부 API는 스로틀 속도가 매우 낮고 제대로 작동할 수 있습니다.하지만 실시간 전자상거래 사이트의 일부인 공개 API의 경우 동시 사용자 급증 가능성을 상쇄하기 위해 예외적으로 높은 비율을 정의해야 할 가능성이 높습니다.두 경우 모두 예상 요구 사항, 잠재 사용자 수, 사용 가능한 컴퓨팅 파워를 기반으로 스로틀링 비율을 정의해야 합니다.
특히 사용량이 매우 많은 API의 경우 성능을 극대화하기 위해 속도를 무제한으로 설정하고 싶을 수 있습니다.간단한 코드만으로 이 작업을 수행할 수 있습니다 (예를 들어, 다음을 사용하겠습니다. 파이썬 장고 REST 프레임워크):
“기본_스로틀_속도: {
“캐논: 없음,
“사용자: 없음
이 예시에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간 경과에 따른 요청 수에 관계없이 무제한으로 API에 접속할 수 있습니다.이는 좋지 않은 생각입니다. 왜냐하면 API가 사용할 수 있는 컴퓨팅 리소스가 아무리 많아도 공격자는 봇넷과 같은 것을 배포하여 결국 크롤링 속도를 늦추거나 아예 오프라인 상태로 만들 수 있기 때문입니다.이 경우 유효한 사용자의 액세스가 거부되고 공격은 성공할 수 있습니다.
리소스 부족 및 속도 제한 문제 해결
조직에서 배포하는 모든 API에는 코드에 스로틀 비율이 정의되어 있어야 합니다.여기에는 실행 제한 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수, 정의된 기간 내에 허용된 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 볼 수 있듯이 스로틀링 비율을 그대로 두지 않고 익명 사용자와 알려진 사용자에 대해 서로 다른 요율로 엄격하게 정의할 수 있습니다.
“기본_스로틀_속도: {
“anon: 구성 (“스로틀_애논, 기본값=200/시간),
“사용자: 구성 (“스로틀_사용자, 기본값=5000/시간)
새 예제에서 API는 익명 사용자가 시간당 200건의 요청을 하도록 제한합니다.이미 시스템의 심사를 거친 알려진 사용자에게는 시간당 5,000건의 요청으로 더 많은 여유가 주어집니다.하지만 피크 타임에 발생하는 우발적인 과부하를 방지하거나 사용자 계정이 도용되어 서비스 거부 공격에 이용되는 경우를 보상하기 위한 목적으로도 제한적입니다.
마지막으로 고려해야 할 사항으로, 사용자가 스로틀링 한도에 도달하면 해당 제한이 재설정되는 시기에 대한 설명과 함께 사용자에게 알림을 표시하는 것이 좋습니다.이렇게 하면 유효한 사용자는 애플리케이션에서 요청을 거부하는 이유를 알 수 있습니다.이는 승인된 작업을 수행하는 유효한 사용자의 API 액세스가 거부되는 경우에도 유용할 수 있습니다. 이는 운영 담당자에게 전송률 제한을 늘려야 한다는 신호를 보낼 수 있기 때문입니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 Secure Code Warrior 교육 플랫폼을 통해 모든 사이버 보안 기술을 연마하고 최신 상태로 유지할 수 있습니다.
이 취약점은 너무 많은 요청이 동시에 들어오고 API에 이러한 요청을 처리하기에 충분한 컴퓨팅 리소스가 없을 때 발생합니다.그러면 API를 사용할 수 없게 되거나 새 요청에 응답하지 않을 수 있습니다.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
리소스 부족과 속도 제한으로 인해 API 취약점은 제목에서 설명한 것과 거의 동일하게 작용합니다.모든 API는 환경에 따라 사용 가능한 리소스와 컴퓨팅 성능이 제한되어 있습니다.또한 대부분은 원하는 기능을 수행하도록 요청하는 사용자나 다른 프로그램의 요청을 처리해야 합니다.이 취약성은 동시에 너무 많은 요청이 들어오고 API에 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않을 때 발생합니다.그러면 API를 사용할 수 없게 되거나 새 요청에 응답하지 않을 수 있습니다.
속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 API는 이 문제에 취약해집니다.그러면 예를 들어 비즈니스가 특히 바쁜 시기에 있을 경우 API에 과부하가 걸릴 수 있습니다.하지만 이는 보안 취약점이기도 합니다. 위협 행위자가 의도적으로 보호되지 않은 API에 요청을 과부하시켜 DDoS (서비스 거부) 공격을 수행할 수 있기 때문입니다.
그나저나, 지금까지의 API 게임화 과제는 어떻게 다루고 계신가요?속도 제한 취약점을 처리하는 기술을 지금 바로 시험해보고 싶다면, 다음 단계로 들어가 보세요.
이제 좀 더 깊이 들어가 보겠습니다.
리소스 부족 및 속도 제한 API 취약점의 몇 가지 예는 무엇입니까?
이 취약점이 API에 침투할 수 있는 두 가지 방법이 있습니다.첫 번째는 코더가 API의 스로틀 속도를 간단히 정의하지 않는 경우입니다.인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만, 이에 의존하는 것은 좋은 정책이 아닙니다.대신 각 API의 속도를 개별적으로 설정해야 합니다.API는 사용 가능한 리소스뿐만 아니라 기능도 크게 다를 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 서비스를 제공하도록 설계된 내부 API는 스로틀 속도가 매우 낮고 제대로 작동할 수 있습니다.하지만 실시간 전자상거래 사이트의 일부인 공개 API의 경우 동시 사용자 급증 가능성을 상쇄하기 위해 예외적으로 높은 비율을 정의해야 할 가능성이 높습니다.두 경우 모두 예상 요구 사항, 잠재 사용자 수, 사용 가능한 컴퓨팅 파워를 기반으로 스로틀링 비율을 정의해야 합니다.
특히 사용량이 매우 많은 API의 경우 성능을 극대화하기 위해 속도를 무제한으로 설정하고 싶을 수 있습니다.간단한 코드만으로 이 작업을 수행할 수 있습니다 (예를 들어, 다음을 사용하겠습니다. 파이썬 장고 REST 프레임워크):
“기본_스로틀_속도: {
“캐논: 없음,
“사용자: 없음
이 예시에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간 경과에 따른 요청 수에 관계없이 무제한으로 API에 접속할 수 있습니다.이는 좋지 않은 생각입니다. 왜냐하면 API가 사용할 수 있는 컴퓨팅 리소스가 아무리 많아도 공격자는 봇넷과 같은 것을 배포하여 결국 크롤링 속도를 늦추거나 아예 오프라인 상태로 만들 수 있기 때문입니다.이 경우 유효한 사용자의 액세스가 거부되고 공격은 성공할 수 있습니다.
리소스 부족 및 속도 제한 문제 해결
조직에서 배포하는 모든 API에는 코드에 스로틀 비율이 정의되어 있어야 합니다.여기에는 실행 제한 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수, 정의된 기간 내에 허용된 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 볼 수 있듯이 스로틀링 비율을 그대로 두지 않고 익명 사용자와 알려진 사용자에 대해 서로 다른 요율로 엄격하게 정의할 수 있습니다.
“기본_스로틀_속도: {
“anon: 구성 (“스로틀_애논, 기본값=200/시간),
“사용자: 구성 (“스로틀_사용자, 기본값=5000/시간)
새 예제에서 API는 익명 사용자가 시간당 200건의 요청을 하도록 제한합니다.이미 시스템의 심사를 거친 알려진 사용자에게는 시간당 5,000건의 요청으로 더 많은 여유가 주어집니다.하지만 피크 타임에 발생하는 우발적인 과부하를 방지하거나 사용자 계정이 도용되어 서비스 거부 공격에 이용되는 경우를 보상하기 위한 목적으로도 제한적입니다.
마지막으로 고려해야 할 사항으로, 사용자가 스로틀링 한도에 도달하면 해당 제한이 재설정되는 시기에 대한 설명과 함께 사용자에게 알림을 표시하는 것이 좋습니다.이렇게 하면 유효한 사용자는 애플리케이션에서 요청을 거부하는 이유를 알 수 있습니다.이는 승인된 작업을 수행하는 유효한 사용자의 API 액세스가 거부되는 경우에도 유용할 수 있습니다. 이는 운영 담당자에게 전송률 제한을 늘려야 한다는 신호를 보낼 수 있기 때문입니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 Secure Code Warrior 교육 플랫폼을 통해 모든 사이버 보안 기술을 연마하고 최신 상태로 유지할 수 있습니다.
리소스 부족과 속도 제한으로 인해 API 취약점은 제목에서 설명한 것과 거의 동일하게 작용합니다.모든 API는 환경에 따라 사용 가능한 리소스와 컴퓨팅 성능이 제한되어 있습니다.또한 대부분은 원하는 기능을 수행하도록 요청하는 사용자나 다른 프로그램의 요청을 처리해야 합니다.이 취약성은 동시에 너무 많은 요청이 들어오고 API에 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않을 때 발생합니다.그러면 API를 사용할 수 없게 되거나 새 요청에 응답하지 않을 수 있습니다.
속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 API는 이 문제에 취약해집니다.그러면 예를 들어 비즈니스가 특히 바쁜 시기에 있을 경우 API에 과부하가 걸릴 수 있습니다.하지만 이는 보안 취약점이기도 합니다. 위협 행위자가 의도적으로 보호되지 않은 API에 요청을 과부하시켜 DDoS (서비스 거부) 공격을 수행할 수 있기 때문입니다.
그나저나, 지금까지의 API 게임화 과제는 어떻게 다루고 계신가요?속도 제한 취약점을 처리하는 기술을 지금 바로 시험해보고 싶다면, 다음 단계로 들어가 보세요.
이제 좀 더 깊이 들어가 보겠습니다.
리소스 부족 및 속도 제한 API 취약점의 몇 가지 예는 무엇입니까?
이 취약점이 API에 침투할 수 있는 두 가지 방법이 있습니다.첫 번째는 코더가 API의 스로틀 속도를 간단히 정의하지 않는 경우입니다.인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만, 이에 의존하는 것은 좋은 정책이 아닙니다.대신 각 API의 속도를 개별적으로 설정해야 합니다.API는 사용 가능한 리소스뿐만 아니라 기능도 크게 다를 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 서비스를 제공하도록 설계된 내부 API는 스로틀 속도가 매우 낮고 제대로 작동할 수 있습니다.하지만 실시간 전자상거래 사이트의 일부인 공개 API의 경우 동시 사용자 급증 가능성을 상쇄하기 위해 예외적으로 높은 비율을 정의해야 할 가능성이 높습니다.두 경우 모두 예상 요구 사항, 잠재 사용자 수, 사용 가능한 컴퓨팅 파워를 기반으로 스로틀링 비율을 정의해야 합니다.
특히 사용량이 매우 많은 API의 경우 성능을 극대화하기 위해 속도를 무제한으로 설정하고 싶을 수 있습니다.간단한 코드만으로 이 작업을 수행할 수 있습니다 (예를 들어, 다음을 사용하겠습니다. 파이썬 장고 REST 프레임워크):
“기본_스로틀_속도: {
“캐논: 없음,
“사용자: 없음
이 예시에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간 경과에 따른 요청 수에 관계없이 무제한으로 API에 접속할 수 있습니다.이는 좋지 않은 생각입니다. 왜냐하면 API가 사용할 수 있는 컴퓨팅 리소스가 아무리 많아도 공격자는 봇넷과 같은 것을 배포하여 결국 크롤링 속도를 늦추거나 아예 오프라인 상태로 만들 수 있기 때문입니다.이 경우 유효한 사용자의 액세스가 거부되고 공격은 성공할 수 있습니다.
리소스 부족 및 속도 제한 문제 해결
조직에서 배포하는 모든 API에는 코드에 스로틀 비율이 정의되어 있어야 합니다.여기에는 실행 제한 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수, 정의된 기간 내에 허용된 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 볼 수 있듯이 스로틀링 비율을 그대로 두지 않고 익명 사용자와 알려진 사용자에 대해 서로 다른 요율로 엄격하게 정의할 수 있습니다.
“기본_스로틀_속도: {
“anon: 구성 (“스로틀_애논, 기본값=200/시간),
“사용자: 구성 (“스로틀_사용자, 기본값=5000/시간)
새 예제에서 API는 익명 사용자가 시간당 200건의 요청을 하도록 제한합니다.이미 시스템의 심사를 거친 알려진 사용자에게는 시간당 5,000건의 요청으로 더 많은 여유가 주어집니다.하지만 피크 타임에 발생하는 우발적인 과부하를 방지하거나 사용자 계정이 도용되어 서비스 거부 공격에 이용되는 경우를 보상하기 위한 목적으로도 제한적입니다.
마지막으로 고려해야 할 사항으로, 사용자가 스로틀링 한도에 도달하면 해당 제한이 재설정되는 시기에 대한 설명과 함께 사용자에게 알림을 표시하는 것이 좋습니다.이렇게 하면 유효한 사용자는 애플리케이션에서 요청을 거부하는 이유를 알 수 있습니다.이는 승인된 작업을 수행하는 유효한 사용자의 API 액세스가 거부되는 경우에도 유용할 수 있습니다. 이는 운영 담당자에게 전송률 제한을 늘려야 한다는 신호를 보낼 수 있기 때문입니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 Secure Code Warrior 교육 플랫폼을 통해 모든 사이버 보안 기술을 연마하고 최신 상태로 유지할 수 있습니다.
아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
리소스 부족과 속도 제한으로 인해 API 취약점은 제목에서 설명한 것과 거의 동일하게 작용합니다.모든 API는 환경에 따라 사용 가능한 리소스와 컴퓨팅 성능이 제한되어 있습니다.또한 대부분은 원하는 기능을 수행하도록 요청하는 사용자나 다른 프로그램의 요청을 처리해야 합니다.이 취약성은 동시에 너무 많은 요청이 들어오고 API에 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않을 때 발생합니다.그러면 API를 사용할 수 없게 되거나 새 요청에 응답하지 않을 수 있습니다.
속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 API는 이 문제에 취약해집니다.그러면 예를 들어 비즈니스가 특히 바쁜 시기에 있을 경우 API에 과부하가 걸릴 수 있습니다.하지만 이는 보안 취약점이기도 합니다. 위협 행위자가 의도적으로 보호되지 않은 API에 요청을 과부하시켜 DDoS (서비스 거부) 공격을 수행할 수 있기 때문입니다.
그나저나, 지금까지의 API 게임화 과제는 어떻게 다루고 계신가요?속도 제한 취약점을 처리하는 기술을 지금 바로 시험해보고 싶다면, 다음 단계로 들어가 보세요.
이제 좀 더 깊이 들어가 보겠습니다.
리소스 부족 및 속도 제한 API 취약점의 몇 가지 예는 무엇입니까?
이 취약점이 API에 침투할 수 있는 두 가지 방법이 있습니다.첫 번째는 코더가 API의 스로틀 속도를 간단히 정의하지 않는 경우입니다.인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만, 이에 의존하는 것은 좋은 정책이 아닙니다.대신 각 API의 속도를 개별적으로 설정해야 합니다.API는 사용 가능한 리소스뿐만 아니라 기능도 크게 다를 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 서비스를 제공하도록 설계된 내부 API는 스로틀 속도가 매우 낮고 제대로 작동할 수 있습니다.하지만 실시간 전자상거래 사이트의 일부인 공개 API의 경우 동시 사용자 급증 가능성을 상쇄하기 위해 예외적으로 높은 비율을 정의해야 할 가능성이 높습니다.두 경우 모두 예상 요구 사항, 잠재 사용자 수, 사용 가능한 컴퓨팅 파워를 기반으로 스로틀링 비율을 정의해야 합니다.
특히 사용량이 매우 많은 API의 경우 성능을 극대화하기 위해 속도를 무제한으로 설정하고 싶을 수 있습니다.간단한 코드만으로 이 작업을 수행할 수 있습니다 (예를 들어, 다음을 사용하겠습니다. 파이썬 장고 REST 프레임워크):
“기본_스로틀_속도: {
“캐논: 없음,
“사용자: 없음
이 예시에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간 경과에 따른 요청 수에 관계없이 무제한으로 API에 접속할 수 있습니다.이는 좋지 않은 생각입니다. 왜냐하면 API가 사용할 수 있는 컴퓨팅 리소스가 아무리 많아도 공격자는 봇넷과 같은 것을 배포하여 결국 크롤링 속도를 늦추거나 아예 오프라인 상태로 만들 수 있기 때문입니다.이 경우 유효한 사용자의 액세스가 거부되고 공격은 성공할 수 있습니다.
리소스 부족 및 속도 제한 문제 해결
조직에서 배포하는 모든 API에는 코드에 스로틀 비율이 정의되어 있어야 합니다.여기에는 실행 제한 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수, 정의된 기간 내에 허용된 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 볼 수 있듯이 스로틀링 비율을 그대로 두지 않고 익명 사용자와 알려진 사용자에 대해 서로 다른 요율로 엄격하게 정의할 수 있습니다.
“기본_스로틀_속도: {
“anon: 구성 (“스로틀_애논, 기본값=200/시간),
“사용자: 구성 (“스로틀_사용자, 기본값=5000/시간)
새 예제에서 API는 익명 사용자가 시간당 200건의 요청을 하도록 제한합니다.이미 시스템의 심사를 거친 알려진 사용자에게는 시간당 5,000건의 요청으로 더 많은 여유가 주어집니다.하지만 피크 타임에 발생하는 우발적인 과부하를 방지하거나 사용자 계정이 도용되어 서비스 거부 공격에 이용되는 경우를 보상하기 위한 목적으로도 제한적입니다.
마지막으로 고려해야 할 사항으로, 사용자가 스로틀링 한도에 도달하면 해당 제한이 재설정되는 시기에 대한 설명과 함께 사용자에게 알림을 표시하는 것이 좋습니다.이렇게 하면 유효한 사용자는 애플리케이션에서 요청을 거부하는 이유를 알 수 있습니다.이는 승인된 작업을 수행하는 유효한 사용자의 API 액세스가 거부되는 경우에도 유용할 수 있습니다. 이는 운영 담당자에게 전송률 제한을 늘려야 한다는 신호를 보낼 수 있기 때문입니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 Secure Code Warrior 교육 플랫폼을 통해 모든 사이버 보안 기술을 연마하고 최신 상태로 유지할 수 있습니다.
목차
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약다운로드
%20(1).avif)
.avif)
