OWASP 웹 애플리케이션 위협 상위 10개

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

이 문서에서는 Apigee에서 OWASP에서 식별된 보안 취약점을 해결하기 위해 사용할 수 있는 다양한 접근 방식을 설명합니다. Apigee에 대해 문서화된 추가 접근 방식은 Google Cloud의 OWASP 2021년 OWASP 완화 옵션을 참조하세요.

개요

API 생태계는 외부 및 내부 고객의 다양한 공격을 경험합니다. API를 제공하고 사용하면 서비스 제공업체에 엄청난 기회가 생기지만 보안 위험이 발생할 수도 있습니다. 개발자는 이러한 문제를 인식하고 API를 만들고 사용할 때 해결해야 합니다.

OWASP는 조직에서 신뢰할 수 있는 애플리케이션과 API를 개발, 구매, 유지할 수 있도록 지원하는 개방형 커뮤니티입니다. OWASP는 OWASP API 보안 프로젝트를 통해 웹 애플리케이션 및 REST API에 가장 중요한 보안 위험을 게시하고 이러한 위험에 대처하기 위한 권장사항을 제공합니다.

Apigee를 사용하면 API 프록시 레이어가 백엔드 시스템에서 요청이 처리되기 전에 클라이언트의 잘못된 API 요청을 감지, 차단, 보고할 수 있으므로 위험을 완화하고 서비스를 보호할 수 있습니다. 형식이 잘못된 요청에는 HTTP 애플리케이션 수준 프로토콜을 구성하는 모든 구성요소가 포함될 수 있습니다.

  • URL
  • 헤더
  • 경로
  • 페이로드

잘못된 API 요청은 외부 개발자, 내부 개발자 또는 악성 봇이 개발한 알려진 클라이언트 또는 알 수 없는 클라이언트에서 발생할 수 있습니다. 이러한 유형의 요청이 대부분의 OWASP 위협을 구성하지만 데이터 마스킹, 로깅, 관리 등 위험을 완화할 수 있는 기본 API 프록시 레이어의 추가 구성요소도 있습니다.

Apigee의 지능형 API 관리 플랫폼을 사용하면 API를 설계하고 백엔드 시스템과 연결할 때 소비 중심의 접근 방식을 취하여 주요 OWASP API 보안 취약점을 원활하게 해결할 수 있습니다. 다음은 Apigee에서 주요 REST OWASP 위협에 권장하는 정책/구성 목록입니다.

2017년 OWASP Top 10을 위한 Apigee 솔루션

웹 애플리케이션의 빌드 및 보안과 관련하여 많은 보안 문제가 있습니다. OWASP는 웹 애플리케이션에 관한 2017년 OWASP 보안 위협 상위 10개 목록을 발표했습니다. 웹 애플리케이션에는 많은 부분이 있지만 대부분의 최신 웹 앱은 REST API에 크게 의존합니다. Apigee가 웹 애플리케이션의 모든 보안 요구사항을 처리하는 것은 아니지만 REST API를 보호하는 데 핵심적인 역할을 할 수 있습니다. 다음은 주요 OWASP 보안 위협과 Apigee를 사용하여 이러한 위협을 해결하는 방법에 대한 설명입니다.

A1:2017 - 주사

의도하지 않은 명령어 실행이나 무단 데이터 액세스를 초래할 수 있는 SQL, NoSQL, LDAP, 자바스크립트와 같이 신뢰할 수 없는 데이터 삽입을 방지하기 위해 Apigee는 추가 처리를 허용하기 전에 클라이언트가 제공한 값이 예상과 일치하는지 확인하는 여러 입력 유효성 검사 정책을 제공합니다. 수신되는 API 요청의 서버 역할을 하는 Apigee Edge는 페이로드 구조가 허용 가능한 범위(한도 검사라고도 함) 내에 있는지 확인합니다. 입력 유효성 검사 루틴이 입력을 변환하여 위험한 문자 시퀀스를 삭제하고 안전한 값으로 바꾸도록 API 프록시를 구성할 수 있습니다.

Apigee 플랫폼으로 입력을 검증하는 데에는 몇 가지 접근 방법이 있습니다.

콘텐츠 유형 확인:

A2:2017 - 인증 및 세션 관리 손상

공격자는 애플리케이션의 구현 결함을 이용하여 비밀번호, 세션 토큰, 키에 액세스하여 다른 사용자로 가장할 수 있습니다. 이는 제품 문제가 아니라 구현 문제에 가깝습니다. Apigee는 이 취약점으로부터 보호하는 데 도움이 되는 VerifyApiKey, OAuth, JSON 웹 토큰 (JWT) 정책을 제공합니다.

