paint-brush
Apache APISIX API 게이트웨이를 사용하여 웹 취약점을 해결하는 방법~에 의해@nfrankel
254 판독값

Apache APISIX API 게이트웨이를 사용하여 웹 취약점을 해결하는 방법

~에 의해 Nicolas Fränkel9m2024/02/10
Read on Terminal Reader

너무 오래; 읽다

Coraza 및 핵심 규칙 세트를 사용하여 OWASP Top 10에 대해 Apache APISIX를 강화할 수 있습니다.
featured image - Apache APISIX API 게이트웨이를 사용하여 웹 취약점을 해결하는 방법
Nicolas Fränkel HackerNoon profile picture


Open Worldwide Application Security Project는 IoT, 시스템 소프트웨어 및 웹 애플리케이션 보안 분야에서 무료로 사용할 수 있는 기사, 방법론, 문서, 도구 및 기술을 생산하는 온라인 커뮤니티입니다. OWASP는 무료 개방형 리소스를 제공합니다. OWASP 재단이라는 비영리 단체가 이 단체를 이끌고 있습니다. OWASP Top 10 - 2021은 40개가 넘는 파트너 조직에서 수집한 포괄적인 데이터를 기반으로 한 최근 연구 결과입니다.

-- OWASP 웹사이트


OWASP는 정기적으로 상위 10개 취약점 보고서를 발행합니다. 이 보고서는 웹 애플리케이션의 취약점을 대상으로 합니다.


이번 포스팅에서는 Apache APISIX API Gateway를 통해 그 중 일부를 수정하는 방법을 설명하고 싶습니다.

2021년 OWASP 상위 10위

2021년에 보고서는 다음과 같이 언급합니다.


  • A01:2021-깨진 액세스 제어
  • A02:2021-암호화 오류
  • A03:2021-주입
  • A04:2021-안전하지 않음
  • A05:2021-보안 구성 오류
  • A06:2021-취약하고 오래된 구성 요소
  • A07:2021-식별 및 인증 실패
  • A08:2021-소프트웨어 및 데이터 무결성 오류
  • A09:2021-보안 로깅 및 모니터링 실패
  • A10:2021-서버측 요청 위조


자세한 내용은 전체 보고서를 확인하세요.


취약점 수정은 취약점의 정확한 성격에 따라 달라집니다. 예를 들어, 취약하고 오래된 구성 요소를 수정하는 작업은 프로세스 중심으로 이루어지므로 버전 관리 및 이전 구성 요소 폐기에 대한 규율이 필요합니다. 그러나 일부는 기술적이며 역방향 프록시 또는 API 게이트웨이에서 적절한 구성만 필요합니다 (예 : 서버 측 요청 위조) .

아무도 보안에 신경쓰지 않아

보안을 강화해도 비즈니스에 어떤 가치도 가져오지 않기 때문에 보안은 민감한 주제입니다. 경력 중심의 관리자는 다음 연간 평가에서 회사 이익이 X% 증가했음을 보여줄 수 없기 때문에 보안에 신경 쓰지 않을 것입니다. 이사회가 보안을 심각하게 고려하지 않는 한 아무도 관심을 갖지 않을 것입니다. 이러한 이유로 대부분의 조직에서는 그럴듯한 거부성이라고도 불리는 체크박스 기반 보안을 구현합니다. 보안을 적절하게 구현하는 데 관심이 있다면 이전 블로그 게시물에서 보안을 위험으로 다루십시오라는 몇 가지 생각을 적어 두었습니다.


대체로, 애플리케이션 보안은 많은 예산을 확보하지 못할 것입니다. 따라서 우리는 이에 대해 현명하게 생각하고 기존 구성 요소를 검색해야 합니다. 다행히 OWASP는 Top 10을 처리할 수 있는 기본 구성을 제공하며 이는 Core Rule Set 이라는 구성을 통해 해결할 수 있습니다. 불행히도 ModSecurity를 대상으로 합니다.


Modsec이라고도 불리는 ModSecurity는 오픈 소스 웹 애플리케이션 방화벽(WAF)입니다. 원래 Apache HTTP Server용 모듈로 설계되었지만 Apache HTTP Server, Microsoft IIS 및 Nginx를 포함한 다양한 플랫폼에 걸쳐 기타 보안 기능과 함께 일련의 Hypertext Transfer Protocol 요청 및 응답 필터링 기능을 제공하도록 발전했습니다. Apache 라이센스 2.0에 따라 출시된 무료 소프트웨어입니다.

-- Wikipedia의 ModSecurity


이론적으로는 Apache APISIX 구성을 통해 Nnginx를 구성하는 것이 가능하지만 더 간단한 또 다른 방법이 있습니다.

OWASP 핵심 규칙 세트 및 Coraza

핵심 규칙 세트에 대한 설명은 우리의 요구 사항과 매우 관련이 있습니다.


OWASP® ModSecurity 핵심 규칙 세트(CRS)는 ModSecurity 또는 호환 가능한 웹 애플리케이션 방화벽과 함께 사용하기 위한 일반적인 공격 탐지 규칙 세트입니다. CRS는 최소한의 잘못된 경고로 OWASP Top Ten을 포함한 광범위한 공격으로부터 웹 애플리케이션을 보호하는 것을 목표로 합니다. CRS는 다음을 포함하여 많은 일반적인 공격 범주에 대한 보호 기능을 제공합니다.

  • SQL 주입(SQLi)
  • 크로스 사이트 스크립팅(XSS)
  • LFI(로컬 파일 포함)
  • RFI(원격 파일 포함)
  • PHP 코드 삽입
  • 자바 코드 삽입
  • HTTPoxy
  • 쉘쇼크
  • Unix/Windows 쉘 주입
  • 세션 고정
  • 스크립팅/스캐너/봇 감지
  • 메타데이터/오류 유출

