[번역] OWASP API Security Top 10

https://apisecurity.io/encyclopedia/content/owasp/owasp-api-security-top-10.htm

본 문서는 “OWASP API Security Top 10″으로 게시된 내용을 번역한 내용입니다.
개인적인 연구목적으로 작성하였으며 출처를 표기하신 후에 인용을 부탁드립니다.

오역이 발생할 여지가 있는 부분은 영어 그대로 표기하였으며, 번역자 의견의 경우 녹색으로 표시하였습니다.


Web application security vs API security

REST API와 Web Application 간에는 유사점이 많지만, 근본적인 차이점도 있습니다.

전통적인 Web Application에서는 데이터 프로세싱이 서버사이드에서 이루어지며, 프로세싱 결과는 클라이언트 브라우저로 전송된 후 렌더링되어 표시됩니다. 이러한 이유로 인해 비즈니스상 네트워크 아키텍쳐에 대한 진입점 (사용자 접점)은 상대적으로 적으며 WAF(웹방화벽)과 같은 장비를 서버 앞단에 설정함으로써 공격을 직관적으로 방어할 수 있었습니다.

그러나 최신 API기반의 어플리케이션은 상황이 아주 다릅니다. 점점 더 많은 UI들이 어플리케이션의 기능을 제공하기 위해 백엔드 서버로부터 데이터를 송/수신하는 API를 사용하고 있습니다. 사이트를 렌더링하고 상태를 유지-관리하는 것은 클라이언트의 영역이 되었습니다.

The graphic shows how much more traffic APIs create between the UI and the backend compared to the traditional web applications.

기존 웹 애플리케이션과 비교할때 UI와 백엔드간 얼마나 많은 API트래픽이 생성되는지 보여줍니다.

여기에 개별 애플리케이션의 구성요소가 API화 된 마이크로서비스 아키텍처가 추가됨에따라 Attack Surface가 크게 확장되어 이전과는 훨씬 다른 세계를 경험할 수 있습니다. 이제는 백엔드 서버 또는 네트워크 동-서간에 발생하는 수많은 API호출이 네트워크 아케텍쳐의 진입점이라 할 수 있습니다.

네트워크 아키텍처에서는 종종 여러 진입점이 분산되어 있기 때문에, 서버 앞에 방화벽을 두는 것은 모든 진입점을 보호 하기에는 더이상 충분하지 않습니다. 또한 기존의 WAF 기반 솔루션은 해킹을 위한 악의적 API 호출과 정상적인 API 호출을 구별할 수 있는 수단이 마련되어 있지 않습니다.

본래 API는 애플리케이션 로직과 PII(개인 식별 가능 정보)와 같은 민감한 데이터를 노출하게 되어있으며, 그 때문에 점점 더 공격자의 표적이 되고 있습니다. API는 일종의 약속이라 할 수 있지만,  그 약속자체가 올바르게 유지되는것을 보장하기 위한 방법은 제공하지 않으며 이로인해  API가 연결되는 백엔드 서비스에 심각한 보안 위험을 끼칠 수 있습니다.

따라서 API 보안을 위해서는 API 보안 위험과 취약점을 이해하고 완화(Mitigate)할 수 있는독자적인 방법이 필요합니다.

OWASP API Top 10 project

위에서 언급한 업계 변화로 인해 OWASP는 API 보안을 위한 별도의 프로젝트를 시작하게 되었습니다. 현재 OWASP API Security Top 10 프로젝트는 특히 API 보안 상위 10개 취약점에 초점을 맞추고 있습니다.

 

API1:2019 — Broken object level authorization

API2:2019 — Broken authentication

API 인증이 취약하게 구현된 경우, 공격자는 다른 사용자의 신원을 추정할 수 있습니다.

Having broken authentication in front of your API can give attackers the keys to access it.

