5.4 KiB
SOME - Same Origin Method Execution
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Same Origin Method Execution
Ci saranno occasioni in cui puoi eseguire un po' di javascript limitato in una pagina. Ad esempio, nel caso in cui puoi controllare un valore di callback che verrà eseguito.
In questi casi, una delle migliori cose che puoi fare è accedere al DOM per chiamare qualsiasi azione sensibile tu possa trovare lì (come cliccare un pulsante). Tuttavia, di solito troverai questa vulnerabilità in piccoli endpoint senza nulla di interessante nel DOM.
In questi scenari, questo attacco sarà molto utile, perché il suo obiettivo è essere in grado di abusare dell'esecuzione limitata di JS all'interno di un DOM da una pagina diversa dello stesso dominio con azioni molto più interessanti.
Fondamentalmente, il flusso dell'attacco è il seguente:
- Trova un callback che puoi abusare (potenzialmente limitato a [\w\._]).
- Se non è limitato e puoi eseguire qualsiasi JS, potresti semplicemente abusare di questo come un normale XSS.
- Fai in modo che la vittima apra una pagina controllata dall'attaccante.
- La pagina si aprirà da sola in una finestra diversa (la nuova finestra avrà l'oggetto
opener
che fa riferimento a quella iniziale). - La pagina iniziale caricherà la pagina dove si trova il DOM interessante.
- La seconda pagina caricherà la pagina vulnerabile abusando del callback e utilizzando l'oggetto
opener
per accedere ed eseguire qualche azione nella pagina iniziale (che ora contiene il DOM interessante).
{% hint style="danger" %}
Nota che anche se la pagina iniziale accede a un nuovo URL dopo aver creato la seconda pagina, l'oggetto opener
della seconda pagina è ancora un riferimento valido alla prima pagina nel nuovo DOM.
Inoltre, affinché la seconda pagina possa utilizzare l'oggetto opener, entrambe le pagine devono essere nella stessa origine. Questo è il motivo per cui, per abusare di questa vulnerabilità, devi trovare qualche tipo di XSS nella stessa origine. {% endhint %}
Exploitation
- Puoi usare questo modulo per generare un PoC per sfruttare questo tipo di vulnerabilità: https://www.someattack.com/Playground/SOMEGenerator
- Per trovare un percorso DOM a un elemento HTML con un clic puoi usare questa estensione del browser: https://www.someattack.com/Playground/targeting_tool
Example
- Puoi trovare un esempio vulnerabile in https://www.someattack.com/Playground/
- Nota che in questo esempio il server sta generando codice javascript e aggiungendolo all'HTML in base al contenuto del parametro callback:
<script>opener.{callbacl_content}</script>
. Ecco perché in questo esempio non è necessario indicare esplicitamente l'uso diopener
. - Controlla anche questo writeup CTF: https://ctftime.org/writeup/36068
References
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.