[AWS] WAF 침입 탐지 및 보호

아마존 클라우드

[AWS] WAF 침입 탐지 및 보호

트리스탄1234 2025. 3. 26. 15:49

728x90

이미지 설명: 위 다이어그램은 데이터 흐름을 보여줍니다. 트래픽은 Pen Testing Host라고 하는 EC2 인스턴스에서 AWS WAF를 거쳐 Application Load Balancer 앞에 있는 Cloudfront 배포로 이동합니다. 그러면 ALB가 요청을 Auto Scaling 그룹에 전달합니다.
다음 목록에는 다이어그램에서 가장 중요한 리소스에 대한 세부 정보가 나와 있습니다.

2개의 프라이빗 서브넷과 1개의 퍼블릭 서브넷이 2개의 가용 영역에 분산되어 있는 VPC.
Auto Scaling 그룹 앞에 배치된 내부용 Application Load Balancer 및 2개의 노드.
Application Load Balancer를 향하는 Cloudfront 배포.
트래픽은 Cloudfront 배포에 도달하기 전에 AWS WAF를 통과합니다.
퍼블릭 서브넷에 위치한 PenTestingHost라는 EC2 인스턴스.

이 과제에서는 Fleet Manager를 사용하여 Windows Server EC2 인스턴스에 연결합니다. 인스턴스에 연결한 후에는 OWASP Zed Attack Proxy(ZAP) 및 Firefox를 구성합니다. OWASP ZAP Proxy는 Open Worldwide Application Security Project(OWASP)에서 유지 관리하는 오픈 소스 침투 테스트 도구입니다. ZAP는 ‘중간자 공격’ 프록시로서 테스터의 브라우저와 대상 웹 앱 간의 모든 통신을 가로챕니다. 이를 통해 침투 테스터는 취약성을 발견하기 위해 요청 및 응답을 검사, 수정, 조작할 수 있습니다.

실습 시작

실습을 시작하려면 페이지 상단에서 실습 시작을 선택합니다.

계속 진행하기 전에 프로비저닝된 AWS 서비스가 준비될 때까지 기다려야 합니다.

실습을 열려면 콘솔 열기를 선택합니다.

그러면 새 웹 브라우저 탭에서 자동으로 AWS Management Console에 로그인됩니다.
별다른 지시가 없는 한 리전을 변경하지 마십시오.

일반적인 로그인 오류

오류: 우선 로그 아웃 필요

You must first log out before logging into a different AWS account라는 메시지가 표시된다면 다음을 수행합니다.

click here의 링크를 선택합니다.
Amazon Web Services Sign In 웹 브라우저 탭을 닫고 초기 실습 페이지로 돌아갑니다.
콘솔 열기를 다시 선택합니다.

오류: 실습 시작 선택 시 아무 반응이 없음

경우에 따라 일부 팝업 또는 스크립트 차단 웹 브라우저 확장 프로그램 때문에 실습 시작 버튼이 제대로 작동하지 않을 수 있습니다. 실습을 시작하는 데 문제가 있는 경우 다음을 수행합니다.

팝업 또는 스크립트 차단 프로그램의 허용 목록에 실습 도메인 이름을 추가하거나 차단 프로그램을 끕니다.
페이지를 새로 고친 후 다시 시도하십시오.

과제 1: OWSAP Zap 및 Firefox 구성

이 지침의 왼쪽에 있는 패널에 일련의 URL이 있습니다. PenetrationTestingHost라는 URL을 복사하여 새 브라우저 탭에 붙여넣습니다.

그러면 Fleet Manager - Remote Desktop 연결 페이지로 이동합니다.
경고: Fleet Manager RDP의 경우 Chrome 브라우저만 RDP 세션과 로컬 시스템 간의 양방향 복사 및 붙여넣기를 지원하기 때문에 인터넷 브라우저로 Chrome만 사용하십시오.
참고: Fleet Manager에서 RDP를 사용할 수 없는 경우에는 원격 데스크톱 클라이언트를 사용하여 Windows 인스턴스에 연결할 수도 있습니다.

Authentication type에서 Key pair를 선택합니다.
이 지침의 왼쪽에 있는 패널에서 Download PEM을 선택합니다.
파일을 원하는 디렉터리에 저장합니다.
Key pair content에 Browse your local machine to select the key pair file을 선택합니다.
Browse 버튼을 선택하여 로컬 시스템의 PEM 키를 찾아 업로드합니다.
Connect 버튼을 선택하여 PenTestingHost가 연결된 RDP 세션을 시작합니다.

주의: Fleet Manager RDP 연결은 최대 세션 기간이 60분입니다. 이 기간에 도달하면 Fleet Manager가 세션을 종료합니다. Fleet Manager를 통해 인스턴스와 상호 작용하는 동안 문제가 발생하면 Actions 드롭다운 메뉴를 열고 Renew session을 선택하여 세션을 다시 시작하십시오.

4개의 화살표가 있는 아이콘 을 선택하여 RDP 세션이 있는 창을 확장합니다.