API 키 검증

API 키 유효성 검사는 API에 대해 구성할 수 있는 가장 간단한 형태의 앱 기반 보안입니다. 클라이언트 앱이 요청과 함께 API 키를 제공하면 Apigee Edge가 API 프록시에 연결된 정책을 통해 API 키가 요청 중인 리소스에 대해 승인된 상태인지 확인합니다.

Apigee는 API 키의 생성 및 검증을 지원합니다. Apigee는 하나 이상의 API 제품에 연결된 개발자 앱이 만들어지고 승인될 때 API 키와 보안 비밀을 생성합니다.

'API 키'라는 용어는 서로 다른 의미를 가질 수도 있습니다. Apigee에서 앱과 제품 관계가 형성되면 Apigee가 클라이언트 ID와 클라이언트 비밀번호를 생성합니다. ID와 보안 비밀을 모두 API 키로 지칭하는 경우도 있습니다. 어떤 경우에는 클라이언트 ID만 API 키로 지칭하기도 합니다. Edge UI에 '고객 키'와 '고객 비밀번호'가 표시됩니다.

VerifyAPIKey 정책에서는 클라이언트 ID 또는 '고객 키'만 확인합니다. 개발자가 Apigee에 앱을 등록하고 앱을 API 제품에 연결하면 고객 키를 받습니다. 개발자는 앱에서 API 제품에 번들로 포함된 API 프록시를 호출할 때 고객 키를 포함합니다.

Apigee는 외부 소스에서 기존 API 키를 가져오는 기능도 지원합니다.

OAuth 권한 부여 유형의 경우 클라이언트 ID와 보안 비밀이 모두 사용됩니다.

OAuth 2.0

OAuth 2.0 승인 프레임워크를 사용하면 서드 파티 애플리케이션이 리소스 소유자와 HTTP 서비스 간의 승인 상호작용을 조정하여 리소스 소유자를 대신하여 또는 서드 파티 애플리케이션이 자체적으로 액세스 권한을 획득할 수 있도록 허용하여 HTTP 서비스에 대한 제한된 액세스 권한을 얻을 수 있습니다.

Apigee의 OAuth 2.0 정책을 사용하면 4가지 OAuth 2.0 권한 부여 유형을 구현하고 맞춤설정할 수 있습니다. OAuth 액세스 토큰 적용은 OAuthv2 정책을 사용하여 수행할 수 있습니다. 소비자는 등록되어 있어야 하며 API 액세스 권한을 부여한 승인된 앱이 있어야 합니다. 그러면 API 클라이언트 ID와 클라이언트 보안 비밀번호가 수신됩니다. 소비자는 인증을 받기 위해 OAuth 권한 중 하나를 거쳐야 하며, 이 과정에서 불투명한 액세스 토큰이 부여됩니다. 이 토큰은 API에 대한 액세스를 제어하는 데 사용할 수 있습니다.

JWT

JSON 웹 토큰(JWT)은 일반적으로 연결된 애플리케이션 간의 클레임 또는 어설션을 공유하는 데 사용됩니다. Apigee는 3가지 정책을 사용하여 JWT 지원을 제공합니다.

  • GenerateJWT 토큰 (HS256 및 RS256 서명 지원)
  • ValidateJWT 토큰
  • 검증 없이 DecodeJWT 토큰

A3:2017 - 민감한 정보 노출

공격자는 신용카드 세부정보, 주민등록번호, 로그인 사용자 인증 정보, 개인 식별 정보 (PII), 세금 ID와 같은 민감한 정보를 표적으로 삼아 신원 도용, 금전 도용, 사기, 기타 범죄를 저지릅니다. 웹 애플리케이션은 저장 데이터와 전송 중 데이터 암호화와 민감한 정보 보호를 보장하기 위한 기타 전략을 구현해야 합니다.

TLS(전송 계층 보안. 이전 버전이 SSL)는 웹 서버와 웹 클라이언트(예: 브라우저, 앱) 간에 암호화된 링크를 설정하기 위한 표준 보안 기술입니다. Apigee는 단방향 TLS와 양방향 TLS를 모두 지원합니다.

북쪽 결합 TLS (API에 연결되는 서버 역할을 하는 클라이언트)는 가상 호스트 구성을 통해 지원됩니다. 단방향 또는 양방향 TLS로 가상 호스트를 구성할 수 있습니다.

사우스바운드 TLS (백엔드 서비스에 연결하는 클라이언트로서의 Apigee)는 대상 서버 구성을 통해 지원됩니다. 대상 서버는 단방향 또는 양방향 TLS로 구성할 수 있습니다.

