내가 체크 해 봐야할 API들의 보안 취약점들

OWASP

OWASP 웹 애플리케이션 보안을 목표로 무료 콘텐츠와 도구를 만드는 비영리 재단. 가장 일반적인 API취약점 10가지를 정리하여 발표했다.

정보 누출

API응답, 코드 저장소, 검색 결과, 소셜 미디어, 대상의 웹사이트, 공개 API 디렉터리 같은 공개된 소스를 통해 누출될 수 있다.

1. 불필요하게 자세한 응답메시지
   • "제공된 사용자 ID가 존재하지 않습니다"라는 메시지를 통해 다른 ID를 넣어서 계속 시도를 했는데 만약 "잘못된 비밀번호입니다"라는 메시지가 나왔다면? 아! 이 메시지를 뱉으면 ID는 있는데 비밀번호만 찾으면 되겠네?! 하는 힌트를 주게된다.
2. API응답시 사용자 이름을 반환하여 공격자가 응답을 통해 취한 사용자 이름으로 무차별 비밀번호 대입, 비밀번호 스프레이등으로 로그인시도

BOLA

BOLA(객체 수준 권한 부여 결함)의 취약점은 API 공급자가 접근 궎나이 없는 데이터에 대한 접근을 허용할 때 발생한다. 즉 객체 수준의 접근 제어가 없으면 사용자권한만 있으면 모든 a사용자가 b의 데이터를 요청 할 수 있게된다. 백엔드 입장에서 보면 /api/v1/users?id=1 이라는 요청시에 권한에 id=1에 대한 데이터 소유권 및 권한을 체크하지 않을때 발생하는 문제인 것이다. 즉 1번 user 가 쿼리스트링만 바꿔서 다른 유저정보도 조회할 수 있게 되는 구조는 보안 위험이 있다라는 얘기.

사용자 인증 결함

API 인증 절차의 약점 전체를 뜻한다. 기본적으로 RESTful API는 무상태(STATELESS)구조 즉 요청자의 상태를 들고있지 않기때문에 보통 토큰 등으로 인증절차를 거친다. (요청때 마다 티켓을 들이미는 개념)
이때, 공격자는 API 토큰을 얻는 절차, 토큰에 대한 처리, 토큰 생성시스템을 분석했을때 사용자 인증 결함을 찾을 수 있게 되는 여지가 생긴다. 약점이 발견되면 직접 유효한 토큰을 만들 수 도 있고 다른사람의 토큰을 훔칠 수 도 있게된다.
혹은 등록절처에서 일반적인 SMS나 이메일을통해 6자리 인증번호를 받는 API가 rate limit이 안 걸려있으면 6자리니까 수없이 많은 요청을 통해 무조건 비밀번호를 리셋할 수 있게된다.
public 저장소에 key를 커밋한다던지..

데이터 과다 노출

API응답시 불필요한 정보까지 응답에 포함시키는 경우.

리소스 부족과 속도 제한

리소스 부족과 속도 제한 역시 반드시 테스트 해야할 취약점이다. 자원대비 요청이 너무 많으면 공급자의 시스템이 충돌하고 사용할 수 없게 서비스 거부 상태가 된다. 만약 공격자가 속도 제한을 우회한다면 API공급자의 비용문제도 발생할 가능성이 생긴다.
당연히 속도 제한이 있어야 하는 API를 테스트 할 때 가장 먼저 할 일은 속도 제한이 작동하는지 체크해야한다. 초과시 429 code추가

BFLA

BFLA(기능 수준 권한 부여 결함) 어떤 역할을 수행하는 사용자나 그룹이 다른 역할을 수행하는 사용자나 그룸의 API기능에 접근 할 수 있는 취약점이다.
권한을 벗어나는 기능에 대한 유효성검증이 없어 권한이상의 기능사용을 허용하는 경우이다. BOLA와 비슷하지만 데이터 접근에 결부된 권한 부여 문제가 아니라 작업 수행의 관점에 권한 문제가 생기는 점이다.

웹관점에서 보면 401 or 403을 던져야 할 상황에 그냥 200응답을 해줘버려서 데이터가 노출되는 경우도 BFLA에 해당할 것 같다.

