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에 따라 출시된 무료 소프트웨어입니다.
이론적으로는 Apache APISIX 구성을 통해 Nnginx를 구성하는 것이 가능하지만 더 간단한 또 다른 방법이 있습니다.
OWASP 핵심 규칙 세트 및 Coraza
핵심 규칙 세트에 대한 설명은 우리의 요구 사항과 매우 관련이 있습니다.
OWASP® ModSecurity 핵심 규칙 세트(CRS)는 ModSecurity 또는 호환 가능한 웹 애플리케이션 방화벽과 함께 사용하기 위한 일반적인 공격 탐지 규칙 세트입니다. CRS는 최소한의 잘못된 경고로 OWASP Top Ten을 포함한 광범위한 공격으로부터 웹 애플리케이션을 보호하는 것을 목표로 합니다. CRS는 다음을 포함하여 많은 일반적인 공격 범주에 대한 보호 기능을 제공합니다.
- SQL 주입(SQLi)
- 크로스 사이트 스크립팅(XSS)
- LFI(로컬 파일 포함)
- RFI(원격 파일 포함)
- PHP 코드 삽입
- 자바 코드 삽입
- HTTPoxy
- 쉘쇼크
- Unix/Windows 쉘 주입
- 세션 고정
- 스크립팅/스캐너/봇 감지
- 메타데이터/오류 유출
OWASP는 Go 라이브러리로 사용할 수 있는 ModSecurity 포트인 Coraza 도 제공합니다. Coraza Proxy Wasm은 Coraza를 기반으로 구축되었으며 프록시에 대한 Wasm 인터페이스 세트를 지정하는 Proxy-wasm ABI를 구현합니다. 마지막으로 Apache APISIX는 프록시-wasm 통합을 제공합니다.
함께 모아서
요약하자면:
- 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를 강화할 수 있습니다.
더 나아가려면:
이 게시물의 전체 소스 코드는 GitHub 에서 찾을 수 있습니다.
원래 2024년 2월 4일 A Java Geek 에 게시되었습니다.