참고: Do you want to allow your PC to be discoverable by other PCs and devices on this network? 라고 묻는 Networks 팝업 창이 표시되면 No를 선택합니다.

OWASP ZAP 2.12.0이라는 바탕 화면 바로 가기를 선택하여 ZAP 애플리케이션을 엽니다.

ZAP 로깅 터미널이 나타나고 애플리케이션 시작 화면이 열립니다. 구성 프로세스가 완료될 때까지 기다리고 화면에 나타나는 창을 닫지 마십시오.
자세히 알아보기: OWASP ZAP에 대한 자세한 내용은 OWASP Zed Attack Proxy(ZAP)를 참조하십시오.

ZAP 세션을 유지할지 묻는 팝업 창이 나타납니다. Yes, I want to persist this session with name based on the current timestamp를 선택하고 Start 버튼을 선택합니다.
화면 상단에서 maximize 버튼을 선택하여 ZAP 콘솔 창을 확장합니다.
도구 모음에서 진한 녹색 원을 찾아 선택합니다. 이것은 Disable the ZAP HUD 버튼입니다.

이미지 설명: 위의 이미지는 도구 모음의 진한 녹색 버튼을 보여줍니다.

화면 가운데에서 Manual Explore 버튼을 선택합니다.

이미지 설명: 위의 이미지는 ZAP UI의 Manual Explore 버튼을 보여줍니다.
그러면 Manual Explore 페이지로 이동합니다.

다음 옵션을 구성합니다.

이 지침의 왼쪽에 있는 패널에서 JuiceShopURL이라는 URL을 복사하고 ZAP의 URL to explore 필드에 붙여넣습니다.
Enable HUD 확인란은 선택하지 않은 상태로 둡니다.
Explore your application 옆의 드롭다운 메뉴를 열고 Firefox를 선택합니다.
Launch Browser 버튼을 선택합니다.

이미지 설명: 위의 이미지는 UnprotectedJuiceShop URL, 활성화된 HUD, 브라우저로 선택된 Firefox를 보여줍니다.
참고: ZAP은 ZAP을 통해 자동으로 Firefox를 프록시에 구성합니다. 그러므로 HTTPS를 사용하는 사이트에 대한 인증서 유효성 검사 경고를 신경 쓸 필요가 없습니다.
Firefox가 열리고 JuiceShop 애플리케이션에 연결됩니다.
축하합니다! 성공적으로 침투 테스트를 위해 OWASP ZAP 및 Firefox를 구성했습니다. 다음 과제에서는 대상에 대한 정찰을 수행합니다.

과제 2: 정찰

이 과제에서는 공격에 도움이 될 유용한 정보를 얻기를 바라며 정찰을 수행합니다. 정찰 테스트는 SQL 명령어 삽입 및 XSS 공격에 취약한 양식 필드를 확인하는 데 도움이 될 수 있습니다. 사용되는 데이터베이스 스키마 또는 소프트웨어 버전에 대한 세부 정보를 드러낼 수 있는 오류 메시지를 찾을 수도 있습니다.

과제 2.1: HTTP 요청 생성

다음 단계에서는 Juice Shop 애플리케이션과 상호 작용합니다. 상호 작용에 의해 생성된 HTTP 요청을 ZAP 콘솔에서 가로채고 로깅합니다. 이후 단계에서 애플리케이션을 악용하도록 이러한 요청을 수정하고 재전송합니다.

웹 인터페이스에서 다음 작업을 수행합니다.