대량할당

API 소비자가 요청에 애플리케이션이 의도한 것 보다 더 많은 매개변수를 집어넣고, 애플리케이션이 이러한 매개변수를 코드 변스나 내부객체에 추가되는 상황을 뜻한다. 이를 악용해 객체 프로퍼티를 수정하거나 권한 수정등을 시도해 볼 수 있는 여지를 주는것이다.
쉽게 말하면 dto가 있는데 dto에 존재하지 않는 필드값을 인위적으로 추가하여 API요청을 했는데 요청이 가능해지면 이 또한 보안 구멍이 될 수 있다는 뜻.

보안 설정 오류

개발자가 실수해서 구멍이 생긴 모든 경우는 보안 설정 오류에 해당한다. 유효성 검사가 없거나 미비하면 공격자가 이 포인트를 캐치하게 됐을때 얼마든지 공격할 수 있다.
API 제공자는 흔히 헤더를 사용해 소비자에게 응답과 보안 요건의 처리 방법을 제공한다. 헤더를 잘못 구성하면 민감한 정보 공개, 다운그래이드 공격, XSS등으로 이어질 수 있다.

• X-Powered-By : 백엔드에서 사용하는 기술을 명시
  • 해당 기술의 보안취약점을 아는사람이 있다면 공격당하기 쉽다.
• X-XSS-Protection : XSS 공격을 방지하는 헤더로 사용하지만 값이 0이면 보호기능이 없다는 뜻이고 1이면 보호기능이 작동하고 있다는 뜻이기때문에 만약 0이란게 노출되면 군침 싹 도는것이다.
• X-Response-Time : 요청대비 응답시간을 알려주는데 이또한 보안 위험이 될 수 있다. 예를들어 가짜 계정으로 로그인을 요청했더니 등록된 계정을 요청했을때보다 응답시간이 느리다면 이를 이용해서 무차별 대입 요청을 보내 API를 분석할 수 있는 여지를 주게 된다. 민감한 정보를 소비자에게 제공하는 API는 반드시 TLS를 사용해 데이터를 암호화 해야한다.

주입

주입 결함은 API 공급자가 원치않은 데이터를 제거하는 유효성 검사를 하지않고 백엔드에 전달할 때 발생한다. 그럼 이런 유효성검사를 하지 않는다는 것을 들키면 공격자는 군침 흘리면서 SQL주입, NoSQL주입, 시스템 명령어 주입 등 막 날려 보며 시스템의 구멍을 찾는다. 예를 들어 {"address" : "' OR 1=0--"} 같은 데이터를 집어넣었는데 응답으로 DB error로그가 있는그대로 보여지게 된다면? 이또한 보안구멍이 된다.

부적절한 자원 관리

사용 중지 됐거나 개발중인 API를 노출하는것을 말한다. 이는 불완전한 API를 공격자가 시험해 볼 수 있게 되기 때문에 아주 위험하다. 예를들어 /v1/ 과같은 버전 명시를 하는 경우가 많은데 공격자는 /v3/ 라는 uri를 보고 같은 uri에 /v2/ 이런식으로 버전만 바꿔서 호출해 볼 수 있다. 그런데 정상 응답이 온다면 이또한 보안 구멍이 된다.

비즈니스 로직 취약점

예를 들어 공격자가 악용할 수 잇는 애플리케이션 기능을 말한다. API가 인코딩 된 데이터의 유효성을 검사하지 않는다면 사용자는 어떤 파일이든 업로드 할 수 있게 된다. 보통 이런 취약점은 사용자가 설계자가 생각한데로 순순히 잘 써줄 꺼야 라는 믿음에서 발생한다. 하지만 선의의 사용자가 실수로 잘못올리더라도 이는 애플리케이션에 치명적인 문제를 일으킬 가능성이 있다.
이는 사용자가 A로 들어와서 B를 사용하고 C를 쓸것이다! 하고 그렇게 교육하면 되지?! 이런 안일한 생각이 아니라 A에서 B말고는 다른곳을 갈 수 없도록 막는 것이 올바른 보안 의식이 되는것이다.