Use case 

  • “내부”용으로 간주되는 보호되지 않는 API (번역자 주 : 일반 유저에게 노출되지 않는 히든API 등)
  • 업계의 Best Practice를 따르지 않는 취약한 인증
  • 랜덤화되지 않은 취약한 API 키의 사용
  • 보안성이 약한, 평문의, 암호화된, 잘못된 해싱의, 공유된 패스워드 또는 디폴트 패스워드의 사용
  • Brute force 공격, Credential stuffing공격에 취약한 구조의 인증방식 사용
  • URL에 자격 증명 및 키가 포함된 경우
  • 액세스 토큰의 유효성 검사 부족(JWT 유효성 검사 포함)
  • 서명되지 않았거나 취약하게 서명된 (만기되지 않은) JWT

How to prevent 

  • 가능한한 API요청을 인증할 수 있는 모든 방법을 사용합니다.
  • 비밀번호 재설정 및 일회성 링크용 API도 사용자가 인증할 수 있도록 하며, 다른것과 동일한 수준으로 엄격하게 보호되어야 합니다.
  • 표준 인증, 토큰 생성, 암호 저장 및 MFA(다단계 인증)를 사용합니다.
  • 수명주기가 짧은 액세스 토큰을 사용합니다.
  • 앱을 인증합니다. (이를 통해 누가 당신과 통신하려는지를 알 수 있습니다.) -> 이부분은 설명이 좀 부족한데요. 서버 입장에서 접속하는 앱에 대한 인증을 적용하라는 의미인듯 합니다.
  • 인증에 더 엄격한 속도 제한을 적용하고, 잠금 정책 및 취약한 암호에 대한 검사기능을 구현합니다.

API3:2019 — Excessive data exposure

잘못 구현된 API는 클라이언트가 정상적으로 요청하는 데이터보다 훨씬 더 많은 데이터를 노출시킬 수 있으며, 필터링은 클라이언트에 의존합니다. 공격자가 API에 직접 접근할 수 있다면, 모든 것을 획득하게 됩니다.

The raw data that the API returns from the backend is all up for grabs if your bypass the UI.

Use case

  • 취약한 API는 백엔드 데이터베이스에 저장된 전체 데이터 개체를 반환합니다.
  • 클라이언트 애플리케이션은 응답값을 필터링한 후 사용자가 실제로 봐야 할 데이터만 표시합니다.
  • 공격자는 API를 직접 호출하여 UI가 필터링한 민감한 데이터를 획득할 수 있습니다.

How to prevent

  • 데이터 필터링은 반드시 서버사이드에서 구현 합니다.
  • 모든 API호출에 대한 응답값을 검토하고, API 요청자가 진정 필요로 하는 데이터를 제공할 수 있도록 조정합니다.
  • 모든 API 응답값에 대한 스키마를 신중하게 정의합니다.
  • 응답오류를 누락하지 말고 그에 대한 적절한 스키마도 정의합니다.
  • 모든 민감한 데이터 또는 개인 식별 가능 정보(PII)를 식별하고 올바르게 사용합니다.
  • 우발적인 데이터 유출 또는 예외사항을 방지하기 위해 대응 점검을 실시합니다.

API4:2019 — Lack of resources and rate limiting

대량의 API호출 또는 대용량의 페이로드에 취약한 경우입니다. 공격자는 이러한 취약점을 서비스 거부(DoS) 및 무작위 대입 공격과 같은 인증 결함에 이용할 수 있다.

Bombing the API with too many requests or too big payloads can make the API crash, possibly with unexpected results.

Use case

  • 공격자가 서버가 처리할 수 있는 양보다 훨씬 더 많은 요청을 보냄으로써 API에 과부하를 가합니다.
  • 공격자가 API의 처리 속도를 초과하는 요청을 보내어 정상적인 동작을 방해합니다.
  • API요청시 페이로드 크기 또는 페이로드의 일부 필드를 API가 처리할 수 있는 양보다 초과하여 전송합니다.
  • 압축을 해제하는데 과도한 자원이 소요되고 API에 과부하가 걸리게끔 만들어진 “Zip 폭탄” 파일을 전송합니다.

How to prevent

  • 적절한 rate limit을 정의합니다.
  • 페이로드 크기를 제한합니다.
  • API 함수, 클라이언트 또는 주소에 따라 알맞는 rate limit을 설정합니다.
  • 압축파일의 압축 비율에 대한 검사를 실시합니다.
  • 컨테이너 리소스에 대한 limit을 정의합니다.

API5:2019 — Broken function level authorization