-- OWASP® ModSecurity 핵심 규칙 세트 웹사이트


OWASP는 Go 라이브러리로 사용할 수 있는 ModSecurity 포트인 Coraza 도 제공합니다. Coraza Proxy Wasm은 Coraza를 기반으로 구축되었으며 프록시에 대한 Wasm 인터페이스 세트를 지정하는 Proxy-wasm ABI를 구현합니다. 마지막으로 Apache APISIX는 프록시-wasm 통합을 제공합니다.

함께 모아서

요약하자면:


  1. OWASP는 상위 10개 웹 보안 취약점 목록을 제공합니다.
  2. 핵심 규칙 세트를 통해 ModSecurity에 대해 구현합니다.
  3. Coraza는 프록시-wasm 구현으로 사용 가능한 ModSecurity의 포트입니다.


이런 방식으로 정상적이고 안전한 기본값으로 Apache APISIX를 구성할 수 있습니다. 해보자.

가장 먼저 해야 할 일: Coraza는 Apache APISIX 배포판의 일부가 아닙니다. 그러나 Docker를 사용하여 여기에 추가하는 것은 간단합니다.


 FROM apache/apisix:3.8.0-debian ENV VERSION 0.5.0 #1 ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip #1 ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2 USER root #3 RUN <<EOF apt-get install zip -y #4 unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm rm $CORAZA_FILENAME apt-get remove zip -y chown -R apisix:apisix /usr/local/apisix/proxywasm EOF USER apisix #5
  1. 더 나은 유지 관리를 위해 변수 정의
  2. Coraza Wasm 릴리스 받기
  3. 최근 APISIX 버전에서는 보안을 강화하기 위해 사용자가 apisix 입니다. 패키지를 설치해야 하므로 root 로 전환해야 합니다.
  4. unzip 설치되어 있지 않으므로 설치하고, 다운로드한 아카이브의 압축을 풀고, 아카이브를 제거하고, unzip 제거하고, 추출된 폴더의 소유자를 변경하세요.
  5. 사용자 apisix 로 다시 전환


다음 단계는 Coraza Wasm 플러그인을 사용하도록 APISIX 자체를 구성하는 것입니다.


 wasm: plugins: - name: coraza-filter #1 priority: 7999 #2 file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3
  1. Wasm 코드에 설정된 필터 이름
  2. 다른 플러그인보다 먼저 실행되도록 가장 높은 우선순위를 설정하세요.
  3. 추출된 파일의 경로는 위의 Dockerfile 참조하세요.


마지막으로 플러그인을 경로에 할당하거나 이를 전역 규칙으로 설정하여 모든 경로에 적용할 수 있습니다. 정적 구성을 사용하고 있습니다.


 global_rules: - id: 1 plugins: coraza-filter: #1 conf: directives_map: #2 default: - SecDebugLogLevel 9 #3 - SecRuleEngine On #4 - Include @crs-setup-conf #5 - Include @owasp_crs/*.conf #6 default_directives: default #7
  1. 이제 coraza-filter 플러그인을 구성할 수 있습니다.
  2. 구성을 정의합니다. 여기서는 default 단일 항목을 정의하지만 여러 개를 정의하고 다른 경로에서 다른 항목을 사용할 수도 있습니다.
  3. 로그 수준을 높여 로그에서 어떤 일이 일어나는지 확인하세요.
  4. 엔진을 켜세요
  5. Coraza 설정 사용
  6. 모든 규칙을 사용하십시오. 보다 세밀한 제어를 위해 원하는 것을 선택하고 선택할 수 있습니다.
  7. 위에 정의된 default 구성을 사용하세요.


설정을 테스트하기 위해 https://httpbin.org/ 에 대한 경로를 정의합니다. /get 에 대한 경로를 호출해 보겠습니다.


 curl localhost:9080?user=foobar


응답은 예상대로입니다.


 { "args": { "user": "foobar" }, "headers": { "Accept": "*/*", "Host": "localhost", "User-Agent": "curl/8.4.0", "X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204", "X-Forwarded-Host": "localhost" }, "origin": "192.168.65.1, 176.153.7.175", "url": "http://localhost/get?user=foobar" }


이제 쿼리 문자열에 JavaScript를 전송해 보겠습니다. 이 요청은 서버 측에서 예상되는 방식이 아니므로 우리 인프라는 이 요청으로부터 우리를 보호해야 합니다.


 curl 'localhost:9080?user=<script>alert(1)</script>'


응답은 403 HTTP 상태 코드입니다. 로그를 보면 다음 힌트를 볼 수 있습니다.


 Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection Coraza: Warning. Javascript method detected Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1


코라자가 그 일을 해냈어요!

결론

대부분의 조직은 보안에 대한 인센티브를 제공하지 않습니다. 그러므로 우리는 이에 대해 현명하게 생각하고 기존 구성 요소를 최대한 많이 사용해야 합니다.


Coraza 및 핵심 규칙 세트를 사용하여 OWASP Top 10에 대해 Apache APISIX를 강화할 수 있습니다.


더 나아가려면:



이 게시물의 전체 소스 코드는 GitHub 에서 찾을 수 있습니다.


원래 2024년 2월 4일 A Java Geek 에 게시되었습니다.