drupal8 프레임워크에 대한 심층 분석 및 취약점의 동적 디버깅을 수행하는 방법
- WBOY앞으로
- 2023-05-12 17:19:061262검색
머리말
drupal 프레임워크에서 가장 고전적이고 우리에게 가장 가까운 것은 2018년 CVE-2018-7600 취약점입니다. 그런데 이번 취약점 분석 글을 읽고 연구하는 과정에서 모두 이 취약점에 대한 상세한 분석임을 알게 되었습니다. 이 프레임워크의 실행 프로세스에 익숙하지 않은 사람들은 이 프레임워크를 읽고 나면 이해하기 어려울 수 있습니다.
다음은 주로 두 부분으로 나뉩니다.
첫 번째 부분은 drupal 프레임워크 프로세스에 대한 소개이며(여기서는 주로 8.x 시리즈에 대해) 심포니 오픈 소스 프레임워크를 기반으로 하는 drupal 프레임워크가 어떻게 작동하는지 알려줍니다. 리스너 패턴을 사용합니다. 전체 복잡한 처리 프로세스를 지원하고 프레임워크가 요청을 처리하는 방법에 대한 기본적인 이해를 제공합니다.
두 번째 부분은 취약점 트리거의 시작점에서 먼저 일반 데이터 패킷을 동적으로 디버깅하여 드루팔의 처리 흐름을 이해하는 프레임워크를 기반으로 취약점 CVE-2018-7600의 실행 프로세스에 대한 자세한 해석입니다. 프레임워크를 사용하여 일반 패킷을 사용하여 POC 패키지의 제어 가능한 변수가 구성됩니다. 시작과 끝을 이해할 수 있을 뿐만 아니라 중간 과정도 투명하게 만들 수 있습니다. 평행선을 그릴 수 있습니다.
1. 배경 소개
Drupal은 PHP 언어로 작성된 오픈 소스 CMF(콘텐츠 관리 시스템)와 PHP 개발 프레임워크(Framework)로 구성됩니다. 수년 연속 세계 최고의 CMS 상을 수상했으며 PHP 언어를 기반으로 한 가장 유명한 WEB 애플리케이션입니다.
Drupal 아키텍처는 코어, 모듈, 테마의 세 부분으로 구성됩니다. 세 개는 Hook 메커니즘을 통해 긴밀하게 연결됩니다. 그 중 핵심부분은 세계적으로 유명한 WEB 개발 전문가들로 구성된 팀이 개발하고 유지관리하고 있습니다.
Drupal은 강력하고 자유롭게 구성 가능한 기능을 통합하고 개인 블로그(PersonalWeblog)부터 대규모 커뮤니티 중심 웹사이트(Community-Driven)에 이르기까지 다양한 애플리케이션으로 웹사이트 프로젝트를 지원할 수 있습니다. Drupal은 원래 DriesBuytaert가 개발한 커뮤니티 토론 소프트웨어 세트였습니다. 이후 유연한 아키텍처, 편리한 확장 및 기타 기능으로 인해 전 세계 수천 명의 프로그래머가 Drupal의 개발 및 적용에 참여했습니다. 오늘날 이는 강력한 시스템으로 발전했으며 많은 대규모 조직에서 Drupal 기반 프레임워크를 사용하여 The Onion, Ai't ItCool News, SpreadFirefox, Ourmedia, KernelTrap, NewsBusters 등을 포함한 웹 사이트를 구축하고 있습니다. 특히 커뮤니티 주도 웹사이트에서 흔히 발생합니다.
2. 준비
2.1 소스코드 다운로드
먼저 공식 홈페이지 다운로드 페이지 https://www.drupal.org/download 또는 https://www.drupal.org를 통해 최신 버전을 직접 다운로드 받으실 수 있습니다. /project/drupal /releases/xxx xxx는 해당 버전의 소스 코드 파일을 다운로드하기 위해 다운로드하려는 버전 번호를 나타냅니다. PHP 패키지 관리 도구 작성기를 사용하여 다운로드할 수도 있습니다.
2.2 drupal 설치
설치 환경: WIN7 32비트
통합 환경: PHPSTUDY
디버깅 환경: PHPSTORM
설치 중 발생할 수 있는 문제 및 해결 방법:
1. PHP 버전 문제: PH는 P7이 가장 좋습니다. 위
2. 날짜 시간 문제
해결책:
php.ini 설정
3. 설치 경고
이 두 가지 문제(경고)는 해결할 수 없습니다.
문제 1에 대한 해결책: PHP 버전을 7.1 이상으로 업그레이드하세요.
문제 2에 대한 해결책:
php.ini에서 [opcache]를 찾아 여기에 다음 콘텐츠를 추가하세요.
zend_extension="C:xxxxxxphpphp-7.0.12-ntsextphp_opcache.dll"
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
4. drupal이 일부 요청을 너무 느리게 처리하기 때문에 시간 초과 예외가 발생할 수 있습니다. Php.ini에서 max_execution_time 옵션을 더 큰 값으로 설정하세요.
3. 프레임워크 간략 분석
3.1 디렉터리 구조
다음은 drupal 8.5.7 소스 코드의 압축을 푼 후 디렉터리입니다.
/core drupal의 핵심 폴더, 지침을 참조하세요. 자세한 내용은 아래
/modules. 사용자 정의 또는 다운로드한 모듈
/profiles는 다운로드하고 설치된 사용자 정의 구성 파일을 저장합니다
/sites 폴더는 drupal 7 이하 버전에서 주로 사이트 및 기타 사이트 파일에서 사용하는 테마와 모듈을 저장합니다.
/themses는 사용자 정의되거나 다운로드된 테마를 저장합니다.
/vendor는 코드 종속성 라이브러리를 저장합니다.
다음으로 코어 폴더 core
/core/assets 아래의 디렉터리 구조를 살펴보겠습니다. - drupal에서 사용되는 다양한 확장 라이브러리 jquery, ckeditor, backbone, NormalizeCSS 등
/core/config - drupal의 핵심 구성 파일
/core/includes - 모듈식 시스템 자체와 같은 모듈식 기본 기능 기능
/core/lib – drupal
/core/misc에서 제공하는 원본 코어 클래스 - JS, CSS, 이미지 등과 같이 코어에 필요한 프런트엔드 기타 파일입니다.
/core/modules – 핵심 모듈, 약 80개 항목
/core/profiles – 내장 설치 구성 파일
/core/scripts – 개발자가 사용하는 다양한 히트 스크립트
/tests – 테스트에 사용 파일
/core/themes – 커널 테마
3.2 프레임워크 실행 로직
Drupal은 Symfony 오픈 소스 프레임워크를 기반으로 구축되었습니다. Symfony 공식 웹사이트에서 sysmfony는 모든 변환에 사용할 수 있는 재사용 가능한 PHP 구성 요소 세트라는 것을 알 수 있습니다. 구성요소는 자체 애플리케이션에서 독립적으로 사용됩니다. 각 구성요소는 심포니 공식 웹사이트에 독립적인 문서를 가지고 있습니다. 이러한 구성요소 중 일부는 drupal에서 직접 사용되며 일부는 drupal 고유의 특성에 따라 수정됩니다.
먼저 Symfony의 실행 과정을 살펴보겠습니다
Drupal과 Symfony도 디자인에 있어서 동일한 개념을 사용합니다. 둘 다 웹사이트 시스템이 실제로 요청을 응답으로 변환하는 시스템이라고 믿습니다.
drupal의 라우팅 시스템에서는 다양한 구성 요소 간의 관계를 볼 수 있습니다.
이를 기반으로 drupal은 심포니 처리 프로세스를 개선하여 현재의 거대한 drupal 처리 응답 프로세스를 형성했습니다.
이미지 링크 주소는 https://www.drupal.org/docs/8/api/render-api/the-drupal-8-render-pipeline 입니다. 필요한 경우 고화질 버전을 직접 다운로드 받으실 수 있습니다.
3.3 항목 파일을 보면
항목 파일은 코드가 6줄로 매우 간결하지만, drupal의 핵심 시스템이 너무 크기 때문에 전체를 실행합니다. 모든 것을 분석하는 것은 불가능하므로 항목부터 시작하겠습니다. 파일을 한 줄씩 살펴보고 실행 중인 프로세스를 분석합니다.
첫째, $autoloader =require_once 'autoload.php'; 표면적으로는 autoload.php 파일만 포함합니다. 실제로 drupal은 PHP 자동 로딩 메커니즘을 사용하여 자동 로더를 생성합니다.
코드 관점에서 프로세스를 간략하게 살펴보겠습니다. 기본 프로세스는 Vendor/autoload.php에서 getLoader 함수를 호출하는 것입니다.
그런 다음 함수를 입력하여 그 기능을 확인합니다.
ClassLoader 개체는 내부에 정의된 기본 대응을 사용하여 함수 및 클래스 정의 파일을 찾습니다.
함수는 마침내 인스턴스화 로더를 반환합니다. 이제 첫 번째 단계가 완료되었습니다. Drupal은 더 이상 많은 파일을 수동으로 포함할 필요가 없으므로 많은 작업이 절약됩니다.
그런 다음 $kernel =new DrupalKernel('prod', $autoloader); drupal은 다가오는 요청 객체 처리를 준비하기 위해 새로운 drupal 커널 객체를 생성합니다.
다음 코드 줄은 항목 파일의 $request= Request::createFromGlobals()입니다. 객체 지향 시스템의 경우 $_POST, $_GET, $_COOKIE 등과 같은 전역 변수를 직접 사용해서는 안 됩니다. Drupal은 이 모든 것을 $request 객체에 캡슐화합니다. 이는 간단하고 편리할 뿐만 아니라 요청한 개체를 사용하여 몇 가지 추가 기능과 사용자 정의 속성을 직접 추가할 수도 있습니다.
마지막으로 해당 전역 변수가 요청 개체에 추가되고 캡슐화된 요청 개체가 반환됩니다.
위 작업이 단지 예비 단계인 경우 $response = $kernel->handle($request); 코드의 다음 줄이 요점에 도달하기 시작하고 drupal 커널 개체 커널이 요청을 처리합니다. 요구.
Drupal 프로세싱의 핵심은 디자인 패턴 중 리스너 패턴입니다. 여기에는 다양한 이벤트와 이벤트 수준이 포함된 이벤트 소스가 포함되어 있습니다. 다른 부분은 이벤트를 실행하는 데 필요한 프로그램이나 함수로, 이를 리스너라고 부릅니다. 요청 처리 과정에서 노드에 도달할 때마다 해당 이벤트가 전달되고 리스너는 획득한 이벤트 개체 및 수준을 기반으로 해당 작업을 수행합니다.
시스템의 핵심 이벤트는 8개의 코어가 포함된 kernelevents.php에 있는 Symfony 프레임워크의 이벤트를 계속 사용합니다.
Const REQUEST = 'kernel.request' 프레임워크 코드에서 코드를 실행하기 전에 , 요청 발송 시작이 트리거됩니다.
Const EXCEPTION = 'kernel.Exception' 포착되지 않은 예외가 발생할 때 트리거되는 이벤트입니다.
Const VIEW = 'kernel.view' 컨트롤러의 반환 값이 응답 인스턴스가 아닐 때 트리거됩니다. 이때 컨트롤러는 추가 렌더링 작업을 위해 렌더링 배열을 반환합니다.
Const CONTOLLER = 요청 요청을 파싱하여 해당 컨트롤러를 찾으면 'kernel.controller'가 트리거되며 이 컨트롤러를 수정할 수 있습니다.
Const CONTROLLER_ARGUMENTS = 'kernel.controller_arguments' 컨트롤러의 매개변수를 파싱할 때 트리거되며 매개변수를 변경할 수 있습니다.
Const RESPONSE = 'kernel.response' 응답 응답 요청 생성 시 트리거되며 응답할 응답을 수정하거나 대체할 수 있습니다.
Const TERMINATE = 응답이 전송되면 'kernel.terminate'가 트리거됩니다. 이 이벤트를 사용하면 무거운 사후 응답 작업을 처리할 수 있습니다.
Const FINISH_REQUEST = 'kernel.finish_request' 요청 요청이 완료되면 트리거됩니다. 요청 중에 애플리케이션이 변경되면 애플리케이션의 전역 및 환경 상태를 재설정할 수 있습니다.
이러한 핵심 이벤트 외에도 drupal의 각 리스너는 자체 이벤트를 전달합니다. 이러한 파일의 위치는 corelibDrupalCore 디렉터리 아래의 해당 폴더에 있습니다. 모두 events.php로 끝나고 해당 정적 이벤트 변수가 파일에 정의되어 있습니다.
drupal 코어 요청 프로세스를 살펴보겠습니다.
요청 시작------요청을 구문 분석하여 컨트롤러를 가져오고 수정합니다------》컨트롤러 매개변수 구문 분석------》호출 컨트롤러 방법에 따라 -----》컨트롤러의 반환 상황을 관찰합니다. 응답 개체 응답을 반환하거나 렌더링을 계속합니다. ------》응답을 보냅니다. 전체 프로세스 도중에 예외가 발생하면 예외 이벤트가 직접 발생하여 예외가 배포됩니다. 전체 프로세스에서 요청 객체는 핵심 요청 이벤트에 응답하는 것 외에도 실제 상황에 따라 다른 공통 모듈 이벤트에 응답하는 분기에도 들어갑니다. 그러나 프로세스가 아무리 울퉁불퉁하더라도 결국에는 원래의 상태로 돌아갑니다. 기본 프로세스를 실행하고 응답 개체 응답을 반환합니다.
다음으로 소스 코드에서 위의 특정 동작을 관찰합니다.
계속해서 index.php에서 후속 작업을 수행하고 drupalkernel.php 파일을 입력하면 어떤 작업이 수행되었는지 살펴보겠습니다.
다음 단계는 일련의 핸들러 함수 호출 체인입니다. 핸들 함수를 계속 따라갈 수 있으므로 핵심 함수인 handlerraw를 직접 따를 수 있습니다. 곧 filterResponse 함수가 반환됩니다.
여기의 응답 개체는 계층별로 반환되지만(모든 응답 결과가 이 프로세스를 거치는 것은 아니라는 점에 유의해야 함) 결국에는 응답 개체로 캡슐화되어 index.php로 반환됩니다. 파일을 $response 변수에 넣습니다. 그런 다음 $response->send()를 호출하여 캡슐화된 응답 객체를 보냅니다.
때때로 우리가 보내는 요청 작업의 내용이 너무 번거로울 수 있으므로 위의 호출이 끝나면 Drupal 커널이 종료되기 전에 최종 처리를 수행합니다. 프로세스는 Index.php 파일의 마지막 줄에 들어가서 $kernel->terminate($request,$response)를 호출합니다. 호출 체인에 따라 stackedhttpkernel.php 파일을 따릅니다
이 시점에서 전체 사이클이 종료되었습니다.
위 프로세스에서 가장 일반적인 작업은 이벤트 전달이라는 것을 알았습니다. 실제로 모든 전달 프로세스는 ContainerAwareEventDispatcher.php 파일에 있습니다. 예를 들어보겠습니다.
시스템에는 총 19개의 리스너가 있으며 각 리스너는 수신되는 이벤트 이름을 기준으로 해당 리스너를 일치시킨 다음 하나씩 탐색하고 호출합니다. 서비스 이름에 해당하는 기능 기능입니다. 여기에 있는 것은 kernel.request 이벤트이고 호출 방법은 콜백 호출입니다.
4. CVE-2018-7600을 다시 살펴보세요
세 번째 부분의 간단한 프레임워크 분석을 통해 프로세스에 대한 모호한 개념만 가질 수 있습니다. 다음으로, 보다 고전적인 취약점을 대상으로 예제를 결합하겠습니다. drupal 프레임워크 취약점 cve-2018-7600을 사용하여 프레임워크에서 이 취약점의 자세한 작동 프로세스를 주의 깊게 관찰하세요. 여기서 사용하는 취약점 트리거 환경 버전은 8.5.0입니다. 이 버전의 취약점 트리거는 더 직관적이므로 별도로 명시하지 않는 한 후속 분석에 사용되는 코드 버전은 이 버전입니다.
4.1 패치 비교
이 취약점은 버전 8.5.1에서 수정되었으며, 5.0과 5.1 사이에는 하위 버전이 하나만 있기 때문에 소스 코드의 차이점을 보다 명확하게 비교할 수 있습니다. 공식이 이 취약점을 어떻게 수정했는지 살펴보겠습니다. 버전 8.5.1의 소스 코드에는 요청 부분을 필터링하는 새로운 RequestSanitizer.php 파일이 추가되었습니다. 에 있는 모든 키 이름의 값을 화이트리스트에 추가합니다.
prehandle 메소드에서는 위 파일에 추가된 새로운 메소드가 필터링을 위해 호출됩니다. 아래 그림의 오른쪽 빨간색 부분이 8.5.1에서 추가된 필터링 코드입니다.
여기서 필터링 코드의 호출 위치는 드루팔 커널이 요청을 처리하기 전입니다. 이렇게 하면 취약점이 완전히 해결됩니다.
그런 다음 공식 문서를 확인하기 위해 drupal 공식 웹 사이트에 가서 drupal render api에 #의 시작 부분에 대한 특수 처리가 있음을 발견했습니다. 주요 문서 링크는 다음과 같습니다
https://www.drupal .org/docs/8/api/render -api/render-arrays를 방문하여 체크포인트 보안 팀에 따르면 이 취약점과 관련된 기술적 세부 정보가 포함된 보고서를 공개했습니다. 링크는 다음과 같습니다: https://research.checkpoint.com/uncovering-drupalgeddon-2/. 취약점 유발 원인은 8.5.0 버전의 등록된 사용자 기능 중 아바타 업로드 기능인 것으로 확인되었습니다.
4.2 프레임워크에서 데이터 패킷의 실행 프로세스
이제 취약점의 원인을 알았으므로 먼저 사진을 업로드하고 정상적인 초기 패키지를 가져와서 상황을 확인합니다.
그런 다음 항목 파일 index.php에서 createfromglobals 함수를 패키징한 후 drupal은 우리가 요청 객체에 전달한 모든 매개변수를 캡슐화합니다.
4.2.1KernelEvents::REQUEST 이벤트 전달
위에서 프레임워크 프로세스가 소개되었으므로 다음은 요청을 처리하는 drupal 커널 단계입니다. 여기서는 handlerRaw에 중단점을 직접 설정하고 첫 번째 KernelEvents를 입력합니다. ::REQUEST는 이벤트를 전달하여 리스너가 이 요청에 대해 수행한 작업을 확인합니다.
먼저 drupal은 Option 요청을 처리하려고 시도하지만 안타깝게도 우리의 요청은 POST 요청이므로 처리하지 않고 직접 보냅니다.
그런 다음 URL 경로의 슬래시 문제를 처리하고 여러 슬래시로 시작하는 경로를 단일 슬래시로 변환합니다.
그런 다음 요청에 따라 신원을 확인합니다. 여기서는 수행하지 않은 작업입니다. 관광객으로 로그인하므로 여기서는 특별한 대우가 없습니다.
다음으로 $_GET['destination'] 및 $_REQUEST ['destination']을 포함하는 대상 매개변수가 정리되어 리디렉션 공격을 방지합니다.
그런 다음 POST 요청의 _drupal_ajax 매개변수를 기반으로 요청이 AJAX 요청인지 판단하고 관련 속성이 설정됩니다.
다음 단계는 요청의 URL 부분에 따라 해당 경로를 일치시키는 것입니다. 여기서 drupal은 먼저 경로 캐시에서 해당 일치 항목을 검색하고 그렇지 않은 경우 모든 라우팅 테이블 조회 작업을 수행합니다. (코드 양이 많기 때문에 여기에서는 코드 전체를 가로채지 않고 일부만 가로채겠습니다.) 처리 기능은 onKernelRequest에 있습니다. 동시에 user.routing에서도 관련 정보를 찾을 수 있습니다. yml 파일.
경로를 찾았습니다. 다음 단계는 해당 경로가 사용 가능한지 확인하는 것입니다.
다음 단계는 사이트가 유지 관리 모드인지 확인하고, 유지 관리 모드인 경우 로그아웃합니다. 계정을 확인하고, 사이트가 오프라인인지 확인하고, 동적 페이지 캐시를 확인하고, 비라우팅 설정을 전처리하고, 매개변수에 따라 복제 서버를 비활성화할지 여부를 확인합니다. 이러한 작업과 관련된 기능은 아래 스크린샷입니다.
이 시점에서 위의 작업은 주로 무시할 수 있는 몇 가지 추가 조치를 취한다는 것을 알 수 있습니다. 또한 여기에서 몇 가지 중요한 정보를 추출하고 요청 개체를 통해 관련 라우팅 정보를 일치시켰습니다.
4.2.2KernelEvents::ControlLER 및 KernelEvents::ControlLER_ARGUMENTS 이벤트
다음으로, handlerraw 함수에서 drupal은 방금 일치하는 라우팅 정보를 통해 실제 요청 컨트롤러와 해당 매개변수를 찾습니다.
먼저 KernelEvents::ControlLER의 리스너가 어떤 작업을 수행하는지 살펴보겠습니다. ㅋㅋㅋ $event 개체를 입력하세요.
KernelEvents::ControlLER_ARGUMENTS에는 자체 리스너가 없기 때문에 여기서 디스패치가 직접 해제됩니다.
4.2.3 컨트롤러 호출
요청 관련 이벤트 디스패치를 handlerRaw에서 처리하고 요청에서 해당 컨트롤러를 찾은 후, 컨트롤러를 기반으로 해당 처리 기능을 찾는 차례입니다. 아래 call_user_function의 컨트롤러는 위 그림의 클로저 콜백 함수로 대체되었습니다. 여기서 컨트롤러를 호출하는 것은 위 그림의 클로저 함수를 직접 입력하는 것과 같습니다.
drupal에서는 각 컨트롤러를 처리하는 동안 렌더링이 필요한 곳이 있으면 렌더링 작업이 직접 수행되도록 렌더링 컨텍스트에 컨트롤러가 추가됩니다.
컨트롤러가 실제 호출 메서드인 getContenResult를 입력하면 공식적으로 폼 구성이 시작됩니다.
4.2.4 Form 생성
buildForm 함수에 들어가면 먼저 POST 정보를 얻어서 form_state에 저장하게 됩니다.
buildForm 함수의retrieveForm 함수에서 양식 양식이 처음으로 조립되기 시작합니다. 렌더링해야 할 요소가 있으면 대부분의 Drupal에서는 Drupal::service('renderer')->를 직접 사용합니다. 렌더링을 위한 ;renderPlain(); 서비스는 요소에 대한 렌더링 작업을 수행하며 최종 렌더링 기능의 주요 작업은 doRender 함수에 있습니다.
요청에 따라 양식 양식이 조립되면 양식 요청이 즉시 처리됩니다. 여기서는 processForm 함수가 이 작업을 수행합니다. 이미지 업로드 작업에서도 이 동작이 처리되며, 처리가 완료된 후 이미지가 이동됩니다. 그런 다음 각 요소와 토큰을 확인하고 검증한 후 최종적으로 결과를 바탕으로 전체 Form을 다시 빌드합니다.
processForm에서 이미지 처리 과정을 추적하고 싶다면 아래 함수에 직접 중단점을 설정하고 스택 추적을 기반으로 관심 있는 작업을 찾을 수 있습니다.
processForm 함수를 실행한 후, Rebuild 후 FORM 폼의 일부 스크린샷입니다.
이 시점에서 전체 폼 처리 작업이 완료되었습니다.
4.2.5 비정상적인 분포.
이전 단계에서 양식 작업을 완료한 후 요청 개체가 자신도 모르게 응답 개체로 변환되었습니다. 레이어별로 반환해서 전송 작업을 수행하려 했으나, 다음 프로세스에서 drupal이 이것이 Ajax 요청임을 발견하고 사전에 작업을 가로채고 AJAX 예외를 발생시켜 해당 요청에 대한 추가 처리를 수행했습니다.
예외를 catch한 후 예외를 처리하고 해당 예외에 대한 디스패치 작업을 수행합니다.
여기서의 디스패치는 실제로 예외를 순회하고 일치시키는 과정입니다. 예외가 발생하는 경우에는 올바른 예외를 일치시킨 후 특정 처리를 수행합니다. 일치하는 항목이 없으면 그냥 놔두세요. 여기서는 AJAX 예외를 일치시켰습니다. 다른 예외 처리 프로세스에 대해 더 관심이 있는 경우 kernel.Exception 배열에서 찾아보세요.
추가 조사 결과 onException의 buildResponse 함수에 AJAX를 처리하는 특정 방법이 있음을 발견했습니다.
uploadAjaxCallback 함수에서는 데이터 패킷의 URL에서 element_parents 매개변수의 값을 가져와서 이를 키로 사용하여 최종 처리한 FORM 폼에서 결과를 가져온 다음 그 결과를 렌더링하여 HTML 페이지.
POST 패키지의 URL 매개변수를 기반으로 FORM 형식의 user_picture 아래 위젯 배열에서 첫 번째 항목을 꺼냅니다.
doRender에서 렌더링할 최종 객체는 방금 꺼낸 요소입니다.
렌더링이 끝나면 전체 처리 과정이 끝나고 응답이 레이어별로 구성되어 반환되기 시작합니다.
4.2.6 kernel.response 이벤트
이제 응답을 트리거해야 합니다. 다음으로 응답 디스패치에서 리스너가 무엇인지 살펴보겠습니다. 기본적으로 응답 개체에 벽돌과 타일을 추가하고 해당 확장 작업을 수행하는 것입니다. 예를 들어 동적 페이지를 캐시해야 하는지, 캐시 컨텍스트를 추가해야 하는지, 자리 표시자를 처리해야 하는지, 성공적인 응답에 추가 헤더를 설정해야 하는지 등을 결정합니다. 위의 모든 작업은 리스너 아래의 kernel.response 배열에 있으므로 여기서는 자세히 소개하지 않습니다.
4.2.7 kernel.finish_request
요청 및 응답 작업이 완료되면 drupal 커널에 모든 것이 완료되었다는 메시지가 전달되고 Finish_request 이벤트가 전송됩니다. 이 이벤트에 대한 리스너는 하나만 있습니다. URL 생성기가 올바른 컨텍스트에서 실행되도록 하려면 현재 요청을 상위 요청으로 설정해야 합니다. 
4.2.8 kernel.terminate 이벤트
위 작업이 완료되면 요청 요청이 요청 스택에서 팝되고 응답 전송을 위해 계층별로 기본 Index.php 항목 페이지로 반환됩니다. 마지막으로 작업을 정리하고, kernel.terminate 이벤트를 트리거하고, 관련 변경 사항을 파일에 기록해야 하는지 여부를 결정합니다. 결국 드루팔 커널은 종료됩니다. 모든 과정이 끝났습니다. 
Part 4의 프레임워크에서 실행되는 일반 업로드 패키지 프로세스에 대한 분석을 기반으로 우리는 우리가 구성한 콘텐츠가 doRender의 취약점을 성공적으로 트리거하기를 원한다는 것을 알고 있습니다. 먼저 프로세스를 제어하고 AJAX 콜백 부분에 들어가도록 해야 합니다. 아래 if 판단에서 $ajax_form_request, $form_state->isProcessingInput() 및 $request->request->get('form_id')== $ 세 가지 조건이 동시에 충족되어야 함을 알 수 있습니다. form_id. 아래 그림에서 볼 수 있듯이 $ajax_form_request의 값은 ajax_form 변수에 의해 제어되며 form_id는 폼의 ID입니다.
다음으로, URL의 element_parents 매개변수 값을 사용하여 양식 배열의 값을 가져옵니다. 이는 4부의 섹션 4.2.5에 설명되어 있으며 여기서는 반복하지 않습니다. 마지막으로 해당 변수를 구성하고 doRender 함수에서 call_user_func_array를 사용하여 취약점을 트리거합니다.
위의 설명을 바탕으로 메일 매개변수를 사용하여 다음 POC 패키지를 구성했습니다.
위에서 언급한 메일 매개변수를 제어할 수 있을 뿐만 아니라 분석 과정에서 form_build_id 매개변수도 발견되었습니다. 또 다른 POC는 다음과 같습니다.
위 내용은 drupal8 프레임워크에 대한 심층 분석 및 취약점의 동적 디버깅을 수행하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!