취약한 API는 User 레벨 또는 Admin 레벨 API를 사용하기 위한 권한을 클라이언트 사이드에서 검증합니다. 공격자는 “숨겨진” 관리용 API 함수를 찾아낸 후 직접 호출할 수 있습니다.

No authorization for admin methods can allow anyone to use them.

Use case

  • 몇몇 관리자용 기능이 API로 노출되는 경우도 있습니다.
  • 권한이 없는 사용자가 자기 권한 밖의 함수를 알게되면, 허가 없이 액세스 할수도 있습니다.
  • 다음과 같이 URL주소를 알고 있거나 단어 또는 파라미터를 사용하는 경우 문제가 발생할 수 있습니다.
    • /api/users/v1/user/myinfo
    • /api/admins/v1/users/all

How to prevent

  • 클라이언트 사이드에서 관리자용 액세스를 검증하지 않습니다.
  • 기본적으로 모든 액세스를 차단합니다. (예외 경우만 허용합니다)
  • 적절한 그룹 또는 역할에 속하는 사용자에게만 호출을 허용합니다.
  • 적절하게 설계하고 및 권한을 테스트합니다.

API6:2019 — Mass assignment

취약한 API는 화이트리스트 속성에 대한 적절한 필터링없이 클라이언트가 제공한 데이터를 가져와 그대로 저장합니다. 공격자는 객체 속성을 추측하거나 API 요청시 추가적인 객체 속성을 삽입, API 다큐먼트를 읽기, API 엔드 포인트를 확인하여 백엔드에 저장된 데이터 객체에서 속성을 무단 수정할 수 있는 단서를 찾아낼 수 있습니다.

The API works with the data structures without proper filtering and blindly stores payloads as objects.

Use case

  • 취약한 API의 경우 적절한 필터링이 구현되지 않은 데이터 구조에서 동작합니다.
  • 공격자로부터 수신한 페이로드를 필터링하지 않은채 객체화 되어 저장됩니다.
    • NodeJS:
      var user = new User(req.body);
      user.save();
    • Rails:
      @user = User.new(params[:user])
  • Attackers can guess the fields by looking at the GET request data.
  • 공격자는 GET 요청 데이터를 확인함으로써 필드를 추측할 수 있습니다.

How to prevent

  • 유입되는 데이터와 내부 개체를 자동으로 바인딩하지 않습니다
  • 예상하는 모든 매개변수와 페이로드에 대해 명시적으로 정의합니다.
  • API를 통해 검색할 수 있지만 절대 수정해서는 안 되는 모든 속성에 대해 개체 스키마에서 readOnly 속성을 true로 설정합니다.
  • 설계시 또는 요청시 수락할 스키마, 유형 및 패턴을 정확하게 정의하고 런타임에 적용합니다.

API7:2019 — Security misconfiguration

API 서버 설정이 잘못된 경우 공격자는 이를 이용할 수 있습니다.

All kinds of configuration errors can leave gaping holes in the protection of your API server.

Use case

  • 패치되지 않은 시스템
  • 파일 및 디렉토리에 대한 보호 미설정
  • TLS가 설정되이 않았거나 인증서 기간이 만료된 경우
  • 스토리지 또는 서버 관리 패널이 노출된 경우
  • CORS정책 또는 시큐리디 헤더값의 부재
  • Stack trace내용이 포함된 에러 메시지의 노출
  • 불필요한 기능이 활성화된 경우

How to prevent

  • 지속 가능한 보안 및 패치 프로세스를 구축합니다.
  • 잘못된 설정으로 인한 취약점 찾는 방법을 자동화합니다.
  • 불필요한 기능을 사용하지 않도록 설정합니다.
  • 관리기능에 대한 접근을 제한합니다.
  • 오류를 포함하여 모든 출력내용을 정의합니다.

API8:2019 — Injection

공격자는 SQL, NoSQL, LDAP, OS, API 또는 백엔드에서 검증없이 실행되는 명령어를 삽입하여 API를 호출할 수 있습니다.

Insufficient validation of input data can allow attackers to inject malicious code to be executed by your API or its backend.

