¿Cómo encontrar vulnerabilidades en tu aplicación web?

Hoy en día, cada vez más empresas ofrecen API web para acceder a sus servicios. Suelen seguir el estilo REST. Dicho servicio web RESTful parece una aplicación web normal. Acepta una solicitud HTTP, hace algo de magia y luego responde con una respuesta HTTP. Una de las principales diferencias es que la respuesta normalmente no contiene HTML para mostrarse en un navegador web. En cambio, la respuesta generalmente contiene datos en un formato (por ejemplo, JSON o XML) que es más fácil de procesar por otra aplicación.

Desafortunadamente, dado que un servicio web RESTful sigue siendo una aplicación web, puede contener vulnerabilidades de seguridad típicas para aplicaciones web como inyecciones de SQL, XXE, etc. Una de las formas de identificar problemas de seguridad en aplicaciones web es usar escáneres de seguridad web. Afortunadamente, dado que un servicio web RESTful sigue siendo una aplicación web, podemos usar escáneres de seguridad web para buscar problemas de seguridad en las API web.

Existen varios escáneres de seguridad web conocidos. Uno de ellos es w3af.

¿Cómo encuentra w3af las vulnerabilidades?

w3af es un marco de auditoría y ataque de aplicaciones web. El objetivo del proyecto es crear un marco para ayudarlo a proteger sus aplicaciones web al encontrar y explotar todas las vulnerabilidades de las aplicaciones web. Este marco contiene cientos de complementos que ayudarán a encontrar vulnerabilidades.

Los complementos de rastreo utilizan diferentes técnicas para identificar nuevas URL, formularios y cualquier otro recurso que pueda ser útil durante las fases de auditoría y fuerza bruta. En otras palabras, estos complementos exploran la aplicación e intentan descubrir puntos de entrada para probar.

Los complementos de auditoría utilizan el conocimiento creado por los complementos de rastreo para encontrar vulnerabilidades en la aplicación web y el servidor web remotos. Estos complementos prueban los puntos de entrada descubiertos en busca de vulnerabilidades.

Al habilitar algunos complementos, podría encontrar algunas vulnerabilidades, pero no muchas. Este es el resultado de mi proyecto web spring-boot. Un escáner web generalmente intenta navegar por un sitio web para encontrar todas las páginas y parámetros disponibles que luego se pueden probar en busca de vulnerabilidades. En el caso de un sitio web típico, un escáner a menudo comienza desde una página de inicio y busca enlaces a otras páginas en el código HTML. Pero este enfoque no funciona con las API web porque, por lo general, los extremos de las API no brindan datos HTML y las API generalmente no se refieren entre sí en sus respuestas.

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

Una RESTful Api Spec es importante para un escáner

¿Cómo obtenemos una lista de puntos finales y parámetros de API para escanear? Hay dos formas principales:

• N.º 1 RESTful Api Spec Un servicio web puede tener una especificación OpenAPI que describe todos los puntos finales, parámetros, respuestas, esquemas de autenticación, etc. Normalmente, los desarrolladores proporcionan dicha especificación.
• #2 Proxy Usando un proxy, podemos capturar solicitudes HTTP que un cliente envió a los puntos finales de la API. Luego, podemos analizar las solicitudes capturadas y extraer información sobre los parámetros.

La forma en que el #1 se ve mucho mejor que el #2. En un mundo perfecto, cada servicio web tiene una especificación OpenAPI que siempre está disponible y actualizada. Pero en el mundo real, no parece suceder con demasiada frecuencia. Un desarrollador puede cambiar las API pero olvidarse de actualizar la especificación o, por alguna razón, no hacer que la especificación esté disponible públicamente. En la mayoría de los casos, la API REST disponible públicamente tiene documentos legibles por humanos, lo cual es bueno, pero generalmente es difícil de usar de manera automatizada.

• Pero, APIGIT podría hacer esto más fácil.

APIGIT es una plataforma de colaboración que destaca por su compatibilidad nativa con Git, que simplifica el proceso de desarrollo de API y el control de versiones, lo que permite a los usuarios diseñar, documentar, simular, probar y compartir API fácilmente. El editor visual de OpenAPI de la plataforma, en combinación con su compatibilidad nativa con Git, facilita que el equipo colabore y comparta su trabajo de manera eficiente y sin inconvenientes.

¿Cómo encuentra w3af vulnerabilidades según una RESTful Api Spec?

Aquí hay parte de mi RESTful Api Spec.

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

Habilite los complementos relacionados y el feed con su RESTful Api Spec:

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

Podemos encontrar más vulnerabilidades.

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

Hablemos del complemento crawl.open_api. La primera versión del complemento intentó encontrar una especificación OpenAPI en una de las ubicaciones conocidas, como:

/api/openapi.json

/api/v2/swagger.json

/api/v1/swagger.yaml

etcétera. Es una característica muy agradable. Si tiene varios servicios web para probar, y sus especificaciones de API están disponibles en ubicaciones conocidas, solo necesita alimentar el escáner con los nombres de host, y eso es todo. El escáner encontrará todos los puntos finales de API por sí mismo y luego los probará. Desafortunadamente, a veces los servicios web no proporcionan especificaciones API y el parámetro custom_spec_file permite establecer una ruta local a la especificación OpenAPI. Un usuario puede usar los documentos de la API y crear la especificación por sí mismo o, a veces, las especificaciones están disponibles públicamente pero no en una ubicación conocida.