API 보안 101: 손상된 객체 수준 라이센스

API는 모든 사람에게 무료 대상을 제공한다

사진 작성자CHUTTERSNAP가 Unsplash
나는 최근에 정말 API 보안을 배우기 시작했다.내 책의 초고를 작성할 때, 나의 기술 편집자인 Aaron Guzman은 내가 네트워크 안전에 관한 책은 API 장과 절이 있어야만 완성할 수 있다고 지적했다.
그의 말은 매우 일리가 있다.현대 응용 프로그램이 점점 복잡해지면서 API 구축을 점점 더 많이 사용하고 있다.점점 더 많은 API가 중요한 작업을 수행하거나 중요한 정보를 전달할 수 있습니다.이로 인해 API 취약점은 보안 취약점과 데이터 유출의 광범위한 소스가 됩니다.이는 API, API의 취약점, 이를 방지하는 방법에 대한 이해가 필요하다는 뜻이다.

API 톱10

OWASP의 10대 빈틈이나 웹 응용 프로그램을 위협하는 10대 빈틈을 들어보셨을 수도 있습니다.또한 OWASP는 정기적으로 위협 API의 상위 10개 취약점 목록(OWASP API 상위 10개)을 선택합니다.현재 API 상위 10위는 대상급 권한 수여 중단, 사용자 신분 검증 중단, 데이터 노출 과도, 자원 및 속도 제한 부족, 기능급 권한 수여 중단, 대규모 분배, 안전 설정 오류, 주입, 자산 관리 부적절, 로그 기록과 모니터링 부족이다.
API 이외에도 많은 취약점이 응용 프로그램 구성 요소에 영향을 미치지만, 종종 API에서 나타난다.오늘 OWASP API#1 취약점에 대해 살펴보겠습니다. 개체 수준의 라이센스가 손상되었습니다.

OWASP API#1

API는 일반적으로 리소스에 액세스하는 데 사용되는 객체 식별자를 공개합니다.액세스 제어가 이 단점에서 정확하게 실현되지 않았을 때 공격자는 그들이 방문하지 말아야 할 자원을 보거나 조작할 수 있다.이 취약점은 SOAP, REST 및 GraphQL을 비롯한 모든 API 아키텍처에 영향을 미칩니다.
예를 들자!API를 사용하면 사용자가 사용자 ID를 기반으로 결제 방법에 대한 세부 정보를 검색할 수 있습니다.

https://api.example.com/v1.1/users/payment/show?user_id=12

여기서 앱이 API 호출에서 추가 신분증을 필요로 하지 않고 요청한 데이터를 누구에게도 되돌려주면 프로그램은 민감한 정보를 공격자에게 노출한다.공격자는 피해자의 ID를 추측, 유출 또는 강제로 사용하고 API 엔드포인트를 통해 지급 정보를 훔칠 수 있다.
일반적으로 응용 프로그램은 사용자가 사용자 ID가 아닌 객체 ID를 기반으로 데이터 객체에 액세스할 수 있도록 합니다.예.com에는 사용자가 개인 메시지의 내용을 검색할 수 있도록 하는 API 포트가 하나 더 있습니다.디지털 ID를 사용하여 메시지를 참조하려면 다음과 같이 하십시오.

https://api.example.com/v1.1/messages/show?id=12345

만약 서버가 이 단점에서 접근 제어를 실현하지 못한다면 공격자는 이 디지털 ID를 강제로 사용하여 다른 사용자의 정보를 검색할 수 있습니다!
이것들은 모두 파괴된 대상급 권한 수여의 실례이다.사용자가 단일 데이터 대상에 접근하기 전에 신분 검사를 하지 않았습니다.서버에서 사용자가 올바른 사용자인지 확인하지 못했습니다.그것은 단지 너의 요구에 따라 정보를 되돌려 주었을 뿐이다.
이러한 문제는 데이터 객체의 끝을 읽는 것 외에 데이터 항목을 업데이트, 삭제 또는 생성하는 API 끝에도 영향을 미칠 수 있습니다.예를 들어GraphQL 구현에서 흔히 볼 수 있는 문제는 API가 권한을 부여받지 않은 사용자가 요청에서 ID를 닫아서 데이터를 편집할 수 있도록 허용하는 것이다.