Use cases

  • 공격자는 다음 항목에 악의적인 인풋값을 전송하여 서버 내부 인터프리터로 전달할 수 있습니다.
    • SQL
    • NoSQL
    • LDAP
    • OS commands
    • XML parsers
    • Object-Relational Mapping (ORM)

How to prevent

  • API 사용자는 (내부 사용자일지라도) 절대 신뢰하지 않습니다.
  • 스키마, 유형, 문자열 패턴 등 모든 입력 데이터를 엄격하게 정의하고 런타임에 적용합니다.
  • 들어오는 모든 데이터의 유효성을 확인하고, 필터링 합니다.
  • API 응답 아웃풋에 대해 정의하고, 적절하게 제한하여 데이터 누출을 방지합니다.

API9:2019 — Improper assets management

공격자는 프로덕션 API수준으로 보호되지 않은 비 프로덕션 버전의 API (예 : 스테이징, 테스트, 베타 또는 이전 버전)를 찾아 공격할 수 있습니다.

Authentication through less protected non-production versions of the API may open a backdoor to access the production API.

Use case

  • DevOps, 클라우드, 컨테이너 및 Kubernets는 여러가지 형태의 서버구축(예: 개발, 테스트, 분기, 스테이징, 이전 버전)을 쉽게 구현할 수 있도록 해줍니다.
  • 이전 개발한 API가 실행될 수 있도록 역호환성을 유지하고자 합니다.
  • 이전 버전이나 non-production 버전은 제대로 관리되지는 않으나, 여전히 production 데이터에 액세스할 수 있습니다.
  • 만약 한 엔드포인트에 인증을 성공하면 공격자는 production 서버등으로 옮겨갈 수 있게됩니다.

How to prevent

  • 모든 API 호스트를 최신 인벤토리로 유지합니다.
  • 공개해서는 안 되는 모든 것에 대해 접근을 제한합니다.
  • Production 데이터에 대한 액세스를 제한하고 Production 및 Non-Production 데이터에 대한 액세스를 분리합니다.
  • API 방화벽과 같은 추가적인 외부 제어장치를 구현합니다.
  • 이전 버전의 API 또는 백포트 보안 수정 사항을 적절하게 폐기합니다.
  • 엄격한 인증, 리디렉션, CORS 등을 구현합니다.

API10:2019 — Insufficient logging and monitoring

적절한 로깅, 모니터링 및 경고장치가 없으면 공격자 및 공격행위를 추적할 수 없습니다.

Proper logging, monitoring, and alerting provides the visibility to what is going on with your API.

Use case

  • 로그의 무결성이 보장되지 않는 경우
  • 로그가 SIEM (Security Information and Event Management) 시스템에 통합되지 않은 경우
  • 로그 및 경고 체계가 제대로 설계되지 않은경우.
  • 자동화 시스템보다는 수동 시스템에 의존하는 경우

How to prevent

  • 실패한 시도, 액세스 거부, 입력 유효성 검사 실패 또는 보안 정책 검사 실패행위를 기록합니다.
  • 다른 도구도에서도 사용이 가능하도록 로그 포맷이 지정되었는지 확인합니다.
  • 매우 민감한 정보를 다루듯이 로그 데이터를 보호합니다.
  • 공격자를 식별하기에 충분한 세부 정보를 포함하여 로깅합니다.
  • 민감한 데이터를 로그에 보관하지 않습니다. 디버깅 목적으로 정보가 필요한 경우 부분적으로만 수정합니다.
  • SIEM 및 기타 대시 보드, 모니터링 및 경고 도구와 통합합니다.

번역자 의견

 API는 클라이언트-서버간 정보를 효율적으로 주고 받기 위해 설계되었으나 잘못 사용할 경우 심각한 데이터 유출 또는 해킹사고로 이어질 수 있습니다.

사실 그간 해커원에서 API관련 취약점을 볼때마다 “저게 된다고?” 라는 생각이 들 때가 많았습니다.
그만큼 API는 개발자의 효율에 촛점이 많이 맞춰져 있으며 여전히 API 보안에 대한 이해는 부족하다는 생각입니다.

번역된 글을 참고하셔서 API설계 또는 운영시 안전하게 적용될 수 있었으면 좋겠습니다.

 

그럼 이만~!

Site Footer