Post

J'ai ajouté un import de fichiers le week-end. Lundi matin : "Énorme vuln, j'ai téléchargé ton /etc/passwd" Les failles SSRF et XXE expliquées avec de vrais exemples d'exploitation 👇 eventuallycoding.com/2025/11/xxe-...

eventuallycoding.comSécuriser un import de fichiers : corriger les failles SSRF et XXEComment corriger les failles SSRF et XXE sur un import de fichiers ? Cas réel avec exploitation, exemples de code et solutions de sécurisation en Kotlin.

28/11/25, 9:11 am3 reposts6 likes

Mickael J.

@mjeanroy.bsky.social

28 Nov 2025

A noter que ton check est vulnérable a du dns rebinding, dans la pratique c'est pas si simple a exploiter par contre, surtout si le client utilise du cache dns

Mickael J.

@mjeanroy.bsky.social

28 Nov 2025

Pour ça que ce cas de dns rebinding, j'ai toujours tendance un peu a l'ignorer 🤟

Nicolas Helleringer

@nicolas.helleringer.com

28 Nov 2025

Mais il n'y a pas les passwords dans /etc/passwd !!!! ;)

Mickael J.

@mjeanroy.bsky.social

28 Nov 2025

C'est un détail ça, c'était n'importe quel fichier (incluant /etc/shadow ou un fichier dans .ssh), c'est juste pour prouver que c'est un fichier système 🥴

Nicolas Helleringer

@nicolas.helleringer.com

28 Nov 2025

Pardon, il manquait la mention "Attention, second degré !" ;)

Mickael J.

@mjeanroy.bsky.social

28 Nov 2025

Ah ah no worries, y avait pas de reproche. Je me permettais de préciser car j'ai souvent eu cette remarque ^^

Pierre Chapuis

@catwell.info

28 Nov 2025

Une variante un peu plus tricky et pas gérée par les libs par défaut, c'est de passer une URL pas locale mais à laquelle la machine a potentiellement le droit d'accéder, par exemple une API d'administration du Cloud... Et ça marche aussi avec les webhooks si c'est du POST.