상위 OATH API 취약점
상위 OATH API 취약점: 소개
악용과 관련하여 API는 시작하기에 가장 좋은 곳입니다. API 액세스는 일반적으로 세 부분으로 구성됩니다. 클라이언트는 API와 함께 실행되는 권한 부여 서버에서 발행한 토큰입니다. API는 클라이언트로부터 액세스 토큰을 수신하고 이를 기반으로 도메인별 권한 부여 규칙을 적용합니다.
최신 소프트웨어 애플리케이션은 다양한 위험에 취약합니다. 최신 악용 및 보안 결함에 대한 최신 정보를 유지하십시오. 공격이 발생하기 전에 애플리케이션 보안을 보장하려면 이러한 취약성에 대한 벤치마크를 갖는 것이 필수적입니다. 타사 애플리케이션은 점점 더 OAuth 프로토콜에 의존하고 있습니다. 이 기술 덕분에 사용자는 전반적인 사용자 경험이 향상되고 로그인 및 인증이 빨라집니다. 사용자가 주어진 리소스에 액세스하기 위해 타사 애플리케이션에 자신의 자격 증명을 공개할 필요가 없기 때문에 기존 인증보다 더 안전할 수 있습니다. 프로토콜 자체는 안전하고 안전하지만 구현 방식으로 인해 공격에 노출될 수 있습니다.
API를 설계하고 호스팅할 때 이 문서는 일반적인 OAuth 취약성과 다양한 보안 완화에 중점을 둡니다.
손상된 개체 수준 권한 부여
API는 개체에 대한 액세스를 제공하기 때문에 권한 부여를 위반하는 경우 광범위한 공격 표면이 있습니다. API 접근 가능한 항목은 인증을 받아야 하므로 필요합니다. API 게이트웨이를 사용하여 개체 수준 권한 부여 검사를 구현합니다. 적절한 권한 자격 증명이 있는 사용자만 액세스가 허용되어야 합니다.
손상된 사용자 인증
승인되지 않은 토큰은 공격자가 API에 대한 액세스 권한을 얻는 또 다른 일반적인 방법입니다. 인증 시스템이 해킹되거나 API 키가 실수로 노출될 수 있습니다. 인증 토큰은 다음과 같을 수 있습니다. 해커가 사용 액세스 권한을 얻습니다. 신뢰할 수 있는 경우에만 사람을 인증하고 강력한 암호를 사용하십시오. OAuth를 사용하면 단순한 API 키를 넘어 데이터에 액세스할 수 있습니다. 어떤 장소에 어떻게 들어오고 나갈지 항상 생각해야 합니다. OAuth MTLS Sender Constrained Token은 Mutual TLS와 함께 사용하여 클라이언트가 오작동하지 않고 다른 시스템에 액세스하는 동안 잘못된 당사자에게 토큰을 전달하지 않도록 할 수 있습니다.
API 프로모션:
과도한 데이터 노출
게시할 수 있는 엔드포인트 수에는 제한이 없습니다. 대부분의 경우 모든 사용자가 모든 기능을 사용할 수 있는 것은 아닙니다. 절대적으로 필요한 것보다 더 많은 데이터를 노출함으로써 자신과 다른 사람을 위험에 빠뜨리는 것입니다. 민감한 내용 공개 자제 정보 절대적으로 필요할 때까지. 개발자는 OAuth 범위 및 클레임을 활용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 클레임은 사용자가 액세스할 수 있는 데이터 섹션을 지정할 수 있습니다. 모든 API에서 표준 구조를 사용하여 액세스 제어를 더 간단하고 쉽게 관리할 수 있습니다.
리소스 부족 및 속도 제한
검은 모자는 종종 서비스 거부(DoS) 공격을 무차별 대입 방식으로 사용하여 서버를 압도하여 가동 시간을 XNUMX으로 줄입니다. 호출할 수 있는 리소스에 대한 제한이 없기 때문에 API는 약화 공격에 취약합니다. 'API 게이트웨이 또는 관리 도구를 사용하여 API에 대한 속도 제한을 설정할 수 있습니다. 필터링 및 페이지 매김이 포함되어야 하며 응답이 제한되어야 합니다.
보안 시스템의 잘못된 구성
다양한 보안 구성 지침은 보안 구성이 잘못될 가능성이 높기 때문에 상당히 포괄적입니다. 많은 작은 것들이 플랫폼의 보안을 위험에 빠뜨릴 수 있습니다. 예를 들어 은밀한 목적을 가진 검은 모자가 잘못된 쿼리에 대한 응답으로 전송된 민감한 정보를 발견할 수 있습니다.
대량 할당
엔드포인트가 공개적으로 정의되지 않았다고 해서 개발자가 액세스할 수 없다는 의미는 아닙니다. 비밀 API는 해커가 쉽게 가로채고 리버스 엔지니어링할 수 있습니다. "비공개" API에서 공개 베어러 토큰을 사용하는 이 기본 예를 살펴보십시오. 반면에 개인 용도로만 사용할 수 있는 공개 문서가 존재할 수 있습니다. 검은 모자는 노출된 정보를 사용하여 개체 특성을 읽을 뿐만 아니라 조작할 수도 있습니다. 방어에서 잠재적인 약점을 찾을 때 자신을 해커라고 생각하십시오. 반환된 항목에 대한 적절한 권한이 있는 사용자만 액세스할 수 있습니다. 취약성을 최소화하려면 API 응답 패키지를 제한하십시오. 응답자는 반드시 필요하지 않은 링크를 추가해서는 안 됩니다.
프로모션 API:
부적절한 자산 관리
개발자 생산성 향상 외에도 현재 버전과 문서는 사용자의 안전을 위해 필수적입니다. 새 버전의 도입과 이전 API의 사용 중단에 훨씬 미리 대비하십시오. 이전 API를 계속 사용하도록 허용하는 대신 최신 API를 사용합니다. API 사양은 문서화의 기본 정보 소스로 사용될 수 있습니다.
주입
API는 삽입에 취약하지만 타사 개발자 앱도 마찬가지입니다. 악성 코드는 데이터를 삭제하거나 암호 및 신용 카드 번호와 같은 기밀 정보를 도용하는 데 사용될 수 있습니다. 여기서 얻을 수 있는 가장 중요한 교훈은 기본 설정에 의존하지 않는 것입니다. 관리 또는 게이트웨이 공급업체는 고유한 애플리케이션 요구 사항을 수용할 수 있어야 합니다. 오류 메시지에는 민감한 정보가 포함되어서는 안 됩니다. ID 데이터가 시스템 외부로 유출되는 것을 방지하기 위해 토큰에 Pairwise Pseudonyms를 사용해야 합니다. 이렇게 하면 어떤 클라이언트도 사용자를 식별하기 위해 함께 작업할 수 없습니다.
불충분한 로깅 및 모니터링
공격이 발생하면 팀은 신중한 대응 전략이 필요합니다. 신뢰할 수 있는 로깅 및 모니터링 시스템이 없으면 개발자는 잡히지 않고 계속해서 취약점을 악용할 것이며, 이로 인해 손실이 증가하고 회사에 대한 대중의 인식이 손상될 것입니다. 엄격한 API 모니터링 및 프로덕션 엔드포인트 테스트 전략을 채택합니다. 조기에 취약점을 발견한 White Hat 테스터는 포상금 제도로 보상을 받아야 합니다. 사용자의 ID를 API 트랜잭션에 포함하여 로그 추적을 개선할 수 있습니다. 액세스 토큰 데이터를 사용하여 API 아키텍처의 모든 계층을 감사해야 합니다.
결론
플랫폼 설계자는 확립된 취약성 기준에 따라 공격자보다 한 발 앞서 나가도록 시스템을 구성할 수 있습니다. API는 개인 식별 정보(PII)에 대한 접근성을 제공할 수 있으므로 이러한 서비스의 보안을 유지하는 것은 회사 안정성과 GDPR과 같은 법률 준수 모두에 중요합니다. API 게이트웨이 및 팬텀 토큰 접근 방식을 사용하지 않고 API를 통해 OAuth 토큰을 직접 보내지 마십시오.
프로모션 API:
