코더는 보안 OWASP 상위 10 API 시리즈를 정복 - 자원의 부족과 속도 제한
리소스와 속도 제한이 부족하면 API 취약점이 제목에 의해 설명되는 방식과 거의 정확히 일치합니다. 모든 API에는 환경에 따라 리소스와 컴퓨팅 전력이 제한되어 있습니다. 대부분은 원하는 기능을 수행하도록 요청하는 사용자 또는 기타 프로그램의 요청을 필드로 수행해야 합니다. 이 취약점은 너무 많은 요청이 동시에 들어올 때 발생하며 API에는 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않습니다. 그런 다음 API를 사용할 수 없거나 새 요청에 응답하지 못할 수 있습니다.
API는 속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 이 문제에 취약해집니다. 예를 들어 비즈니스에서 특히 바쁜 기간을 경험하는 경우 API를 오버로드할 수 있습니다. 그러나 위협 행위자는 DDoS(서비스 거부) 공격을 수행하기 위해 요청으로 보호되지 않은 API를 의도적으로 과부하시킬 수 있기 때문에 보안 취약점이기도 합니다.
그런데 지금까지 API 게임화 챌린지로 어떻게 하고 있습니까? 지금 당장 취약점을 제한하는 속도 처리 기술을 시도하려면 경기장에 들어갑니다.
이제 좀 더 깊이 살펴보겠습니다.
리소스가 부족하고 API 취약점을 제한하는 속도의 예로는 어떤 예가 있습니까?
이 취약점이 API에 몰래 들어갈 수 있는 방법에는 두 가지가 있습니다. 첫 번째는 코더가 API에 대한 스로틀 속도를 정의하지 않는 경우입니다. 인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만 이에 의존하는 것은 좋은 정책이 아닙니다. 대신 각 API의 요금은 개별적으로 설정되어야 합니다. API는 사용 가능한 리소스뿐만 아니라 매우 다른 기능을 가질 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 제공하도록 설계된 내부 API는 매우 낮은 스로틀 속도를 가질 수 있으며 잘 작동할 수 있습니다. 그러나 실시간 전자 상거래 사이트의 일부인 공용 API는 동시 사용자의 급증 가능성을 보상하기 위해 매우 높은 비율이 정의될 가능성이 큽습니다. 두 경우 모두 제한 속도는 예상 요구 사항, 잠재적 사용자 수 및 사용 가능한 컴퓨팅 성능에 따라 정의되어야 합니다.
특히 매우 바쁠 가능성이 높은 API를 사용하면 성능을 극대화하기 위해 요금을 무제한으로 설정하는 것이 유혹적일 수 있습니다. 이것은 코드의 간단한 비트로 수행 할 수 있습니다 (예를 들어, 우리는 파이썬 장고 REST 프레임 워크를사용합니다):
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
이 예제에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간이 지남에 따라 요청 수와 관계없이 무제한 으로 API에 연락할 수 있습니다. API가 사용할 수 있는 컴퓨팅 리소스의 양에 관계없이 공격자는 봇넷과 같은 리소스를 배포하여 결국 크롤링 속도를 늦추거나 오프라인으로 완전히 노크할 수 있기 때문에 이는 잘못된 생각입니다. 이 경우 유효한 사용자가 액세스가 거부되고 공격이 성공합니다.
자원 부족 및 속도 제한 문제 제거
조직에서 배포하는 모든 API에는 스로틀 요금이 코드에 정의되어야 합니다. 여기에는 실행 시간 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수 또는 정의된 기간 내에 허용되는 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 제한 요금을 크게 열어 두는 대신 익명 및 알려진 사용자에 대해 서로 다른 비율로 엄격하게 정의할 수 있습니다.
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
새 예제에서 API는 익명 사용자가 시간당 200개의 요청을 하는 것으로 제한합니다. 이미 시스템에 의해 심사를 받은 알려진 사용자는 시간당 5,000건의 요청으로 더 많은 여유를 받습니다. 그러나 피크 타임에 우발적 인 과부하를 방지하거나 사용자 계정이 손상되어 서비스 거부 공격에 사용되는 경우 보상하도록 제한됩니다.
고려해야 할 마지막 좋은 연습으로, 해당 제한이 재설정될 시기에 대한 설명과 함께 제한 제한에 도달했을 때 사용자에게 알림을 표시하는 것이 좋습니다. 이렇게 하면 유효한 사용자가 응용 프로그램이 요청을 거부하는 이유를 알 수 있습니다. 또한 승인된 작업을 수행하는 유효한 사용자가 제한을 늘려야 한다는 것을 작업 담당자에게 신호를 볼 수 있으므로 API에 대한 액세스가 거부되는 경우에도 도움이 될 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.


