API의 5가지 일반적인 취약점은 무엇입니까?

API를 사용하면 비즈니스를 쉽게 할 수 있으며 해커도 그렇게 생각합니다. 기업의 디지털 전환이 본격화되는 오늘날, API는 기술의 범위를 훨씬 뛰어넘었으며, 기존 기업의 디지털 전환은 API 경제 또는 API 전략과 분리될 수 없습니다. API는 시스템과 데이터뿐만 아니라 기업 기능 부서, 고객, 파트너, 심지어 전체 비즈니스 생태계까지 연결합니다. 동시에 점점 더 심각해지는 보안 위협으로 인해 API는 네트워크 보안의 차세대 개척자가 되고 있습니다. 보안 전문가가 기업에 제안하는 5가지 주요 API 보안 취약점과 패치 제안 사항을 정리했습니다.

API를 사용하면 데이터 공유부터 시스템 연결, 중요한 기능 제공에 이르기까지 모든 것이 쉬워지지만, 악성 봇을 포함한 공격자도 API를 사용하면 더 쉽게 사용할 수 있습니다. API 애플리케이션의 확산으로 인해 사이버 범죄자는 점점 더 API 보안 취약점을 악용하여 사기를 저지르고 데이터를 훔치게 됩니다.

아래에서는 해커가 쉽게 악용할 수 있는 API 취약점 5가지에 대해 논의하고, 보안 전문가들이 제시하는 완화 및 강화 제안을 공유하겠습니다.

1. 너무 쉽게 발견됩니다.

당신이 해커이고 회사를 공격하려는 경우 가장 먼저 해야 할 일은 가능한 한 많은 API를 식별하는 것입니다. 먼저 브라우저에서 웹 애플리케이션을 열거나 휴대폰에 모바일 애플리케이션을 다운로드하여 설치하는 등 일반적인 방법으로 대상 애플리케이션을 사용한 다음 차단 프록시를 사용하여 통신을 모니터링합니다.

차단 프록시는 브라우저 또는 모바일 애플리케이션에서 백엔드 웹 서버에 대한 모든 요청을 캡처할 수 있으므로 공격자가 사용 가능한 모든 API 엔드포인트를 카탈로그화할 수 있습니다. 예를 들어 대부분의 API에는 인증 끝점으로 API/V1/login이 있습니다.

대상도 모바일 앱인 경우 앱의 압축을 풀고 앱 내에서 사용 가능한 API 호출을 확인하세요. 공격자는 가능한 모든 활동을 고려하여 사용자 데이터를 적절하게 보호하지 못하는 일반적인 구성 오류나 API를 검색할 수 있습니다.

마지막으로 공격자는 API 문서를 찾습니다. 일부 조직에서는 타사를 위한 API 문서를 게시하지만 모든 사용자에게 동일한 API 엔드포인트를 사용합니다.

좋은 엔드포인트 목록을 통해 공격자는 표준 사용자 행동과 비정상적인 행동 테스트를 모두 테스트하여 흥미로운 취약점을 찾을 수 있습니다.

해결 방법: 공격자가 API를 더 쉽게 발견할 수 있도록 하려면 유효한 사용자 액세스만 허용하는 권한 관리를 통해 API 문서에 대한 액세스를 제어해야 합니다. 인증서를 모바일 앱에 고정해도 API 엔드포인트가 완전히 숨겨지지 않고 완벽하지도 않지만 공격에 추가 단계가 추가됩니다. 웹 서버에 대한 API 요청은 최대한 난독화되고 제어되어야 합니다.

2. 지나치게 상세한 오류 메시지

최근 계정 탈취를 시도하는 공격자가 늘어나고 있습니다. 너무 "자세한" 오류 메시지는 이러한 공격을 더 쉽게 만드는 경향이 있습니다. 긴 오류 메시지는 합법적인 요청으로 나타나기 위해 어떤 변경을 해야 하는지 공격자에게 안내합니다. API는 낮은 부하에서 고속 트랜잭션을 위해 설계되었으므로 공격자가 고성능 시스템을 사용하여 유효한 계정을 식별한 다음 로그인 및 비밀번호 변경을 시도하여 악용할 수 있습니다.

해결책: 사용자 경험을 방패로 사용하지 마십시오. 사용자 경험에 좋을 것 같은 일부 관행은 보안에 좋지 않을 수 있습니다. 시스템에서 반환되는 오류 메시지에는 잘못된 사용자 이름이나 잘못된 비밀번호 또는 오류 메시지 카테고리(잘못된 사용자 이름이나 비밀번호)가 포함되어서는 안 됩니다. 데이터를 쿼리하는 데 사용되는 오류 메시지도 마찬가지입니다. 쿼리/검색의 형식이 잘못되었거나 어떤 이유로 실행할 수 없는 경우 가장 "영양가 없는" 오류 메시지인 "죄송합니다. 문제가 발생했습니다."를 반환해야 합니다.