Apigee는 다양한 TLS 구성 옵션을 지원합니다.

양방향 TLS를 적용하면 클라이언트가 Apigee에 이미 온보딩된 인증서를 사용할 수 있습니다. OWASP는 TLS 권장사항도 제공합니다.

Apigee Hybrid에서는 가상 호스트와 유사한 개념인 호스트 별칭을 통해 인그레스에서 TLS를 사용할 수 있습니다.

다음은 민감한 정보를 보호하기 위한 가이드라인입니다.

  • 프로토콜 수준에서 보호하는 단방향 및 양방향 TLS를 지원하는 플랫폼을 사용합니다.
  • 민감한 정보가 클라이언트에 반환되기 전에 AssignMessage 정책 및 JavaScript 정책과 같은 정책을 사용하여 민감한 정보를 삭제하세요.
  • 표준 OAuth 기법을 사용하고 HMAC, 해시, 상태, nonce, PKCE 또는 기타 기법을 추가하여 각 요청의 인증 수준을 개선하세요.
  • 데이터 마스킹 설정을 사용하여 Edge Trace 도구에서 민감한 정보를 마스킹합니다.
  • 민감한 정보를 캐시에 저장하거나 캐시에 저장된 민감한 정보를 암호화할 때는 주의하세요. Edge에서는 키 값 맵에서 민감한 저장 정보를 암호화할 수 있습니다.

A4:2017 - XML 외부 엔티티

XML을 처리하는 시스템이나 애플리케이션은 XML의 '외부 항목 참조'(XML 처리 중에 실제 데이터로 대체되는 파일 또는 데이터 참조)를 처리해야 합니다. 애플리케이션 또는 XML 프로세서가 오래되었거나 제대로 구현되지 않은 경우 공격자는 데이터를 해킹하여 정보를 도용하거나 시스템에 대한 다양한 종류의 공격(예: 서비스 거부)을 실행할 수 있습니다.

Apigee의 ExtractVariables 정책을 사용하면 요청 또는 응답에서 콘텐츠를 추출하고 해당 콘텐츠를 변수에 할당할 수 있습니다. 헤더, URI 경로, JSON/XML 페이로드, 양식 매개변수, 쿼리 매개변수 등 메시지의 모든 부분을 추출할 수 있습니다. 이 정책은 메시지 콘텐츠에 텍스트 패턴을 적용하고 일치하는 항목을 찾으면 지정된 메시지 콘텐츠로 변수를 설정하는 방식으로 작동합니다.

Apigee에는 XPath를 사용하여 데이터를 추출하는 플랫폼의 일부로 기본 제공되는 XML 파서가 있습니다. 또한 악성 XML 페이로드로부터 보호하는 XMLThreatProtection 정책이 있습니다.

A5:2017 - 액세스 제어 손상

사용자가 로그인하여 시스템에 액세스 권한을 얻은 후에는 사용자가 허용된 작업만 보고 수행할 수 있도록 적절한 승인 제어를 갖추어야 합니다. 강력한 액세스 제어가 없으면 공격자가 승인되지 않고 종종 민감한 정보를 보거나 악의적으로 데이터 및 시스템 동작을 조작할 수 있습니다.

Apigee는 악의적인 행위자가 무단으로 변경하거나 시스템에 액세스하지 못하도록 액세스 제어를 구현하는 계층화된 접근 방식을 지원합니다.

Edge UI 액세스 제어

Apigee 개발자 포털 액세스 제어

  • 회사의 ID 공급업체로 싱글 사인온(SSO)을 구성합니다.
  • 사용자가 Drupal 기반 개발자 포털에서 필요한 기능 및 구성에만 액세스할 수 있도록 역할 기반 액세스 제어 (RBAC)를 구성합니다.
  • 사용자 역할에 따라 특정 API 제품을 표시하도록 개발자 포털을 구성합니다.
  • 사용자 역할에 따라 콘텐츠를 표시하거나 숨기도록 포털을 구성합니다.

