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

Apigee Edge 문서입니다.
Apigee X 문서로 이동 정보

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

개요

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 상위 10개를 위한 Apigee 솔루션

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

A1:2017 - 삽입

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

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

콘텐츠 유형을 확인합니다.

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

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

API 키 검증

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

Apigee는 API 키 생성 및 유효성 검사를 지원합니다. 하나 이상의 API 제품에 연결된 개발자 앱이 생성되고 승인되면 Apigee에서 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는 세 가지 정책을 사용하여 JWT 지원을 제공합니다.

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

A3:2017 - 민감한 정보 노출

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

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

A6:2017-보안 구성 오류

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

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

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

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

교차 사이트 스크립팅 (XSS)을 사용하면 공격자가 사용자 웹브라우저에서 스크립트를 실행하여 사용자 세션을 제어하거나, 웹사이트를 조작하거나, 다른 방법으로 사용자에게 악의적인 영향을 줄 수 있습니다. XSS 문제는 API와 반드시 관련이 있는 것은 아니지만 Apigee는 API에서 XSS를 방지하는 데 활용할 수 있는 위협 보호 정책을 제공합니다.  RegularExpressionProtection 정책 또는 JavaScript 정책에 따라 정규 표현식을 사용하면 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 분석 데이터는 Analytics API를 통해 가져오고 다른 시스템으로 가져오거나 내보낼 수 있습니다.
  • 프라이빗 클라우드용 Edge에서 MessageLogging 정책을 사용하여 로컬 로그 파일에 기록할 수 있습니다. 실행 중인 각 구성요소의 로그 파일도 사용할 수 있습니다.
  • JavaScript 정책을 사용하여 로그 메시지를 REST 로깅 엔드포인트에 동기 또는 비동기로 전송할 수 있습니다.

모니터링

  • API 모니터링 UI 또는 API를 사용하여 API 및 백엔드를 정기적으로 모니터링하고 알림을 트리거합니다.
  • 상태 모니터링을 사용하여 정기적으로 대상 서버 백엔드를 모니터링합니다.
  • Apigee는 프라이빗 클라우드용 Edge를 모니터링하기 위한 권장사항을 제공합니다.
  • Apigee는 또한 API 프로그램을 모니터링하기 위해 팀에서 활용할 수 있는 권장사항을 제공합니다.

오류 처리

Apigee는 API 프록시에 대해 강력하고 다양한 결함 처리 메커니즘을 제공합니다. Java 프로그램이 예외를 캐치하는 것과 비슷하게, 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 리디렉션을 방지합니다.