이 취약점은 너무 많은 요청이 동시에 들어올 때 발생하며 API에는 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않습니다. 그런 다음 API를 사용할 수 없거나 새 요청에 응답하지 못할 수 있습니다.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.


리소스와 속도 제한이 부족하면 API 취약점이 제목에 의해 설명되는 방식과 거의 정확히 일치합니다. 모든 API에는 환경에 따라 리소스와 컴퓨팅 전력이 제한되어 있습니다. 대부분은 원하는 기능을 수행하도록 요청하는 사용자 또는 기타 프로그램의 요청을 필드로 수행해야 합니다. 이 취약점은 너무 많은 요청이 동시에 들어올 때 발생하며 API에는 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않습니다. 그런 다음 API를 사용할 수 없거나 새 요청에 응답하지 못할 수 있습니다.
API는 속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 이 문제에 취약해집니다. 예를 들어 비즈니스에서 특히 바쁜 기간을 경험하는 경우 API를 오버로드할 수 있습니다. 그러나 위협 행위자는 DDoS(서비스 거부) 공격을 수행하기 위해 요청으로 보호되지 않은 API를 의도적으로 과부하시킬 수 있기 때문에 보안 취약점이기도 합니다.
그런데 지금까지 API 게임화 챌린지로 어떻게 하고 있습니까? 지금 당장 취약점을 제한하는 속도 처리 기술을 시도하려면 경기장에 들어갑니다.
이제 좀 더 깊이 살펴보겠습니다.
리소스가 부족하고 API 취약점을 제한하는 속도의 예로는 어떤 예가 있습니까?
이 취약점이 API에 몰래 들어갈 수 있는 방법에는 두 가지가 있습니다. 첫 번째는 코더가 API에 대한 스로틀 속도를 정의하지 않는 경우입니다. 인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만 이에 의존하는 것은 좋은 정책이 아닙니다. 대신 각 API의 요금은 개별적으로 설정되어야 합니다. API는 사용 가능한 리소스뿐만 아니라 매우 다른 기능을 가질 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 제공하도록 설계된 내부 API는 매우 낮은 스로틀 속도를 가질 수 있으며 잘 작동할 수 있습니다. 그러나 실시간 전자 상거래 사이트의 일부인 공용 API는 동시 사용자의 급증 가능성을 보상하기 위해 매우 높은 비율이 정의될 가능성이 큽습니다. 두 경우 모두 제한 속도는 예상 요구 사항, 잠재적 사용자 수 및 사용 가능한 컴퓨팅 성능에 따라 정의되어야 합니다.
특히 매우 바쁠 가능성이 높은 API를 사용하면 성능을 극대화하기 위해 요금을 무제한으로 설정하는 것이 유혹적일 수 있습니다. 이것은 코드의 간단한 비트로 수행 할 수 있습니다 (예를 들어, 우리는 파이썬 장고 REST 프레임 워크를사용합니다):
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
이 예제에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간이 지남에 따라 요청 수와 관계없이 무제한 으로 API에 연락할 수 있습니다. API가 사용할 수 있는 컴퓨팅 리소스의 양에 관계없이 공격자는 봇넷과 같은 리소스를 배포하여 결국 크롤링 속도를 늦추거나 오프라인으로 완전히 노크할 수 있기 때문에 이는 잘못된 생각입니다. 이 경우 유효한 사용자가 액세스가 거부되고 공격이 성공합니다.
자원 부족 및 속도 제한 문제 제거
조직에서 배포하는 모든 API에는 스로틀 요금이 코드에 정의되어야 합니다. 여기에는 실행 시간 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수 또는 정의된 기간 내에 허용되는 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 제한 요금을 크게 열어 두는 대신 익명 및 알려진 사용자에 대해 서로 다른 비율로 엄격하게 정의할 수 있습니다.
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
새 예제에서 API는 익명 사용자가 시간당 200개의 요청을 하는 것으로 제한합니다. 이미 시스템에 의해 심사를 받은 알려진 사용자는 시간당 5,000건의 요청으로 더 많은 여유를 받습니다. 그러나 피크 타임에 우발적 인 과부하를 방지하거나 사용자 계정이 손상되어 서비스 거부 공격에 사용되는 경우 보상하도록 제한됩니다.
고려해야 할 마지막 좋은 연습으로, 해당 제한이 재설정될 시기에 대한 설명과 함께 제한 제한에 도달했을 때 사용자에게 알림을 표시하는 것이 좋습니다. 이렇게 하면 유효한 사용자가 응용 프로그램이 요청을 거부하는 이유를 알 수 있습니다. 또한 승인된 작업을 수행하는 유효한 사용자가 제한을 늘려야 한다는 것을 작업 담당자에게 신호를 볼 수 있으므로 API에 대한 액세스가 거부되는 경우에도 도움이 될 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

