코더 컨커 시큐리티 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를 사용할 수 없게 되거나 새 요청에 응답하지 않을 수 있습니다.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
리소스 부족과 속도 제한으로 인해 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 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
리소스 부족과 속도 제한으로 인해 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 교육 플랫폼을 통해 모든 사이버 보안 기술을 연마하고 최신 상태로 유지할 수 있습니다.
목차
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약다운로드시작하는 데 도움이 되는 리소스
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