Apigee 런타임 API 액세스를 위한 액세스 제어

  • API에 대한 액세스는 API 키, OAuth 토큰, OAuth 범위, 인증서, 기타 기법을 통해 적용할 수 있습니다.
  • API 제공업체는 API 제품을 정의하여 사용 가능한 리소스를 구성합니다. 액세스 권한은 UI에서 수동으로 또는 관리 API를 통해 부여되거나 개발자 포털을 통해 부여됩니다. 개발자의 앱이 API 제품에 대한 액세스 권한을 부여받으면 인증 프로세스에 사용되는 클라이언트 ID와 보안 비밀을 받게 됩니다.
  • Apigee는 모든 ID 공급업체와 통합하여 OAuth를 수행할 수 있습니다.
  • Apigee는 JWT 토큰 또는 기타 기술을 생성하여 사용자 ID를 대상 서비스에 전송할 수 있습니다. 대상 서비스는 이 ID를 사용하여 필요에 따라 서비스 및 데이터에 대한 액세스를 제한할 수 있습니다.

A6:2017-보안 구성 오류

보안 구성 오류는 간과하기 쉽습니다. 관리자와 개발자가 자신이 사용하는 시스템이 본질적으로 안전하다고 잘못 믿기 때문입니다. 보안 구성 오류는 기본 구성을 신뢰하거나 안전하지 않을 수 있는 부분 구성을 만들거나, 오류 메시지에 민감한 세부정보가 포함되도록 하거나, 적절한 보안 제어 없이 클라우드에 데이터를 저장하거나, HTTP 헤더를 잘못 구성하는 등 여러 가지 방식으로 발생할 수 있습니다. Apigee 플랫폼은 재사용 가능한 공유 흐름을 포함하여 보안 구성을 제어, 관리, 모니터링할 수 있는 다양한 메커니즘을 제공합니다.

공유 흐름을 사용하면 API 개발자가 정책과 리소스를 재사용 가능한 그룹으로 결합할 수 있습니다. 공유 흐름을 사용하면 재사용 가능한 기능을 한곳에 모아 일관성을 유지하고 개발 시간을 단축하며 코드를 더 쉽게 관리할 수 있습니다. 개별 API 프록시 내에 공유 흐름을 포함하거나 한 단계 더 진행하여 공유 흐름을 흐름 후크에 배치하여 공유 흐름과 동일한 환경에 배포된 모든 API 프록시에 대해 공유 흐름 로직을 자동으로 실행할 수 있습니다.

Apigee 제품 출시는 취약점이 있는 라이브러리로부터 보호해 줍니다. 새로운 취약점이 발견되면 Apigee에서 추가 패치 또는 업데이트를 출시할 수 있습니다. Edge 퍼블릭 클라우드는 자동으로 패치됩니다. 프라이빗 클라우드용 에지 (온프레미스) 고객은 제품 패치를 직접 적용해야 합니다.

A7:2017-교차 사이트 스크립팅 (XSS)

교차 사이트 스크립팅 (XSS)을 사용하면 공격자가 사용자 웹브라우저에서 스크립트를 실행하여 사용자 세션을 제어하거나, 웹사이트를 조작하거나, 다른 방식으로 악의적으로 사용자에게 피해를 줄 수 있습니다. XSS 문제가 반드시 API와 관련된 것은 아니지만 Apigee는 API에서 XSS로부터 보호하는 데 활용할 수 있는 위협 보호 정책을 제공합니다. RegularExpressionProtection 정책 또는 JavaScript 정책과 함께 정규 표현식을 사용하여 자바스크립트 및 기타 삽입 유형 공격의 페이로드와 매개변수 값을 확인합니다.

모든 브라우저에서 적용되는 동일 출처 정책에 대해 일반적으로 구현되는 솔루션 중 하나인 CORS는 AssignMessage 정책을 사용하여 구현할 수 있습니다.

A8:2017 - 안전하지 않은 역직렬화

공격자는 재생, 권한 에스컬레이션, 삽입과 같은 다양한 유형의 공격에 대해 역직렬화의 결함을 사용할 수 있습니다. 또한 비보안 역직렬화는 원격 코드 실행을 사용 설정할 수 있습니다.

Apigee는 역직렬화를 권장하지 않습니다. 하지만 JSONThreatProtection 정책 및 RegularExpressionProtection 정책은 악성 JSON 페이로드로부터 보호하는 데 도움이 될 수 있습니다. JavaScript 정책은 페이로드에서 악성 콘텐츠를 스캔하는 데도 사용할 수 있습니다. 캐시 및 기타 정책을 사용하여 재전송 공격을 방지할 수 있습니다. 또한 Apigee 플랫폼에는 인프라 수준에서 실행 중인 프로세스를 보호하기 위한 가드레일이 내장되어 있습니다.

A9:2017 - 알려진 취약점이 있는 구성요소 사용

프레임워크, 라이브러리, 모듈은 전체 실행 및 CRUD 액세스 권한으로 실행되므로 공격자가 구성요소 취약점을 악용하여 시스템을 공격할 수 있습니다.

