Wie finden Sie Schwachstellen in Ihrer Webanwendung?

Heutzutage stellen immer mehr Unternehmen Web-APIs für den Zugriff auf ihre Dienste bereit. Sie folgen normalerweise dem REST-Stil. Ein solcher RESTful-Webdienst sieht aus wie eine normale Webanwendung. Es akzeptiert eine HTTP-Anfrage, vollführt einen Zauber und antwortet dann mit einer HTTP-Antwort. Einer der Hauptunterschiede besteht darin, dass die Antwort normalerweise kein HTML enthält, das in einem Webbrowser gerendert werden kann. Stattdessen enthält die Antwort normalerweise Daten in einem Format (z. B. JSON oder XML), das von einer anderen Anwendung einfacher verarbeitet werden kann.

Da ein RESTful-Webdienst immer noch eine Webanwendung ist, kann er leider typische Sicherheitslücken für Webanwendungen wie SQL-Injections, XXE usw. enthalten. Eine Möglichkeit, Sicherheitsprobleme in Webanwendungen zu identifizieren, ist die Verwendung von Web-Sicherheitsscannern. Da es sich bei einem RESTful-Webdienst glücklicherweise immer noch um eine Webanwendung handelt, können wir Web-Sicherheitsscanner verwenden, um nach Sicherheitsproblemen in Web-APIs zu suchen.

Es gibt mehrere bekannte Web-Sicherheitsscanner. Einer davon ist w3af.

Wie findet w3af Schwachstellen?

w3af ist ein Web Application Attack and Audit Framework. Das Ziel des Projekts besteht darin, ein Framework zu schaffen, das Ihnen hilft, Ihre Webanwendungen zu schützen, indem es alle Schwachstellen von Webanwendungen findet und ausnutzt. Dieses Framework enthält Hunderte von Plugins, die beim Auffinden von Schwachstellen helfen.

Crawl-Plugins verwenden unterschiedliche Techniken, um neue URLs, Formulare und andere Ressourcen zu identifizieren, die während der Audit- und Bruteforce-Phase von Nutzen sein könnten. Mit anderen Worten: Diese Plugins durchsuchen die Anwendung und versuchen, Einstiegspunkte zum Testen zu finden.

Audit-Plugins nutzen das von Crawl-Plugins gewonnene Wissen, um Schwachstellen in der Remote-Webanwendung und dem Webserver zu finden. Diese Plugins testen die entdeckten Einstiegspunkte auf Schwachstellen.

Durch die Aktivierung einiger Plugins könnten Sie einige Schwachstellen finden, aber nicht viele. Hier ist ein Ergebnis meines Spring-Boot-Webprojekts. Ein Webscanner versucht normalerweise, eine Website nach allen verfügbaren Seiten und Parametern zu durchsuchen, die dann auf Schwachstellen getestet werden können. Bei einer typischen Website startet ein Scanner oft von einer Homepage aus und sucht im HTML-Code nach Links zu anderen Seiten. Dieser Ansatz funktioniert jedoch nicht mit Web-APIs, da API-Endpunkte normalerweise keine HTML-Daten bereitstellen und APIs in ihren Antworten normalerweise nicht aufeinander verweisen.

{
  "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
    }
  ]
}

Für einen Scanner ist eine RESTful-API-Spezifikation wichtig

Wie erhalten wir eine Liste der zu scannenden API-Endpunkte und Parameter? Es gibt zwei Hauptmethoden:

• Nr. 1 RESTful-API-Spezifikation Ein Webdienst verfügt möglicherweise über eine OpenAPI-Spezifikation, die alle Endpunkte, Parameter, Antworten, Authentifizierungsschemata usw. beschreibt. Eine solche Spezifikation wird normalerweise von Entwicklern bereitgestellt.
• #2 Proxy Mithilfe eines Proxys können wir HTTP-Anfragen erfassen, die von einem Client an die API-Endpunkte gesendet wurden. Anschließend können wir die erfassten Anfragen analysieren und Informationen zu Parametern extrahieren.

Die Art und Weise, wie Nr. 1 viel besser aussieht als Nr. 2. In einer perfekten Welt verfügt jeder Webdienst über eine OpenAPI-Spezifikation, die immer verfügbar und aktuell ist. Aber in der realen Welt scheint es nicht allzu oft vorzukommen. Ein Entwickler kann die APIs ändern, aber vergessen, die Spezifikation zu aktualisieren, oder er macht die Spezifikation aus irgendeinem Grund nicht öffentlich verfügbar. In den meisten Fällen verfügen öffentlich verfügbare REST-APIs über für Menschen lesbare Dokumente, was zwar nett ist, aber normalerweise schwierig automatisiert zu verwenden ist.

• Aber APIGIT könnte dies einfacher machen.

APIGIT ist eine Kollaborationsplattform, die sich durch ihre native Git-Unterstützung auszeichnet, die den API-Entwicklungsprozess und die Versionskontrolle vereinfacht und es Benutzern ermöglicht, APIs einfach zu entwerfen, zu dokumentieren, zu simulieren, zu testen und zu teilen. Der visuelle OpenAPI-Editor der Plattform in Kombination mit der nativen Git-Unterstützung erleichtert dem Team die nahtlose und effiziente Zusammenarbeit und den Austausch ihrer Arbeit.

Wie findet w3af Schwachstellen gemäß einer RESTful-API-Spezifikation?

Hier ist ein Teil meiner RESTful-API-Spezifikation.

"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"
          }
        ],

Indem Sie verwandte Plugins und Feeds mit Ihrer RESTful-API-Spezifikation aktivieren:

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

Wir können weitere Schwachstellen finden.

{
  "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
    }
  ]
}

Lassen Sie uns über das crawl.open_api-Plugin sprechen. Die erste Version des Plugins versuchte, eine OpenAPI-Spezifikation an einem der bekannten Orte zu finden, wie zum Beispiel:

/api/openapi.json

/api/v2/swagger.json

/api/v1/swagger.yaml

usw. Es ist eine sehr schöne Funktion. Wenn Sie mehrere Webdienste testen möchten und deren API-Spezifikationen an bekannten Orten verfügbar sind, müssen Sie den Scanner nur mit den Hostnamen versorgen, und das ist alles. Der Scanner findet alle API-Endpunkte selbst und testet sie dann. Leider stellen Webdienste manchmal keine API-Spezifikationen bereit und der Parameter „custom_spec_file“ ermöglicht das Festlegen eines lokalen Pfads zur OpenAPI-Spezifikation. Ein Benutzer kann API-Dokumente verwenden und die Spezifikation selbst erstellen. Manchmal sind Spezifikationen jedoch öffentlich verfügbar, jedoch nicht an einem bekannten Ort.