3. 매개변수가 너무 많음

공격자가 API 호출을 통해 공격 시스템을 통과할 때 데이터를 얻기 위해 무엇을 보낼 수 있는지 파악해야 합니다. 공격자들은 시스템이 복잡할수록 더 많은 문제가 발생할 수 있다고 "믿습니다". 공격자가 API를 식별하면 매개변수 목록을 작성한 다음 관리자(수직 권한 에스컬레이션) 또는 다른 사용자(수평 권한 에스컬레이션)의 데이터에 액세스하여 추가 데이터를 수집하려고 시도합니다. 불필요한 매개변수가 너무 많이 사용자에게 노출되는 경우가 많습니다.

최근 연구 프로젝트에서 대상 서비스에 대한 API 호출은 대량의 데이터를 반환했는데, 그 중 대부분은 결제 게이트웨이의 프로세서 키 및 사용 가능한 할인 정보와 같은 불필요한 데이터 정보였습니다. 이 "보상 정보"를 통해 공격자는 이러한 API 호출의 컨텍스트와 구문을 더 잘 이해할 수 있습니다. 공격자가 다음에 무엇을 해야 할지 알아내는 데는 많은 상상력이 필요하지 않습니다. 이러한 추가 매개변수는 공격자에게 풍부한 공격 데이터 세트를 제공합니다.

해결 방법: 사용자가 볼 수 있는 콘텐츠 범위를 필수 콘텐츠로 제한하고, 중요한 데이터의 전송을 제한하고, 데이터 쿼리 구조를 알 수 없도록 설정하면 공격자가 알고 있는 매개 변수를 무차별 공격하기가 어렵습니다.

4. 데이터가 너무 많습니다

다시 말하지만, 사용할 수 있는 매개변수가 너무 많기 때문에 데이터 수집은 분명한 다음 단계가 될 것입니다. 많은 엔터프라이즈 시스템은 익명 연결을 지원하며 일반 사용자에게 필요하지 않은 추가 데이터를 유출하는 경향이 있습니다. 또한 많은 기업에서는 직접 액세스할 수 있는 데이터를 저장하는 것을 선호합니다.

보안 전문가들은 종종 데이터가 저장된 위치를 노출시키는 API 요청 문제를 해결하기 위해 고군분투하고 있습니다. 예를 들어 보안 카메라의 비디오를 보면 해당 정보가 Amazon S3 리포지토리에서 가져온 것임을 알 수 있습니다. 이러한 S3 리포지토리는 제대로 보호되지 않아 누구의 데이터도 검색할 수 있는 경우가 많습니다.

또 다른 일반적인 데이터 문제는 데이터 과부하입니다. 많은 기업은 겨울이 오기 전에 다람쥐처럼 필요한 것보다 훨씬 많은 데이터를 저장합니다. 만료된 사용자 데이터 중 상당수는 상업적 가치나 보존 가치가 없지만, 유출될 경우 기업에 막대한 브랜드 및 규정 준수 위험을 초래합니다.

해결책: PII나 PHI뿐만 아니라 사용자 데이터를 저장하는 기업의 경우 철저한 데이터 감사가 필요합니다. 저장된 데이터를 조사한 후 데이터 액세스 규칙을 개발하고 테스트해야 합니다. 익명으로 액세스할 수 있는 데이터에 민감한 데이터가 포함되어 있지 않은지 확인하세요.

5. 너무 적은 보안 디자인

수년 동안 애플리케이션 디자인은 항상 기능성과 유용성을 우선시했으며 보안을 거의 고려하지 않았습니다. 많은 CISO는 특히 API 보안이 심각하게 고려되지 않거나 보안 설계 프로세스에서 완전히 제외된다고 말합니다. 일반적으로 개발자는 개발 및 배포를 완료한 후 API가 프로덕션에 투입되고 자주 공격을 받은 후에만 문제를 찾으려고 합니다. 보안(API 보안 포함)은 제품 설계의 일부가 되어야 하며 나중에 고려하는 것이 아니라 첫 번째 고려 사항 중 하나로 구현되어야 합니다.

해결책: 애플리케이션의 보안 아키텍처를 검토하는 것은 보안 시스템을 향한 중요한 첫 번째 단계입니다. API를 사용하면 공격자가 시스템을 보다 효율적으로 공격하거나 악용할 수 있습니다. 보안 설계의 목표는 API를 공격자가 아닌 사용자를 위한 효율적인 도구로 만드는 것입니다.

위 내용은 API의 5가지 일반적인 취약점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!