# Niveau "Low" Le challenge en niveau "Low" invite à saisir une URL afin d'exécuter un script externe : ![](/files/-LuDXNJ4CWxxz_JBCcBU) Etant donné que le challenge porte sur CSP, j'analyse la politique en place : ![](/files/-LuDXc34gZge173YaqZT) ``` Content-Security-Policy: script-src 'self' https://pastebin.com example.com code.jquery.com https://ssl.google-analytics.com ``` Ce qui donne pour la directive `script-src` : * `'self'` : Autorise l'exécution de ressources fournies par la même origine * `https://pastebin.com` : Autorise l'exécution de ressources hébergées sur ** * `example.com` : Autorise l'exécution de ressources hébergées sur *example.com* * `code.jquery.com` : Autorise l'exécution de ressources hébergées sur le sous domaine *code.jquery.com* * `https://ssl.google-analytics.com` : Autorise l'exécution de ressources hébergées sur le sous domaine *ssl.google-analytics.com* Ma première idée est d'exploiter la vulnérabilité de file upload trop permissive qui va me permettre d'uploader sur la plateforme un fichier javascript malicieux. Ce fichier aura donc la même origine que celle de l'application : ![](/files/-LuD_ONTkEHNZDH8AmhW) Etant donné qu'il est possible d'accéder directement au fichier, je peux soumettre son URL dans le formulaire du challenge CSP : ![](/files/-LuH8Z8URGYSn2Df9-zB) Cela permet de contourner la source `'self'` du CSP. Concernant la liste blanche d'URL autorisées, `https://pastbin.com` va me permettre également l'exécution de script : ![](/files/-LuDaWAdAh7kvrdTc_YM) Pour l'exploitation, j'utilise le mode "raw" afin de soumettre l'URL à DVWA : ![](/files/-LuDajV26x_qeygdCbki) Ce qui permet de faire exécuter un script contrôlé par mes soins tout en respectant la liste blanche imposée par DVWA : ![](/files/-LuDbRJ0RmPCLT8NiF-X) Il suffit d'adapter la payload malicieux afin de récupérer le jeton de la victime : ![](/files/-LuDcGaaNsbgyHn8rLHr) Reste maintenant à savoir comment s'y prendre pour que l'attaque affecte un autre utilisateur. En effet, la requête n'est pas de type **`GET`** mais de type **`POST`**, ce qui m'empêche de partager facilement un lien forgé à la victime : ![](/files/-LuDe2cjBmCs6uF8z7Sr) La solution que j'ai trouvée pour remédier à ce problème est d'utiliser la faille CSRF présente dans cette requête (aucun mécanisme de protection n'est présent). Il me faut donc héberger sur un serveur d'attaque la page malicieuse suivante : ```markup Exploitation POST XSS

Post reflected XSS !

``` Puis de fournir à la victime le lien permettant d'accéder à ma page, par exemple `http://192.168.56.182/dvwa/post_xss.html` : ![](/files/-LuDfMJhJBe5taQIhhx0) La victime, obligatoirement authentifiée, sera redirigée (ce qui déclenchera l'exécution de notre script) vers le site du challenge CSP de DVWA et l'attaquant réceptionnera son jeton : ![](/files/-LuDfcBQK702qn0KNxs6) --- # 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://sharpforce.gitbook.io/cybersecurity/walkthroughs/deliberately-vulnerable/damn-vulnerable-web-application-dvwa/csp-bypass/niveau-low.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.