리소스와 속도 제한이 부족하면 API 취약점이 제목에 의해 설명되는 방식과 거의 정확히 일치합니다. 모든 API에는 환경에 따라 리소스와 컴퓨팅 전력이 제한되어 있습니다. 대부분은 원하는 기능을 수행하도록 요청하는 사용자 또는 기타 프로그램의 요청을 필드로 수행해야 합니다. 이 취약점은 너무 많은 요청이 동시에 들어올 때 발생하며 API에는 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않습니다. 그런 다음 API를 사용할 수 없거나 새 요청에 응답하지 못할 수 있습니다.
API는 속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 이 문제에 취약해집니다. 예를 들어 비즈니스에서 특히 바쁜 기간을 경험하는 경우 API를 오버로드할 수 있습니다. 그러나 위협 행위자는 DDoS(서비스 거부) 공격을 수행하기 위해 요청으로 보호되지 않은 API를 의도적으로 과부하시킬 수 있기 때문에 보안 취약점이기도 합니다.
그런데 지금까지 API 게임화 챌린지로 어떻게 하고 있습니까? 지금 당장 취약점을 제한하는 속도 처리 기술을 시도하려면 경기장에 들어갑니다.
이제 좀 더 깊이 살펴보겠습니다.
리소스가 부족하고 API 취약점을 제한하는 속도의 예로는 어떤 예가 있습니까?
이 취약점이 API에 몰래 들어갈 수 있는 방법에는 두 가지가 있습니다. 첫 번째는 코더가 API에 대한 스로틀 속도를 정의하지 않는 경우입니다. 인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만 이에 의존하는 것은 좋은 정책이 아닙니다. 대신 각 API의 요금은 개별적으로 설정되어야 합니다. API는 사용 가능한 리소스뿐만 아니라 매우 다른 기능을 가질 수 있기 때문에 특히 그렇습니다.
예를 들어 소수의 사용자에게만 제공하도록 설계된 내부 API는 매우 낮은 스로틀 속도를 가질 수 있으며 잘 작동할 수 있습니다. 그러나 실시간 전자 상거래 사이트의 일부인 공용 API는 동시 사용자의 급증 가능성을 보상하기 위해 매우 높은 비율이 정의될 가능성이 큽습니다. 두 경우 모두 제한 속도는 예상 요구 사항, 잠재적 사용자 수 및 사용 가능한 컴퓨팅 성능에 따라 정의되어야 합니다.
특히 매우 바쁠 가능성이 높은 API를 사용하면 성능을 극대화하기 위해 요금을 무제한으로 설정하는 것이 유혹적일 수 있습니다. 이것은 코드의 간단한 비트로 수행 할 수 있습니다 (예를 들어, 우리는 파이썬 장고 REST 프레임 워크를사용합니다):
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
이 예제에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간이 지남에 따라 요청 수와 관계없이 무제한 으로 API에 연락할 수 있습니다. API가 사용할 수 있는 컴퓨팅 리소스의 양에 관계없이 공격자는 봇넷과 같은 리소스를 배포하여 결국 크롤링 속도를 늦추거나 오프라인으로 완전히 노크할 수 있기 때문에 이는 잘못된 생각입니다. 이 경우 유효한 사용자가 액세스가 거부되고 공격이 성공합니다.
자원 부족 및 속도 제한 문제 제거
조직에서 배포하는 모든 API에는 스로틀 요금이 코드에 정의되어야 합니다. 여기에는 실행 시간 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수 또는 정의된 기간 내에 허용되는 프로세스 수 등이 포함될 수 있습니다.
위의 예에서 제한 요금을 크게 열어 두는 대신 익명 및 알려진 사용자에 대해 서로 다른 비율로 엄격하게 정의할 수 있습니다.
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
새 예제에서 API는 익명 사용자가 시간당 200개의 요청을 하는 것으로 제한합니다. 이미 시스템에 의해 심사를 받은 알려진 사용자는 시간당 5,000건의 요청으로 더 많은 여유를 받습니다. 그러나 피크 타임에 우발적 인 과부하를 방지하거나 사용자 계정이 손상되어 서비스 거부 공격에 사용되는 경우 보상하도록 제한됩니다.
고려해야 할 마지막 좋은 연습으로, 해당 제한이 재설정될 시기에 대한 설명과 함께 제한 제한에 도달했을 때 사용자에게 알림을 표시하는 것이 좋습니다. 이렇게 하면 유효한 사용자가 응용 프로그램이 요청을 거부하는 이유를 알 수 있습니다. 또한 승인된 작업을 수행하는 유효한 사용자가 제한을 늘려야 한다는 것을 작업 담당자에게 신호를 볼 수 있으므로 API에 대한 액세스가 거부되는 경우에도 도움이 될 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

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

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약다운로드시작할 수 있는 리소스
보안 기술 벤치마킹: 기업에서 보안 설계 간소화
보안 설계 이니셔티브의 성공에 대한 의미 있는 데이터를 찾는 것은 매우 어렵기로 악명이 높습니다. CISO는 직원과 회사 차원에서 보안 프로그램 활동의 투자 수익률(ROI)과 비즈니스 가치를 입증하는 데 어려움을 겪는 경우가 많습니다. 특히 기업이 현재 업계 표준과 비교하여 조직이 어떻게 벤치마킹되고 있는지에 대한 인사이트를 얻는 것은 더욱 어렵습니다. 대통령의 국가 사이버 보안 전략은 이해관계자들에게 "보안과 회복탄력성을 설계에 포함"할 것을 촉구했습니다. 설계에 의한 보안 이니셔티브의 핵심은 개발자에게 안전한 코드를 보장하는 기술을 제공하는 것뿐만 아니라 규제 기관에 이러한 기술이 제대로 갖추어져 있음을 확신시키는 것입니다. 이 프레젠테이션에서는 25만 명 이상의 개발자로부터 수집한 내부 데이터 포인트, 데이터 기반 고객 인사이트, 공개 연구 등 여러 주요 소스에서 파생된 수많은 정성적 및 정량적 데이터를 공유합니다. 이러한 데이터 포인트의 집계를 활용하여 여러 업종에 걸친 보안 설계 이니셔티브의 현재 상태에 대한 비전을 전달하고자 합니다. 이 보고서는 현재 이 분야의 활용도가 낮은 이유, 성공적인 업스킬링 프로그램이 사이버 보안 위험 완화에 미칠 수 있는 중대한 영향, 코드베이스에서 취약성 범주를 제거할 수 있는 잠재력에 대해 자세히 설명합니다.