Comment trouver une vulnérabilité dans votre application Web ?

De nos jours, de plus en plus d'entreprises proposent des API Web pour accéder à leurs services. Ils suivent généralement le style REST. Un tel service Web RESTful ressemble à une application Web ordinaire. Il accepte une requête HTTP, fait un peu de magie, puis répond avec une réponse HTTP. L'une des principales différences est que la réponse ne contient normalement pas de code HTML à afficher dans un navigateur Web. Au lieu de cela, la réponse contient généralement des données dans un format (par exemple, JSON ou XML) qui est plus facile à traiter par une autre application.

Malheureusement, étant donné qu'un service Web RESTful est toujours une application Web, il peut contenir des vulnérabilités de sécurité typiques pour les applications Web telles que les injections SQL, XXE, etc. L'un des moyens d'identifier les problèmes de sécurité dans les applications Web consiste à utiliser des scanners de sécurité Web. Heureusement, étant donné qu'un service Web RESTful est toujours une application Web, nous pouvons utiliser des scanners de sécurité Web pour rechercher des problèmes de sécurité dans les API Web.

Il existe plusieurs scanners de sécurité Web bien connus. L'un d'eux est w3af.

Comment w3af trouve-t-il les vulnérabilités ?

w3af est un cadre d'attaque et d'audit d'applications Web. L'objectif du projet est de créer un cadre pour vous aider à sécuriser vos applications Web en trouvant et en exploitant toutes les vulnérabilités des applications Web. Ce framework contient des centaines de plugins qui aideront à trouver des vulnérabilités.

Les plugins de crawl utilisent différentes techniques pour identifier de nouvelles URL, formulaires et toute autre ressource qui pourrait être utile pendant les phases d'audit et de force brute. Autrement dit, ces plugins parcourent l'application et tentent de découvrir des points d'entrée à tester.

Les plugins d'audit utilisent les connaissances créées par les plugins d'analyse pour trouver des vulnérabilités sur l'application Web et le serveur Web distants. Ces plugins testent les points d'entrée découverts pour les vulnérabilités.

En activant certains plugins, vous pourriez trouver des vulnérabilités, mais pas beaucoup. Voici le résultat de mon projet web spring-boot. Un scanner Web essaie généralement de parcourir un site Web pour trouver toutes les pages et tous les paramètres disponibles qui peuvent ensuite être testés pour les vulnérabilités. Dans le cas d'un site Web typique, un analyseur démarre souvent à partir d'une page d'accueil et recherche des liens vers d'autres pages dans le code HTML. Mais cette approche ne fonctionne pas avec les API Web, car les points de terminaison des API ne servent généralement pas de données HTML et les API ne se réfèrent généralement pas les unes aux autres dans leurs réponses.

{
  "items": [
    {
      "href": "/scans/1/kb/0",
      "id": 0,
      "name": "Strange HTTP Reason message",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/1/kb/1",
      "id": 1,
      "name": "Cross site tracing vulnerability",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/1/kb/2",
      "id": 2,
      "name": "Omitted server header",
      "url": null
    },
    {
      "href": "/scans/1/kb/3",
      "id": 3,
      "name": "Allowed HTTP methods",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/1/kb/4",
      "id": 4,
      "name": "Click-Jacking vulnerability",
      "url": null
    }
  ]
}

Une spécification d'API RESTful est importante pour un scanner

Comment obtenir une liste des points de terminaison et des paramètres d'API à analyser ? Il existe deux manières principales :

• #1 RESTful Api Spec Un service Web peut avoir une spécification OpenAPI qui décrit tous les points de terminaison, paramètres, réponses, schémas d'authentification, etc. Une telle spécification est normalement fournie par les développeurs.
• #2 Proxy À l'aide d'un proxy, nous pouvons capturer les requêtes HTTP qui ont été envoyées aux points de terminaison de l'API par un client. Ensuite, nous pouvons analyser les requêtes capturées et extraire des informations sur les paramètres.

