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을 처리할 수 있는 기본 구성을 제공하며 이는 이라는 구성을 통해 해결할 수 있습니다. 불행히도 ModSecurity를 대상으로 합니다. Core Rule Set 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를 기반으로 구축되었으며 프록시에 대한 Wasm 인터페이스 세트를 지정하는 구현합니다. 마지막으로 Apache APISIX는 프록시-wasm 통합을 제공합니다. Coraza Coraza Proxy Wasm은 Proxy-wasm ABI를 함께 모아서 요약하자면: OWASP는 상위 10개 웹 보안 취약점 목록을 제공합니다. 핵심 규칙 세트를 통해 ModSecurity에 대해 구현합니다. 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 더 나은 유지 관리를 위해 변수 정의 Coraza Wasm 릴리스 받기 최근 APISIX 버전에서는 보안을 강화하기 위해 사용자가 입니다. 패키지를 설치해야 하므로 로 전환해야 합니다. apisix root 설치되어 있지 않으므로 설치하고, 다운로드한 아카이브의 압축을 풀고, 아카이브를 제거하고, 제거하고, 추출된 폴더의 소유자를 변경하세요. unzip unzip 사용자 로 다시 전환 apisix 다음 단계는 Coraza Wasm 플러그인을 사용하도록 APISIX 자체를 구성하는 것입니다. wasm: plugins: - name: coraza-filter #1 priority: 7999 #2 file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3 Wasm 코드에 설정된 필터 이름 다른 플러그인보다 먼저 실행되도록 가장 높은 우선순위를 설정하세요. 추출된 파일의 경로는 위의 참조하세요. 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 이제 플러그인을 구성할 수 있습니다. coraza-filter 구성을 정의합니다. 여기서는 단일 항목을 정의하지만 여러 개를 정의하고 다른 경로에서 다른 항목을 사용할 수도 있습니다. default 로그 수준을 높여 로그에서 어떤 일이 일어나는지 확인하세요. 엔진을 켜세요 Coraza 설정 사용 모든 규칙을 사용하십시오. 보다 세밀한 제어를 위해 원하는 것을 선택하고 선택할 수 있습니다. 위에 정의된 구성을 사용하세요. 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를 강화할 수 있습니다. 더 나아가려면: OWASP 보안 상위 10 OWASP ModSecurity 핵심 규칙 세트 OWASP 코라자 WAF APISIX - Coraza와 통합 이 게시물의 전체 소스 코드는 에서 찾을 수 있습니다. GitHub 원래 2024년 2월 4일 에 게시되었습니다. A Java Geek