RESTful Api 사양은 취약성 스캐너에서 중요합니다.
APIGit
2023-07-27
웹 애플리케이션의 취약점을 찾는 방법은 무엇입니까?
오늘날 점점 더 많은 회사에서 웹 API를 제공하여 서비스에 액세스합니다. 일반적으로 REST 스타일을 따릅니다. 이러한 RESTful 웹 서비스는 일반 웹 애플리케이션처럼 보입니다. HTTP 요청을 수락하고 마법을 부린 다음 HTTP 응답으로 응답합니다. 주요 차이점 중 하나는 회신에 일반적으로 웹 브라우저에서 렌더링할 HTML이 포함되어 있지 않다는 것입니다. 대신 응답에는 일반적으로 다른 애플리케이션에서 처리하기 쉬운 형식(예: JSON 또는 XML)의 데이터가 포함됩니다.
안타깝게도 RESTful 웹 서비스는 여전히 웹 애플리케이션이기 때문에 SQL 주입, XXE 등과 같은 웹 애플리케이션에 대한 일반적인 보안 취약점을 포함할 수 있습니다. 웹 애플리케이션의 보안 문제를 식별하는 방법 중 하나는 웹 보안 스캐너를 사용하는 것입니다. 다행스럽게도 RESTful 웹 서비스는 여전히 웹 애플리케이션이므로 웹 보안 스캐너를 사용하여 웹 API의 보안 문제를 찾을 수 있습니다.
여러 잘 알려진 웹 보안 스캐너가 있습니다. 그 중 하나가 w3af입니다.
w3af는 취약점을 어떻게 찾습니까?
w3af는 웹 애플리케이션 공격 및 감사 프레임워크입니다. 이 프로젝트의 목표는 모든 웹 애플리케이션 취약점을 찾아 악용하여 웹 애플리케이션을 보호하는 데 도움이 되는 프레임워크를 만드는 것입니다. 이 프레임워크에는 취약점을 찾는 데 도움이 되는 수백 개의 플러그인이 포함되어 있습니다.
크롤링 플러그인은 다양한 기술을 사용하여 감사 및 무차별 대입 단계에서 사용될 수 있는 새로운 URL, 양식 및 기타 리소스를 식별합니다. 즉, 이러한 플러그인은 애플리케이션을 탐색하고 테스트할 진입점을 찾으려고 시도합니다.
감사 플러그인은 크롤링 플러그인으로 생성된 지식을 사용하여 원격 웹 애플리케이션 및 웹 서버의 취약점을 찾습니다. 이 플러그인은 발견된 진입점의 취약점을 테스트합니다.
일부 플러그인을 활성화하면 일부 취약점을 발견할 수 있지만 많지는 않습니다. 다음은 스프링 부트 웹 프로젝트의 결과입니다. 웹 스캐너는 일반적으로 취약성에 대해 테스트할 수 있는 모든 사용 가능한 페이지와 매개변수를 찾기 위해 웹 사이트를 탐색하려고 시도합니다. 일반적인 웹 사이트의 경우 스캐너는 종종 홈페이지에서 시작하여 HTML 코드에서 다른 페이지에 대한 링크를 찾습니다. 그러나 일반적으로 API 엔드포인트는 HTML 데이터를 제공하지 않으며 API는 일반적으로 응답에서 서로를 참조하지 않기 때문에 이 접근 방식은 웹 API에서 작동하지 않습니다.
{
"items": [
{
"href": "/scans/1/kb/0",
"id": 0,
"name": "Strange HTTP Reason message",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/1",
"id": 1,
"name": "Cross site tracing vulnerability",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/2",
"id": 2,
"name": "Omitted server header",
"url": null
},
{
"href": "/scans/1/kb/3",
"id": 3,
"name": "Allowed HTTP methods",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/4",
"id": 4,
"name": "Click-Jacking vulnerability",
"url": null
}
]
}
RESTful Api 사양은 스캐너에 중요합니다.
스캔할 API 엔드포인트 및 매개변수 목록을 어떻게 얻습니까? 두 가지 주요 방법이 있습니다.
- #1 RESTful API 사양 웹 서비스에는 모든 엔드포인트, 매개변수, 응답, 인증 체계 등을 설명하는 OpenAPI 사양이 있을 수 있습니다. 이러한 사양은 일반적으로 개발자가 제공합니다.
- #2 프록시 프록시를 사용하면 클라이언트가 API 끝점으로 보낸 HTTP 요청을 캡처할 수 있습니다. 그런 다음 캡처된 요청을 구문 분석하고 매개변수에 대한 정보를 추출할 수 있습니다.
방법 #1이 #2보다 훨씬 좋아 보입니다. 완벽한 세상에서 각 웹 서비스에는 항상 사용 가능하고 최신 상태인 OpenAPI 사양이 있습니다. 그러나 현실 세계에서는 그렇게 자주 발생하지 않는 것 같습니다. 개발자는 API를 변경했지만 사양 업데이트를 잊거나 어떤 이유로 사양을 공개하지 않을 수 있습니다. 대부분의 경우 공개적으로 사용 가능한 REST API에는 사람이 읽을 수 있는 문서가 있지만 일반적으로 자동화된 방식으로 사용하기는 어렵습니다.
- 그러나 APIGIT를 사용하면 이를 더 쉽게 만들 수 있습니다.
APIGIT는 API 개발 프로세스 및 버전 제어를 단순화하여 사용자가 API를 쉽게 설계, 문서화, 목업화, 테스트 및 공유할 수 있도록 하는 기본 Git 지원이 돋보이는 협업 플랫폼입니다. 플랫폼의 시각적 OpenAPI 편집기는 기본 Git 지원과 결합되어 팀이 원활하고 효율적인 방식으로 작업을 쉽게 협업하고 공유할 수 있도록 합니다.
RESTful Api 사양에 따라 w3af는 어떻게 취약점을 찾나요?
다음은 내 RESTful API 사양의 일부입니다.
"paths": {
"/find_pet": {
"get": {
"summary": "List pet",
"operationId": "listPet",
"tags": [
"pet"
],
"parameters": [
{
"name": "version",
"in": "query",
"description": "Get pet by version",
"required": true,
"type": "string"
}
],
RESTful Api 사양으로 관련 플러그인 및 피드를 활성화하여:
[crawl.open_api]
custom_spec_location = /var/log/wvs/openapi2.json
no_spec_validation = True더 많은 취약점을 찾을 수 있습니다.
{
"items": [
{
"href": "/scans/0/kb/0",
"id": 0,
"name": "Strange HTTP Reason message",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/1",
"id": 1,
"name": "Omitted server header",
"url": null
},
{
"href": "/scans/0/kb/2",
"id": 2,
"name": "Cross site tracing vulnerability",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/3",
"id": 3,
"name": "Open API specification found",
"url": "file:///var/log/wvs/openapi2.json"
},
{
"href": "/scans/0/kb/4",
"id": 4,
"name": "Allowed HTTP methods",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/5",
"id": 5,
"name": "Cross site scripting vulnerability",
"url": "http://192.168.1.65:8181/find_pet"
},
{
"href": "/scans/0/kb/6",
"id": 6,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/_pet"
},
{
"href": "/scans/0/kb/7",
"id": 7,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/find_"
},
{
"href": "/scans/0/kb/8",
"id": 8,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/9",
"id": 9,
"name": "Strange HTTP response code",
"url": "http://192.168.1.65:8181/%2Fbin%2Fcat+%2Fetc%2Fpasswd_pet"
},
{
"href": "/scans/0/kb/10",
"id": 10,
"name": "Click-Jacking vulnerability",
"url": null
}
]
}
crawl.open_api 플러그인에 대해 이야기해 봅시다. 플러그인의 첫 번째 버전은 다음과 같은 잘 알려진 위치 중 하나에서 OpenAPI 사양을 찾으려고 했습니다.
/api/openapi.json
/api/v2/swagger.json
/api/v1/swagger.yaml
등등. 아주 좋은 기능입니다. 테스트할 웹 서비스가 여러 개 있고 잘 알려진 위치에서 해당 API 사양을 사용할 수 있는 경우 스캐너에 호스트 이름을 입력하기만 하면 됩니다. 그게 전부입니다. 스캐너는 자체적으로 모든 API 끝점을 찾은 다음 테스트합니다. 안타깝게도 때때로 웹 서비스는 API 사양을 제공하지 않으며 custom_spec_file 매개변수는 OpenAPI 사양에 대한 로컬 경로를 설정할 수 있습니다. 사용자는 API 문서를 사용하여 스스로 사양을 구축할 수 있습니다. 또는 사양이 공개적으로 사용 가능하지만 잘 알려진 위치에 없는 경우도 있습니다.
