# SSRF ## SSRF stockée dans l'url de source des images de profiles menant à la fuites d'informations des utilisateurs ### Description L'application était une plate-forme d'apprentissage en ligne qui permettait à tous les utilisateurs de s'inscrire à des cours en ligne sur différents sujets. Tous les utilisateurs avaient la possibilité de télécharger leur propre image de profile qui était ensuite chargée à partir d'un domaine de stockage hébergé en externe. Lors de la modification du profil, l'URL complète où l'image est stockée est envoyée dans un paramètre nommé "user\_profile\[user]". Après avoir testé sans succès les vulnérabilités liées à la fonctionnalité de téléchargement, j'ai décidé de me concentrer sur cette URL. ### Exploitation * J'ai d'abord essayé de remplacer le domaine d'origine avec mon propre domaine mais les changements n'étaient pas pris en compte lorsque je validais la requête. * J'ai alors ensuite essayé de contourner la regex de validation d'url utilisée en ajoutant un ".attacker.xyz" puis un "@attacker.xyz" à la suite du domaine d'origine ce qui à ma grande surprise a fonctionné me permettant ainsi de remplacer la source de l'image à charger par une source provenant de mon propre serveur.

* Cela me permettant de faire en sorte que les utilisateurs de l'application charge l'image de mon serveur à chaque fois que mon image de profile était chargé dans la page qu'ils ouvraient.

### Risques Fuites d'informations techniques des utilisateurs de l'application (IP, User-Agent) ## SSRF dans une page d'erreur menant à des fuites d'informations techniques des appareils et navigateurs des victimes ### Description Le site web vulnérable proposait un espace personnel sur son sous domaine . Lorsqu'une erreur survenait sur le site, une redirection était effectué vers l'url avec comme paramètres GET "message", "url" et "label". Le paramètre "message" était reflété dans la page en tant que message d'erreur. Après avoir tenté d'exploiter ce vecteur en cherchant à executer des injections HTML/XSS/SSTI sans succès, ce suis passé au paramètre suivant. Le paramètre label avait pour seule utilité de contenir le type d'erreur rencontré, cependant le paramètre url contenait une url compléte vers une image svg présente sur le domaine principal de l'organisation. (https:%2F%2Fwww\.redacted.fr%2Fdesign%2F3.9.0%2Fneva%2Fassets%2F) Dans le code source de la page, cette url était reflété avec à la suite le path vers l'image en accord avec l'erreur (/img/unavailable.svg) ### Exploitation * J'ai d'abord tenté de simplement remplacer le domaine [www.redacted.fr](http://www.redacted.fr) par mon domaine attaquant mais celui-ci fût remplacé par le domaine d'origine dans la réponse. * J'ai alors ensuite simplement tenté de garder le domaine d'origine en y ajoutant un simple "@" suivi de mon propore domaine et le serveur a accepté l'url en l'état (https:%2F%<2Fwww.redacted.fr@attacker.xyz>%2Fdesign%2F3.9.0%2Fneva%2Fassets%2F) * Et lors du chargement de l'image dans le code source, celle-ci à bien été cherché à l'endroit voulu comme le montre les logs.

Fuites d'informations techniques sur les victimes

### Risques Fuites d'informations techniques des utilisateurs de l'application (IP, User-Agent) mais nécessité de phishing pour l'exploiter. ## Récompenses ![](/files/C2jxBAU6MioMuDl0gyY6) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://bugbounty.s1rn3tz.ovh/ssrf.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.