La façon dont le n° 1 est bien meilleur que le n° 2. Dans un monde parfait, chaque service Web a une spécification OpenAPI qui est toujours disponible et à jour. Mais dans le monde réel, cela ne semble pas arriver trop souvent. Un développeur peut modifier les API mais oublier de mettre à jour la spécification, ou pour une raison quelconque, il ne rend pas la spécification accessible au public. Dans la plupart des cas, l'API REST accessible au public contient des documents lisibles par l'homme, ce qui est agréable, mais il est généralement difficile à utiliser de manière automatisée.

• Mais, APIGIT pourrait rendre cela plus facile.

APIGIT est une plateforme de collaboration qui se distingue par sa prise en charge native de Git, qui simplifie le processus de développement d'API et le contrôle de version, permettant aux utilisateurs de concevoir, documenter, simuler, tester et partager facilement des API. L'éditeur visuel OpenAPI de la plate-forme, associé à sa prise en charge native de Git, permet aux équipes de collaborer et de partager facilement leur travail de manière transparente et efficace.

Comment w3af trouve-t-il les vulnérabilités selon une spécification RESTful Api ?

Voici une partie de ma spécification RESTful Api.

"paths": {
    "/find_pet": {
      "get": {
        "summary": "List pet",
        "operationId": "listPet",
        "tags": [
          "pet"
        ],
        "parameters": [
          {
            "name": "version",
            "in": "query",
            "description": "Get pet by version",
            "required": true,
            "type": "string"
          }
        ],

En activant les plugins et flux associés avec votre RESTful Api Spec :

[crawl.open_api]
custom_spec_location = /var/log/wvs/openapi2.json
no_spec_validation = True

Nous pouvons trouver plus de vulnérabilités.

{
  "items": [
    {
      "href": "/scans/0/kb/0",
      "id": 0,
      "name": "Strange HTTP Reason message",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/1",
      "id": 1,
      "name": "Omitted server header",
      "url": null
    },
    {
      "href": "/scans/0/kb/2",
      "id": 2,
      "name": "Cross site tracing vulnerability",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/3",
      "id": 3,
      "name": "Open API specification found",
      "url": "file:///var/log/wvs/openapi2.json"
    },
    {
      "href": "/scans/0/kb/4",
      "id": 4,
      "name": "Allowed HTTP methods",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/5",
      "id": 5,
      "name": "Cross site scripting vulnerability",
      "url": "http://192.168.1.65:8181/find_pet"
    },
    {
      "href": "/scans/0/kb/6",
      "id": 6,
      "name": "Unhandled error in web application",
      "url": "http://192.168.1.65:8181/_pet"
    },
    {
      "href": "/scans/0/kb/7",
      "id": 7,
      "name": "Unhandled error in web application",
      "url": "http://192.168.1.65:8181/find_"
    },
    {
      "href": "/scans/0/kb/8",
      "id": 8,
      "name": "Unhandled error in web application",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/9",
      "id": 9,
      "name": "Strange HTTP response code",
      "url": "http://192.168.1.65:8181/%2Fbin%2Fcat+%2Fetc%2Fpasswd_pet"
    },
    {
      "href": "/scans/0/kb/10",
      "id": 10,
      "name": "Click-Jacking vulnerability",
      "url": null
    }
  ]
}

Parlons du plugin crawl.open_api. La première version du plugin essayait de trouver une spécification OpenAPI sur l'un des emplacements bien connus tels que :

/api/openapi.json

/api/v2/swagger.json

/api/v1/swagger.yaml

et ainsi de suite. C'est une très belle fonctionnalité. Si vous avez plusieurs services Web à tester et que leurs spécifications d'API sont disponibles dans des emplacements bien connus, il vous suffit d'alimenter le scanner avec les noms d'hôte, et c'est tout. Le scanner va trouver tous les points de terminaison de l'API par lui-même, puis les tester. Malheureusement, les services Web ne fournissent parfois pas de spécifications d'API et le paramètre custom_spec_file permet de définir un chemin local vers la spécification OpenAPI. Un utilisateur peut utiliser les documents de l'API et créer lui-même la spécification, ou parfois les spécifications sont accessibles au public mais pas à un emplacement bien connu.