무슨 문제가 생길지

대상 레벨 접근 제어 중단의 영향은 노출된 데이터 대상에 달려 있습니다.사용자의 PII와 자격 증명 등 핵심 대상이 노출되면 이 취약점으로 인해 데이터가 유출되거나 애플리케이션이 손상될 수 있습니다.
공격자는 이 빈틈을 더욱 적극적으로 이용할 수 있다. 공격자는 모든 사용자 ID를 조회하고 데이터를 자동으로 긁어내는 스크립트를 작성할 수 있다.만약 이 빈틈이 온라인 쇼핑몰에서 발생한다면 공격자는 수백만 개의 은행 계좌, 신용카드 번호, 주소를 얻을 수 있을 것이다.만약 은행 사이트에서 이 빈틈을 발견한다면 공격자는 모든 사람의 신용 정보와 세무 표를 누설할 수 있습니다!
암호 재설정, 암호 변경, 계정 복구 등 관건적인 기능에서 쓰기 기반의 손상 대상 레벨 접근 제어가 발생하면 공격자는 일반적으로 이러한 빈틈을 이용하여 사용자나 관리자 계정을 인수할 수 있다.

나는 어떻게 해야만 이런 상황을 방지할 수 있습니까?

이 문제를 방지하는 이상적인 방법은 방문 영패나 다른 형식의 비밀리에 API 사용자의 신분을 추정하는 것이다.그런 다음 특정 권한이 필요한 모든 민감한 API 엔드포인트에서 액세스 제어를 수행합니다.또한 각 API 엔드포인트와 요청 방법에 대한 감사 및 적절한 보호가 필요하다는 점을 기억하십시오.예를 들어, 나는 API가 실현되는 것을 자주 보았는데, 간단하게 다른 요청 방법으로 바꾸면 컨트롤을 돌아갈 것이다.
만약 불가능하다면, 간단한 디지털 ID가 아닌 무작위와 예측할 수 없는 값을 사용하여 데이터 대상을 인용합니다.그러나 단순히 하나의 랜덤 ID를 사용하는 것은 ID가 유출되거나 도둑맞을 수 있기 때문에 전면적인 보호로 여겨질 수 없다.API 끝점이 액세스 제어에 의해 제한되지 않는다고 가정합니다.

[https://api.example.com/v1.1/messages/show?id=d0c240ea139206019f692d](https://api.example.com/v1.1/messages/show?id=d0c240ea139206019f692d)

정보를 인용하는 데 사용되는 ID를 추측하기는 어렵지만 공격자가 이 ID를 훔치거나 누설할 수도 있다.이러한 ID는 브라우저에서 사용 내역을 확장하고 탐색하는 데도 사용할 수 있습니다.
개발자로서 대상급 권한 수여가 파괴되는 것을 방지하는 것이 당신의 최우선 과제입니다.그러나 적절한 객체 수준의 권한이 있는 API라도 공격에 취약할 수 있습니다.API 서비스에 적합한 인증 메커니즘을 구현하는 것도 까다로울 수 있습니다.다음은 OWASP API 상위 10위 #2, 파괴된 사용자 인증, 그리고 인증 문제가 어떻게 약한 영패, 장수 영패와 영패가 유출되는 형식으로 API에 나타나는지 살펴본다.다음은 API 토큰, 그리고 왜 그것들은 때때로 거대한 악몽인지.안녕히 계세요!
당신은 또 어떤 다른 안전 개념을 알고 싶습니까?알고 싶어요.마음대로 트위터에 접속하세요.
응용 프로그램 안전에 대해 더 알고 싶으세요?OWASP 10대 강좌 https://www.shiftleft.io/learn/를 무료로 수강할 수 있습니다.