Apigee의 정기적인 제품 출시는 특히 특정 취약점이 발견되었을 때 구성요소 취약점으로부터 보호해 줍니다. Apigee 퍼블릭 클라우드는 자동으로 패치가 적용되고, Apigee는 온프레미스 패치를 설치할 수 있게 되면 프라이빗 클라우드용 Edge 고객에게 알림을 보냅니다.

A10:2017 - 로깅 및 모니터링 부족

시스템에서 로깅, 모니터링, 이슈 관리를 적절히 수행하지 않으면 공격자가 데이터와 소프트웨어에 대해 보다 심층적이고 장기적인 공격을 수행할 수 있습니다.

Apigee에는 로깅, 모니터링, 오류 처리, 감사 로깅을 수행하는 여러 가지 방법이 있습니다.

로깅

  • 로그 메시지는 MessageLogging 정책을 사용하여 Splunk 또는 다른 syslog 엔드포인트로 보낼 수 있습니다.
  • 애널리틱스 API를 통해 API 분석 데이터를 가져와 다른 시스템으로 가져오거나 내보낼 수 있습니다.
  • 프라이빗 클라우드용 에지에서는 MessageLogging 정책을 사용하여 로컬 로그 파일에 쓸 수 있습니다. 실행 중인 각 구성요소의 로그 파일도 제공됩니다.
  • JavaScript 정책을 사용하여 동기식 또는 비동기식으로 REST 로깅 엔드포인트에 로그 메시지를 보낼 수 있습니다.

모니터링

  • API Monitoring UI 또는 API를 사용하여 API와 백엔드를 정기적으로 모니터링하고 Alet을 트리거합니다.
  • 상태 모니터링을 사용하여 대상 서버 백엔드를 정기적으로 모니터링합니다.
  • Apigee는 Edge for Private Cloud 모니터링을 위한 권장사항을 제공합니다.
  • Apigee는 팀에서 API 프로그램을 모니터링하는 데 활용할 수 있는 권장사항을 제공합니다.

오류 처리

Apigee는 API 프록시에 강력하고 다재다능한 오류 처리 메커니즘을 제공합니다. 자바 프로그램이 예외를 포착하는 방식과 마찬가지로 API 프록시도 오류를 포착하고 클라이언트에 적절한 응답을 반환하는 방법을 결정할 수 있습니다. Apigee의 커스텀 오류 처리를 사용하면 오류가 발생할 때마다 메시지 로깅과 같은 기능을 추가할 수 있습니다.

감사 로그

Apigee 플랫폼은 API 프록시, 제품, 조직 기록의 변경사항을 추적하는 감사 로그를 보관합니다. 이 로그는 UI 또는 Audits API를 통해 확인할 수 있습니다.

2013년 OWASP 취약점 해결을 위한 Apigee 솔루션

OWASP가 2017년 목록을 업데이트할 때 2013년 목록의 일부 취약성은 누락된 채로 남아 있었습니다. 이러한 취약성은 여전히 유효한 위협입니다. 다음 섹션에서는 Apigee를 사용하여 이러한 위협을 처리하는 방법을 설명합니다.

A8:2013 - 크로스 사이트 요청 위조 (CSRF)

교차 사이트 위조 요청을 사용하면 공격자가 사용자의 인증 세부정보, 세션 쿠키, 기타 데이터를 HTTP를 통해 취약한 웹 애플리케이션에 전달하여 웹 애플리케이션이 사용자의 합법적인 요청이라고 믿게 만들 수 있습니다.

가이드라인:

  • 이는 API 제품 문제가 아니라 브라우저 문제에 가깝습니다. OpenID Connect, OAuth, 기타 기법을 사용하여 이 취약점을 해결할 수 있습니다.
  • 위조 및 재전송 공격을 방지하기 위해 HMAC, 상태, 해시, nonce, PKCE 기법을 사용하는 것이 좋습니다.

A10:2013 - 유효하지 않은 리디렉션 및 전달

웹 애플리케이션이 리디렉션을 수행하지만 리디렉션이 사용자를 신뢰할 수 있는 의도된 웹사이트로 보내는지 검증하지 않는 경우 공격자는 사용자를 악성 대상으로 보내 피싱, 멀웨어 실행, 기타 공격을 수행할 수 있습니다.

가이드라인:

  • OAuth를 사용하고 각 요청에서 유효성 검사를 시행하세요.
  • API 프록시 로직에서 응답 코드를 확인하고 리디렉션을 적절히 처리하여 예기치 않은 302 리디렉션을 방지합니다.