검색 창을 사용하여
apple juice
를 검색합니다.
등록 페이지 (https://[JuiceShopDomain].cloudfront.net/#/register) 로 이동하여 새 사용자를 생성합니다.
로그인 페이지 (https://[JuiceShopDomain].cloudfront.net/#/login) 로 이동하여 방금 생성한 새 사용자로 로그인합니다.

이미지 설명: 위의 이미지는 검색 창의 위치를 보여줍니다.
참고: 경우에 따라 새로 생성한 사용자가 활성화되도록 잠시 기다려야 할 수도 있습니다. 로그인할 수 없는 경우 30초 동안 기다렸다가 다시 시도하십시오.

과제 2.2: SQL 명령어 삽입

‘apple juice’를 검색하고 새 사용자를 생성한 다음 해당 사용자로 로그인할 때 애플리케이션에 전송된 API 요청을 ZAP에서 가로챘습니다. 다음 단계에서는 ZAP 콘솔을 사용하여 이러한 요청을 찾아 수정한 후 애플리케이션을 악용할 수 있는지 확인합니다.

Windows 인터페이스 하단의 작업 표시줄에서 파란색 OWASP ZAP 아이콘을 선택하여 ZAP 콘솔로 돌아갑니다.

이미지 설명: 위의 이미지는 Windows 작업 표시줄의 OWASP ZAP 아이콘을 보여줍니다.
이제 ZAP 콘솔을 사용하여 SQL 명령어 삽입에 취약한 입력 필드가 있는지 알아보겠습니다.

ZAP 콘솔 하단에 있는 패널에서 Search 버튼을 선택합니다.

이미지 설명: 위의 이미지는 ZAP 콘솔의 Search 버튼을 보여줍니다.
다음 단계에서는 Juice Shop 애플리케이션이 애플리케이션 및 데이터베이스에 대한 정보를 제공하는 오류 메시지를 표시하도록 해 봅니다.
참고: 오류 기반 명령어 삽입은 오류 메시지에 포함된 정보를 활용하여 데이터베이스에 저장된 정보 유형 및 그 구조를 알아냅니다.

명령: Search 필드에 를 입력하고 ENTER 키를 누릅니다.
apple juice
검색 결과에서 다음 URL이 포함된 GET 요청을 찾습니다. https://[JuiceShopDomain].cloudfront.net/rest/products/search?q=. 컨텍스트 메뉴를 열어(마우스 오른쪽 버튼 클릭) Open/Resend with Request Editor를 선택합니다.

이미지 설명: 위의 이미지는 /rest/products/search?q=로 끝나는 URL을 보여줍니다.
Manual Request Editor가 열립니다. 여기에는 Request 및 Response라는 두 개의 탭이 있고, 각 탭은 두 개의 패널로 분할되어 있습니다. 헤더는 위쪽 패널에 표시되고 메시지 본문은 아래쪽 패널에 표시됩니다. 이 창을 통해 HTTP 요청을 수정한 후 재전송할 수 있습니다. 먼저 쿼리 문자열에 부울 공격을 전달하여 검색 필드를 악용할 수 있는지 테스트합니다.
참고: HTTP 쿼리 문자열은 물음표(?) 뒤에 오는 URL의 일부이며 HTTP 요청의 일부로 추가 데이터를 웹 서버에 전송하는 데 사용됩니다. 검색 창에서

apple juice

를 제출했을 때 apple%20juice(apple juice의 URL 인코딩에 해당)가 쿼리 문자열로 API에 전송되었습니다.

Request 탭이 선택된 상태에서 커서를 텍스트 영역에 놓고 헤더 첫 번째 줄의 URL을
/search?q=' or 1=1 --
로 끝나도록 업데이트한 다음 Send 버튼을 선택합니다.

참고: SQL 부울 공격은 true/false 조건을 사용하여 쿼리를 조작하는 유형의 SQL 명령어 삽입입니다. 이 경우, 문자열

' or 1=1 --

은

1=1

조건으로 인해 항상 true를 반환하도록 쿼리를 변경합니다. 이중 하이픈

은 쿼리의 나머지 부분을 주석 처리하여 추가 조건이 적용되지 않게 합니다.

이미지 설명: 위의 이미지는 업데이트된 URL 및 Send 버튼을 보여줍니다.
Response 탭이 열려 처리되지 않은 예외를 표시합니다. 메시지 본문은 아래쪽 패널에 표시됩니다. 패널 하단으로 스크롤하여 다음 메시지를 봅니다.

이미지 설명: 위의 이미지는 HTTP 응답의 처리되지 않은 오류를 보여줍니다.
응답은 정확히 찾고 있던 정보를 제공했으며 적절한 오류 처리의 중요성을 강조합니다. 이제 이 응답을 보고 애플리케이션이 SQLite 데이터베이스를 사용한다는 것을 알았습니다.
참고: 데이터베이스 유형(MySQL, SQLite, Oracle, 등)을 아는 것은 효과적인 SQL 명령어 삽입 페이로드를 만드는 데 중요합니다. 데이터베이스 시스템마다 취약점과 액세스 권한을 얻기 위한 방법이 다릅니다. 정찰은 대상 데이터베이스의 특정 구성에 맞는 명령어 삽입을 개발하는 데 도움이 됩니다.
축하합니다! 성공적으로 정찰을 완료하고 애플리케이션이 SQLite 데이터베이스를 사용하고 있음을 확인했습니다. 또한 애플리케이션이 SQL 명령어 삽입에 취약하다는 것도 알아냈습니다.

과제 3: 지속형 XSS 공격

사이트가 SQLite를 사용하고 SQL 명령어 삽입에 취약하다는 사실을 발견했으므로 이제 크로스 사이트 스크립팅 공격에도 취약한지 알아보겠습니다. 다음 단계에서는 지속형 XSS 공격을 사용하여 등록된 사용자의 목록에 스크립트를 삽입합니다.
참고: 저장형 XSS 공격이라고도 하는 지속형 XSS 공격은 공격자가 웹 애플리케이션의 데이터베이스 또는 기타 영구 스토리지에 악성 스크립트를 삽입하는 경우에 발생합니다. 이렇게 삽입된 코드는 사용자가 영향을 받는 웹 페이지에 액세스할 때 실행되어 브라우저 내에서 악성 스크립트를 실행시킵니다. 공격자는 이 스크립트를 사용하여 민감한 정보를 훔치거나 웹 콘텐츠를 조작하거나 기타 승인되지 않은 작업을 사용자 대신 실행할 수 있습니다.

Manual Request Editor 창을 닫고 검색 창으로 돌아갑니다.
명령: 검색 창에 를 입력하고 ENTER 키를 누릅니다.
api/Users
검색 결과에서 URL이 /api/Users로 끝나는 POST 요청을 선택하고 컨텍스트 메뉴를 열어(마우스 오른쪽 버튼 클릭) Open/Resend with Request Editor를 선택합니다.

요청이 Manual Request Editor에서 열립니다.
참고: 이 요청은 애플리케이션 인터페이스에서 새 사용자를 생성할 때 서버로 전송된 것입니다. Users 엔드포인트로 전송된 POST 요청이며 User-Agent, Content-Type, 쿠키 등 다양한 표준 헤더를 포함합니다. 메시지 본문은 다음과 비슷합니다.

{"email":"myuser@example.com","password":"123456","passwordRepeat":"123456","securityQuestion":{"id":1,"question":"Your eldest siblings middle name?","createdAt":"2023-04-19T15:48:55.057Z","updatedAt":"2023-04-19T15:48:55.057Z"},"securityAnswer":"123456"}

고려 사항: 이 메시지 본문에 포함된 데이터가 모두 새 사용자를 생성하는 데 필요한 것은 아닐 수 있습니다. 새 사용자를 email, password 및 passwordRepeat 키만 사용하여 생성하고 XSS 페이로드를 email 키-값 페어에 삽입해 보겠습니다.

명령: 커서를 메시지 본문 패널 안에 놓고 기존 메시지를 다음 텍스트로 바꿉니다.

{"email":"<iframe src=\"javascript:alert(`xss`)\">","password":"123456","passwordRepeat":"123456"}

다음 목록은 스크립트의 구성 요소를 설명합니다.

iframe: iframe 요소를 생성합니다.
src=: iframe의 소스(src) 속성을 JavaScript 코드 조각으로 설정합니다.
javascript:alert(
xss
): 메시지 ‘xss’가 포함된 경고를 트리거합니다.

Send 버튼을 선택하여 수정된 페이로드로 요청을 재전송합니다.

이미지 설명: 위의 이미지는 페이로드에 XSS 공격을 포함하고 있는 수정된 HTTP 요청을 보여줍니다.
예상 출력:

******************************
**** This is OUTPUT ONLY. ****
******************************

{"status":"success","data":{"username":"","role":"customer","deluxeToken":"","lastLoginIp":"0.0.0.0","profileImage":"/assets/public/images/uploads/default.svg","isActive":true,"id":22,"email":"","updatedAt":"2023-04-19T21:28:08.976Z","createdAt":"2023-04-19T21:28:08.976Z","deletedAt":null}}

훌륭합니다! Response 탭이 열리고 사용자가 생성되었다는 메시지가 표시됩니다. 이제 악성 스크립트가 데이터베이스에 기록되었습니다. 앞으로 다른 사용자가 이 사용자의 프로필을 보면 브라우저에서 스크립트가 실행됩니다.
참고: JSON 응답에는 deluxeToken과 같은 추가 필드와 사용자가 요청에 포함하지 않은 역할이 포함되어 있습니다. 즉, 데이터베이스의 Users 테이블에 웹 사이트 UI에 표시되지 않은 속성이 포함되어 있다는 의미입니다. 이들은 후속 과제에서 유용할 수 있습니다.
축하합니다! 웹 사이트에 대한 XSS 공격을 성공적으로 시작했습니다.

과제 4: 도전 과제 - 로그인 페이지 우회

이 실습의 첫 번째 도전 과제입니다. ZAP, SQL 명령어 삽입 공격 및 Juice Shop 데이터베이스에 대해 학습한 내용을 활용하여 과제를 완료하십시오. 도움이 필요한 경우 Hint 메뉴를 확장하면 추가 정보를 확인할 수 있습니다. 과제를 완료할 수 없는 경우 Solution 메뉴를 확장하고 그 안의 지침에 따라 목표를 달성하십시오. 다음 과제를 진행하기 전에 이 도전 과제부터 완료하십시오.

목표

이 도전 과제의 목표는 Juice Shop 로그인 페이지를 우회하는 것입니다.

도전 과제 하위 과제

https://[JuiceShopDomain].cloudfront.net/#/login으로 이동합니다.
웹 사이트에 인증된 사용자로 로그인할 수 있는 공격을 찾습니다.

힌트 1

힌트 2

힌트 3

해법

축하합니다! 성공적으로 첫 번째 도전 과제를 완료하여 로그인 페이지를 우회했습니다.

과제 5: 도전 과제 - 새 관리 사용자 생성

이 실습의 두 번째 도전 과제입니다. 이전 도전 과제와 마찬가지로 Hint 및 Solution 메뉴를 확장할 수 있습니다. 다음 과제를 진행하기 전에 이 도전 과제부터 완료하십시오.

목표

이 도전 과제의 목표는 사용자 등록 페이지를 악용하여 관리 권한이 있는 새 사용자를 생성하는 것입니다.

도전 과제 하위 과제

ZAP 콘솔을 사용하여 관리 권한이 있는 사용자를 생성할 수 있는 공격을 찾습니다.

힌트 1

힌트 2

해법

축하합니다! 성공적으로 첫 번째 도전 과제를 완료하여 로그인 페이지를 우회했습니다.

과제 6: AWS WAF에서 웹 ACL 생성

애플리케이션이 SQLi 및 XSS 공격에 취약하다는 것을 확인했으므로 이제 애플리케이션을 방어할 차례입니다. 이 과제에서는 AWS WAF에서 웹 액세스 제어 목록(웹 ACL)을 생성합니다. 웹 ACL은 AWS 리소스에 대한 HTTP 및 HTTPS 요청을 모니터링할 수 있게 하는 웹 애플리케이션 방화벽입니다.

화면 오른쪽 상단에서 4개의 화살표가 있는 아이콘 을 선택하여 RDP 세션이 포함된 창을 최소화합니다.
AWS 관리 콘솔 상단의 검색 창에서 를 검색하여 선택합니다.
WAF & Shield
Create web ACL 버튼을 선택합니다.
구성 세부 정보를 입력하기 전에 Resource type에서 CloudFront distributions를 선택합니다.

페이지가 새로 고쳐집니다.

화면 상단의 패널에 다음 구성을 입력합니다.

Name:
JuiceShopACL
Description:
Managed Rule sets and custom rules for JuiceShop
CloudWatch metric name:
JuiceShopACL
Resource type: Amazon CloudFront distributions

화면 하단으로 스크롤하여 Associated AWS resources 패널에서 Add AWS resources를 선택합니다.

Add AWS resources 팝업이 나타납니다.

Cloudfront distribution 옆의 확인란을 선택하고 Add를 선택합니다.
Next 버튼을 선택합니다.

그러면 Add rules and rule groups 페이지로 이동합니다.

Rules 패널에서 Add rules 드롭다운 메뉴를 열고 Add managed rule groups를 선택합니다.

먼저 관리형 규칙 그룹을 웹 ACL에 추가합니다. 관리형 규칙 그룹은 AWS 및 AWS Marketplace 판매자가 작성 및 유지 관리하는 사전 정의되고 즉시 사용할 수 있는 규칙의 모음입니다.

관리형 규칙 그룹 목록의 맨 위에서 AWS managed rule groups 드롭다운 메뉴를 선택합니다.
페이지에서 Core rule set까지 아래로 스크롤하여 그 옆에 있는 Add to web ACL 토글 버튼을 선택합니다.

참고: Core rule set에는 일반적으로 웹 애플리케이션에 적용되는 규칙이 포함되어 있습니다. 이 그룹은 OWASP 간행물에 설명된 취약점을 포함하여 광범위한 취약점의 악용에 대한 보호를 제공합니다.

목록 아래로 내려가서 SQL database 옆에 있는 토글 버튼을 선택합니다.

참고: SQL database 규칙 그룹에는 SQL 명령어 삽입 공격을 포함하여 SQL 데이터베이스 악용과 관련된 요청 패턴을 차단하는 규칙이 포함되어 있습니다.

페이지 하단으로 스크롤하여 Add rules를 선택합니다.

추가한 관리형 규칙 그룹이 화면 상단에 표시됩니다.
참고: 규칙 바로 밑에 있는 패널을 검토하십시오. 현재 ACL은 가능한 5,000개의 웹 ACL 용량 단위(WCU) 중 900개를 사용하고 있습니다. ACL을 적용하려면 WCU 단위로 측정되는 컴퓨팅 용량이 필요합니다. AWS WAF는 각 규칙 유형에 대해 용량을 다르게 계산하여 각 규칙의 상대 비용을 반영합니다. 실행 비용이 거의 없는 단순한 규칙은 더 많은 처리 능력을 사용하는 복잡한 규칙보다 더 적은 WCU를 사용합니다. 예를 들어 크기 제약 조건 규칙 스테이트먼트는 정규식 패턴 집합을 사용하여 요청을 검사하는 스테이트먼트보다 적은 WCU를 사용합니다.

페이지 하단으로 스크롤하여 Next 버튼을 선택합니다.

그러면 Set rule priority 페이지로 이동합니다. 이 페이지에서 규칙이 적용되는 순서를 변경할 수 있습니다.

기본 우선순위를 그대로 두고 Next 버튼을 선택합니다.
지표 설정을 변경하지 말고 페이지 하단으로 스크롤하여 Next 버튼을 선택합니다.
잠시 ACL을 검토한 다음 페이지 하단에서 Cerate web ACL 버튼을 선택합니다.

축하합니다! 성공적으로 첫 번째 웹 ACL을 생성했습니다. 다음 과제에서는 실제로 어떻게 작동하는지 알아봅니다.

과제 7: 웹 ACL 테스트

이 과제에서는 이 실습의 앞부분에서 실행한 공격을 재전송하여 새로 생성한 웹 ACL이 해당 공격을 완화하는지 확인합니다.

이 지침의 왼쪽에 있는 패널에서 PenetrationTestingHost라는 URL을 복사하고 새 브라우저 탭에 붙여넣어 Fleet Manager 세션으로 돌아갑니다.
기존 세션이 종료된 경우 Try again 버튼을 선택하고 앞서 다운로드한 PEM 키를 사용하여 PenetrationTestingHost에 다시 연결합니다.
4개의 화살표가 있는 아이콘 을 선택하여 RDP 세션이 있는 창을 확장합니다.

먼저 ACL이 사용자가 부울 공격으로 검색 창을 악용하는 것을 방지하는지 확인하겠습니다.

ZAP 콘솔을 열고 Search 탭을 선택합니다.
명령: 검색 창에 를 입력하고 Search 버튼을 선택합니다.
products/search
검색 결과에서 URL이 로 끝나는 GET 요청을 찾아 선택합니다. 컨텍스트 메뉴를 열어(마우스 오른쪽 버튼 클릭) Open/Resend with Request Editor를 선택합니다.
/rest/products/search?q=

이미지 설명: 위의 이미지는 ZAP 검색 창의 HTTP 요청 /rest/products/search?q=를 보여줍니다.
Manual Request Editor가 열립니다.

명령:
/rest/products/search?q=' or 1=1 --
요청의 첫째 줄에서 URL의 끝부분을 업데이트한 다음 Send 버튼을 선택합니다.

예상 출력:

******************************
**** This is OUTPUT ONLY. ****
******************************

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: HgKOwHjr5vLod9HGr-JvPt5OCg6nJz4nqGUi-V36_GO3gdJxXBZSVg==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

훌륭합니다! 지금까지 ACL이 예상대로 작동하고 있습니다. 이제 ACL이 공격자가 로그인 페이지를 악용하는 것을 방지하는지 살펴보겠습니다.

Manual Request Editor를 닫습니다.
명령: Searches 탭으로 돌아가 검색 창에 을 입력합니다.
rest/User/login
일치하는 결과를 하나 선택하고, 컨텍스트 메뉴를 열어(마우스 오른쪽 버튼 클릭) Open/Resend with Request Editor를 선택합니다.
명령: Request 탭을 선택하고 페이로드를 다음 텍스트로 바꿉니다.

{"email":"' or 1=1 --","password":"123"}

Send 버튼을 선택합니다.

예상 출력:

******************************
**** This is OUTPUT ONLY. ****
******************************

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: cUx-NuvsiSYbbVZiLxWztDAcDeq4bpP9Vi3YW4_f76lOH2881evgOA==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

이번에도 관리형 규칙 그룹이 Juice Shop 애플리케이션을 성공적으로 방어했습니다. 이제 XSS 공격은 어떻게 처리하는지 살펴보겠습니다.

명령: Search 탭으로 돌아가검색 창에 을 입력합니다.
api/Users
xss@eample.com 사용자를 생성한 POST 요청을 찾습니다. 이 요청을 선택하고 컨텍스트 메뉴를 열어(마우스 오른쪽 버튼 클릭) Open/Resend with Request Editor를 선택합니다.
명령: Request 탭을 선택하고 페이로드를 다음 텍스트로 바꿉니다.

{"email":"<iframe src=\"javascript:alert(`xss`)\">","password":"123456","passwordRepeat":"123456"}

Send 버튼을 선택합니다.

예상 출력:

******************************
**** This is OUTPUT ONLY. ****
******************************

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: YdWwzs5h6YvEelmPmwYxuibdcOVA0CJX7IpgIz60C1nm7WrIKQWQng==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

요청이 성공적으로 차단되었습니다! 지금까지는 좋습니다. 이제 동일한 HTTP 요청을 사용하여 관리 권한이 있는 새 사용자를 생성해 보겠습니다.

Request 탭으로 돌아갑니다.
명령: 페이로드를 다음 텍스트로 바꿉니다.

{"email":"newadmin@example.com","password":"123456","passwordRepeat":"123456","role":"admin"}

Send 버튼을 선택합니다.

예상 출력:

******************************
**** This is OUTPUT ONLY. ****
******************************

{"status":"success","data":{"username":"","deluxeToken":"","lastLoginIp":"0.0.0.0","profileImage":"/assets/public/images/uploads/defaultAdmin.png","isActive":true,"id":24,"email":"newadmin@example.com","role":"admin","updatedAt":"2023-04-18T19:18:02.884Z","createdAt":"2023-04-18T19:18:02.884Z","deletedAt":null}}

문제가 있습니다! “role”:“admin” 의 새 사용자가 생성되었습니다. 이는 놀라운 일이 아닙니다. 메시지 본문에 명백히 악의적인 내용이 포함되지 않았기 때문입니다. API 요청에 “role”:“admin” 과 같은 문자열이 포함될 수 있는 많은 합법적인 상황은 쉽게 생각할 수 있습니다. 그러나 이 특정 사례에서는 이를 심각한 취약성으로 식별했으며 사용자 지정 WAF 규칙을 생성하여 이러한 요청을 차단해야 합니다.
축하합니다! 잘하셨습니다! 일반적인 SQLi 및 XSS 공격을 차단하는 웹 ACL을 생성했습니다. 안타깝게도 Juice Shop 애플리케이션은 발견된 공격 중 하나에 여전히 취약합니다. 다음 과제에서는 이를 해결하기 위해 사용자 지정 규칙을 생성합니다.

과제 8: AWS WAF 규칙 작성기 사용

이전 과제에서 적용한 관리형 규칙 그룹이 대부분의 공격을 차단했지만 한 가지 공격은 차단하지 못했습니다. 이 과제에서는 AWS WAF 규칙 작성기를 사용하여 관리형 규칙 그룹에서 방지하지 못하는 공격을 완화하도록 설계된 사용자 지정 WAF 규칙을 생성합니다.

화면 오른쪽 상단에서 4개의 화살표가 있는 아이콘 을 선택하여 RDP 세션이 포함된 창을 최소화합니다.
AWS 관리 콘솔 상단의 검색 창에서 를 검색하여 선택합니다.
WAF & Shield
JuiceShopACL 링크를 선택합니다.

JuiceShopACL 페이지가 열려 웹 ACL에서 검사한 요청의 차트를 보여줍니다.

Rules 탭을 엽니다.
Add rules 버튼을 선택하고 드롭다운 메뉴에서 Add my own rules and rule groups를 선택합니다.

참고: 사용자 지정 규칙을 사용하면 요청을 처리하기 위한 자체 논리를 구축하고 향상된 유연성 및 제어 기능을 제공할 수 있습니다. 규칙은 헤더, 쿼리 문자열, URI 경로, 본문 등 요청의 여러 측면을 검사할 수 있습니다. 그런 다음 규칙에 지정된 조건에 따라 작업이 요청에 적용됩니다.
다음 단계에서는

api/Users

엔드포인트가 메시지 본문에 “role”:“admin” 이 포함된 요청을 수락하는 것을 금지하는 사용자 지정 규칙을 구성합니다.
보안: 규칙에 포함하는 스테이트먼트를 신중하게 고려하십시오. 너무 광범위한 규칙은 오탐을 초래할 수 있습니다. 반면 세분화된 규칙, 특히 JSON 구문 분석과 관련된 규칙은 현저히 많은 WCU를 사용합니다.

Rule type 패널에서 Rule builder를 선택합니다.
페이지에서 Name 필드까지 아래로 스크롤하여 을 입력합니다.
CustomSQLiRuleForJuiceShop
If a request 드롭다운 메뉴를 열고 matches all the statements (AND) 를 선택합니다.

참고: AND, OR 및 NOT 연산자를 사용하여 여러 스테이트먼트를 연결할 수 있습니다.

Statement 1 패널에서 다음 구성을 입력합니다.

Negate statement results: 확인란을 선택하지 않은 상태로 둡니다.
Inspect: URI path
Match type: Contains string
String to match:
api/Users
Text transformation: None

참고: 이 스테이트먼트는 검색 창이 악용되는 것을 방지합니다. 아포스트로피(')로 시작하는 쿼리 문자열이 포함된 모든 요청을 차단합니다.

Statement 2 패널에서 다음 구성을 입력합니다.

Negate statement results: 확인란을 선택하지 않은 상태로 둡니다.
Inspect: Body
Content type: Plain text
Match type: Contains string
String to match:
"role":"admin"
Text transformation: None
Oversize handling: Continue - Inspect the contents that are within the size limitations according to the rule inspection criteria

Action 패널에서 Block을 선택합니다.

참고: 이 스테이트먼트는 사용자 등록 페이지가 악용되는 것을 방지합니다. URI에

api/Users

문자열이 포함되고 메시지 본문에 “role”:“admin” 이 포함된 모든 요청을 차단합니다. 이 규칙은 Cloudfront를 통과하는 요청에만 적용됩니다. 사이트 관리자는 여전히 Juice Shop 서버에 직접 연결하여 새 관리 사용자를 생성할 수 있습니다.
이제 규칙이 구성되었으므로 규칙이 유효한지 잠시 확인하겠습니다.

페이지 맨 위로 스크롤하여 Name 필드 위에 있는 Validate 버튼을 선택합니다.

규칙이 유효함을 확인하는 배너가 표시됩니다.

페이지 하단에서 Add rule 버튼을 선택합니다.

축하합니다! 사용자 지정 규칙을 성공적으로 생성했습니다. 이제 테스트할 시간입니다.

과제 9: 사용자 지정 규칙 테스트

이 과제에서는 OWASP ZAP 콘솔로 돌아가서 다시 Juice Shop 애플리케이션의 검색 및 사용자 등록 기능을 악용하려고 시도합니다.

이 지침의 왼쪽에 있는 패널에서 PenetrationTestingHost라는 URL을 검색하여 새 브라우저 탭에 붙여넣습니다.
이전 RDP 세션이 종료된 경우 Try again 버튼을 선택하고 PEM 키를 사용하여 PenetrationTestingHost에 다시 연결합니다.
4개의 화살표가 있는 아이콘 을 선택하여 RDP 세션이 있는 창을 확장합니다.
명령: Search 탭으로 돌아가검색 창에 을 입력합니다.
api/Users
일치하는 POST 요청을 하나 선택하고, 컨텍스트 메뉴를 열어(마우스 오른쪽 버튼 클릭) Open/Resend with Request Editor를 선택합니다.
Request 탭을 선택하고 페이로드를 다음 텍스트로 바꿉니다.

{"email":"newadmin2@example.com","password":"123456","passwordRepeat":"123456","role":"admin"}

Send 버튼을 선택하여 악성 페이로드를 다시 전송합니다.

예상 출력:

******************************
**** This is OUTPUT ONLY. ****
******************************

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: BWqQgCAH_8UUbEnDXWl2lwVq6zJ8ejzwBgouZ-79SNepchHkntX-Xw==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

축하합니다! 사용자 지정 규칙이 공격을 차단했습니다. 물론 애플리케이션이 여전히 다른 공격에 취약할 수 있으므로 웹 ACL을 통과하는 트래픽에 대한 추가 정보를 수집할 수 있도록 로깅을 활성화하는 것이 좋습니다. 이러한 로그는 Amazon CloudWatch Logs 로그 그룹, Amazon Simple Storage Service(Amazon S3) 버킷 또는 Amazon Kinesis Data Firehose로 보낼 수 있습니다.

완료

다음 작업을 완료했습니다.

웹 애플리케이션을 손상시키기 위해 간단한 SQLi 및 XSS 공격을 배포
AWS WAF에서 웹 액세스 제어 목록(웹 ACL)을 생성하고 Application Load Balancer와 연결
AWS 관리형 규칙 그룹을 웹 ACL에 적용
사용자 지정 규칙을 웹 ACL에 적용

실습 종료

다음 단계에 따라 콘솔을 닫고 실습을 종료합니다.

AWS Management Console로 돌아갑니다.
페이지 오른쪽 상단에서 AWSLabsUser를 선택하고 Sign out을 선택합니다.
실습 종료를 선택한 다음 실습을 종료할 것임을 확인합니다.

추가 리소스

AWS WAF를 사용하는 방법에 대한 자세한 내용은 AWS WAF 설명서를 참조하십시오.
AWS WAF를 포괄적인 웹 애플리케이션 보안 적용 정책에 통합하는 방법을 알아보려면 AWS WAF용 AWS 관리형 규칙을 사용한 심층 방어(1부) 및 AWS WAF용 AWS 관리형 규칙을 사용한 심층 방어(2부)를 참조하십시오.

RDP를 사용하여 Windows 인스턴스에 연결

현재 읽고 있는 지침의 왼쪽에서 Download PEM을 선택합니다.
파일을 원하는 디렉터리에 저장합니다.
Amazon EC2 콘솔을 엽니다.
탐색 창에서 Instances를 선택합니다. PenTestingHost 인스턴스를 선택한 다음, Connect를 선택합니다.
Connect to instance 페이지에서 RDP client 탭을 선택하고 Get password를 선택합니다.
Browse를 선택하고 앞서 생성한 프라이빗 키(.pem) 파일로 이동합니다. 파일을 선택하고 Open을 선택하여 파일의 전체 내용을 이 창에 복사합니다.
Decrypt Password를 선택합니다. 콘솔의 Password 아래에 이전에 표시된 Get password 링크 대신 인스턴스의 기본 관리자 암호가 표시됩니다. 이 암호를 안전한 곳에 보관합니다. 이 암호는 인스턴스에 연결하는 데 필요합니다.

RDP 클라이언트의 경우 다음 세부 정보를 사용하여 연결합니다.

PenTestingHost IP: EC2 콘솔에서 Public IP를 복사하여 붙여넣습니다.
Username:
Administrator
를 입력합니다.
Password: 앞서 저장한 password를 복사하여 붙여넣습니다.

지침으로 돌아가기

AWS Training and Certification에 대한 자세한 내용은 https://aws.amazon.com/training/을 참조하십시오.
여러분의 피드백을 환영합니다. 피드백, 제안 사항 또는 수정 요청 사항을 제공하려면 AWS Training and Certification 문의 양식에 세부 정보를 입력해 주시기 바랍니다.

728x90

'아마존 클라우드' 카테고리의 다른 글

[아마존] VPC내 Public, Private Subnet 생성하기 (85)	2025.03.28
Amazon VPC 에 Aurora 데이터베이스 계층 생성하기 (59)	2025.03.27
[아마존 클라우드] Amazon VPC에서 Auto Scaling 구성하 (61)	2025.03.26
[AWS] Role Assumption Challenge (32)	2025.03.23
[AWS] Kubenetis Cluster AWS 클라우드에 구축 하기. (102)	2024.02.28

현재글[AWS] WAF 침입 탐지 및 보호

250x250

IT관련 지식과 영어 관련 지식을 공유하는 블로그 입니다.

지식나눔