Escribe una comprobación portátil de diagnósticos con Nuclei

Introducción

Un escáner que solo comprueba el estado encontró coincidencias tanto en una respuesta de diagnóstico real como en un ejemplo de documentación. Ahora construirás una comprobación que responda a la pregunta prevista: ¿ha recibido una solicitud sin autenticación el objeto activo de diagnóstico interno de esta aplicación?

Crearás una plantilla YAML nativa de Nuclei, probarás sus condiciones de respuesta y analizarás seis sitios aprobados de Fieldwork Studio. Tu entrega será la plantilla reutilizable y los hallazgos reales. El entorno es independiente del laboratorio anterior; no se transfieren archivos ni procesos.

Completa primero Confirma la exposición de diagnósticos con respuestas reales, o debes sentirte cómodo leyendo estados HTTP, cabeceras de tipo de contenido, un objeto JSON pequeño y hallazgos JSONL de Nuclei. Este laboratorio explica su YAML y las expresiones de coincidencia. Toda la configuración del objetivo es sintética. Utiliza únicamente el ámbito de solo lectura suministrado, conserva las páginas públicas de talleres y sus programas, y calcula unos 65 minutos, incluida la lectura y los errores habituales; es una estimación del autor.

Establece el contrato de respuesta de la comprobación

En este paso establecerás el servicio normal y la pregunta exacta que debe responder tu plantilla. Abre Workshops, consulta las sesiones y utiliza Get the workshop schedule para descargar el archivo real fieldwork-schedule.csv. Printmaking y Bookbinding deben seguir disponibles durante toda la evaluación.

Las dos tarjetas de talleres muestran el servicio público que debes conservar. El enlace verde Get the workshop schedule descarga su programa real.

Cambia a Auditor. Entra en el contenedor de auditoría Kali en /home/labex/project. Lee el ámbito y las URL base aprobadas:

cat scope.txt

cat targets.txt

Los seis sitios son studio, archive, manual, garden, status y members, bajo http://workshop.test:8080/. Prueba únicamente estas URL mediante solicitudes HTTP GET de solo lectura. No modifiques los sitios objetivo ni los archivos de ámbito suministrados.

Vuelve a consultar una respuesta activa de diagnóstico. Como antes, curl -i incluye las cabeceras de respuesta:

curl -i http://workshop.test:8080/studio/maintenance/diagnostics

Un hallazgo debe combinar HTTP 200, un tipo de contenido JSON y el objeto de diagnóstico interno de nivel superior de la aplicación. Sus cuatro campos escalares identifican el servicio y la visibilidad, una ruta absoluta de archivo de base de datos y un recuento de solicitudes entero no negativo sin comillas. La ruta del archivo y el recuento pueden cambiar. El orden de las claves y los espacios en blanco no afectan al significado. Un ejemplo anidado de documentación no es el objeto activo.

Tu comprobación se dirige al formato de respuesta declarado de esta pequeña aplicación. No demuestra que un punto de acceso JSON arbitrario sea vulnerable ni que un sitio carezca de otros problemas. En particular, una página pública, un resumen JSON público, una respuesta de estado del servicio, un rechazo HTTP o una redirección al inicio de sesión no constituyen la evidencia de exposición requerida.

Si cambia tu directorio, usa pwd para inspeccionarlo y cd /home/labex/project para volver antes de leer o crear nombres de archivo relativos. Conserva tu trabajo al volver a conectarte; abrir una terminal no reconstruye la escena.

Construye los matchers nativos de respuesta

En este paso escribirás una plantilla reutilizable en lugar de depender de una coincidencia HTTP 200. Permanece en Auditor.

Una plantilla de Nuclei tiene un id, una sección descriptiva info y una sección de protocolo como http. La sangría agrupa campos YAML anidados, mientras que un guion inicia un elemento de lista. Usa espacios, no tabulaciones. method: GET selecciona una solicitud de solo lectura. {{BaseURL}} procede del objetivo pasado a Nuclei, de modo que la plantilla no incorpora un nombre de host, puerto o prefijo de sitio concreto. redirects: false mantiene una redirección de inicio de sesión visible como redirección.

Un matcher es una condición aplicada a una respuesta. Esta plantilla requiere los tres grupos de matchers:

matchers-condition: and combina estos grupos. Sin él, la relación OR predeterminada podría permitir que HTTP 200 por sí solo volviera a producir un hallazgo. Dentro del matcher DSL, condition: and también exige todas las expresiones del cuerpo enumeradas.

DSL significa lenguaje específico de dominio: aquí son expresiones breves que inspeccionan una respuesta. body es el texto de la respuesta. json_minify(body) analiza y compacta JSON válido, eliminando espacios en blanco irrelevantes sin depender del orden de las claves. contains(text, fragment) busca un fragmento literal. Normalizar primero permite que un campo escrito como "visibility" : "internal" cumpla la misma condición que "visibility":"internal".

regex(pattern, text) aplica una expresión regular. Las expresiones siguientes utilizan un conjunto pequeño de símbolos:

• /[A-Za-z0-9._/-]+ exige una barra inicial seguida de uno o más caracteres de ruta: letras, dígitos, puntos, guiones bajos, barras o guiones. Acepta rutas absolutas diferentes, incluidas letras mayúsculas.
• [0-9]+[,}] exige dígitos seguidos inmediatamente de una coma o una llave de cierre. Así se evita tratar un recuento entre comillas, un valor negativo o el principio de un decimal como el recuento entero.
• ^\{[^{}]*\}$ exige un par externo de llaves y ninguna llave anidada, lo que coincide con el formato de diagnóstico plano de cuatro campos de este curso en lugar de un objeto dentro de un ejemplo de documentación.

La expresión de cabecera usa (?im) para una coincidencia por líneas que no distingue mayúsculas de minúsculas; \s* permite espacios en blanco. Su grupo opcional (?: ... )? acepta parámetros como ; charset=utf-8. Puedes copiar esta expresión como comprobación completa del tipo de contenido JSON; no necesitas construir un analizador MIME general.

En el YAML siguiente, >- introduce un valor de texto en la siguiente línea con sangría. Conserva las comillas y barras inversas de la expresión sin escapes de comillas YAML adicionales. Las comillas simples dentro de cada expresión rodean texto literal; las comillas dobles de ese texto son la puntuación de los campos JSON que se busca.

Crea diagnostics.yaml. Como en el laboratorio anterior, > sustituye este archivo y el delimitador entre comillas del here-document copia el bloque literalmente. El YAML final debe estar solo en su línea.

cat > diagnostics.yaml <<'YAML'
id: workshop-diagnostics-exposed
info:
  name: Public workshop diagnostics
  author: labex
  severity: medium
http:
  - method: GET
    path:
      - "{{BaseURL}}/maintenance/diagnostics"
    redirects: false
    matchers-condition: and
    matchers:
      - type: status
        status: [200]
      - type: regex
        part: header
        regex:
          - '(?im)^content-type:\s*application/json(?:\s*;[^\r\n]*)?\s*$'
      - type: dsl
        condition: and
        dsl:
          - >-
            contains(json_minify(body), '"service":"workshop-portal"')
          - >-
            contains(json_minify(body), '"visibility":"internal"')
          - >-
            regex('"database_file":"/[A-Za-z0-9._/-]+"', json_minify(body))
          - >-
            regex('"request_count":[0-9]+[,}]', json_minify(body))
          - >-
            regex('^\{[^{}]*\}$', json_minify(body))
YAML

Pide al motor real que valide la plantilla. -validate comprueba la sintaxis de la plantilla de Nuclei; no demuestra que el comportamiento de detección sea correcto. -t selecciona tu archivo, -duc desactiva las comprobaciones de actualizaciones, -ni desactiva las llamadas externas de Interactsh y -nc elimina los códigos de color de la terminal.

nuclei -t diagnostics.yaml -validate -duc -ni -nc

Espera All templates validated successfully. Si Nuclei informa de un error de YAML o de expresión, compara la sangría, las comillas y las barras inversas con el bloque completo y repite el here-document corregido y el comando de validación. Conserva targets.txt y scope.txt.

El curso acepta este subconjunto enseñado: una definición HTTP GET en la ruta aprobada {{BaseURL}}/maintenance/diagnostics, sin redirecciones y con matchers de estado, palabra, regex o DSL que solo evalúen la respuesta. Las funciones auxiliares DSL permitidas son contains, contains_all, contains_any, regex, json_minify, len, tolower, toupper, starts_with y ends_with, aplicadas a body, all_headers, status_code o content_length. Utiliza solo id, info y http en el nivel superior, y los campos de solicitud method, path, redirects, matchers-condition y matchers. Mantén la plantilla dentro de 32 KiB y con un máximo de doce matchers. Otros protocolos, scripts, llamadas externas y acceso a archivos locales quedan fuera de esta tarea. Se aceptan disposiciones equivalentes de matchers dentro de este ámbito.

La verificación ejecuta tu plantilla sin cambios con el motor nativo de Nuclei contra ejemplos desechables de respuestas positivas y negativas. Estos ejemplos incluyen cambios de puertos, nombres de host, valores, disposición JSON y parámetros del tipo de contenido. Un archivo que simplemente se valide, siempre coincida o nunca coincida no puede superar estas comprobaciones funcionales.

Ejecuta la comprobación y revisa la entrega

En este paso aplicarás tu plantilla a los sitios aprobados reales y conservarás evidencias que se puedan revisar. Permanece en Auditor. Puedes reutilizar el mismo archivo cuando cambie la lista de objetivos porque su ruta es relativa a BaseURL.

Ejecuta la evaluación real. -l suministra las URL base, -o guarda los hallazgos y -elog guarda los errores de solicitud. -jsonl utiliza un objeto JSON por hallazgo; -ot omite la plantilla codificada y conserva la solicitud y respuesta nativas.

nuclei -t diagnostics.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o findings.jsonl -elog scan-errors.jsonl

Antes de interpretar la ausencia de un hallazgo, inspecciona el registro nativo de errores de solicitud:

cat scan-errors.jsonl

Debería estar vacío en esta ejecución correcta. Un error de conexión significa que la comprobación está incompleta, incluso si Nuclei sale con cero o imprime No results found. Corrige los errores de escritura o conexión antes de formular una conclusión y utiliza nombres de archivo nuevos al reintentar para no confundir las evidencias anteriores con la nueva ejecución. Los archivos finales aceptados son findings.jsonl y scan-errors.jsonl; si has reintentado con nombres nuevos, utiliza cp para copiar el par correcto a esos nombres de archivo finales. Por ejemplo, cp retry-findings.jsonl findings.jsonl copia el primer archivo sobre el segundo; copia también el registro de errores correspondiente.

Lee los hallazgos:

cat findings.jsonl

Espera una URL coincidente que termine en /studio/maintenance/diagnostics. Lee la respuesta incorporada y su X-Audit-Event, no solo el número de hallazgos. El cuerpo debe cumplir el contrato que comprobaste manualmente.

Confirma por qué no coincidieron dos alternativas plausibles:

curl -i http://workshop.test:8080/garden/maintenance/diagnostics

Es JSON público con visibility establecido en public. No es una exposición de diagnósticos internos.

curl -i http://workshop.test:8080/members/maintenance/diagnostics

Espera HTTP 302 con un Location que apunte al inicio de sesión. Tu plantilla no lo sigue ni confunde la página de inicio de sesión con un resultado de diagnóstico. Los otros sitios que no coinciden son el archive protegido, la documentación anidada de manual y la respuesta mínima de estado de status. Cada uno sigue recibiendo la solicitud de solo lectura aprobada; la ausencia de hallazgos solo describe las condiciones de esta plantilla, no la seguridad global del sitio.

Entrega archivos regulares autosuficientes que auditor pueda leer. Tu entrega consiste en la plantilla reutilizable diagnostics.yaml, el archivo real findings.jsonl y el scan-errors.jsonl correspondiente. Conserva los archivos de ámbito junto a ellos. La plantilla no contiene una ruta de archivo de base de datos, recuento de solicitudes, nombre de host o puerto específicos de un objetivo. La verificación comprueba la evidencia real antes de ejecutar ejemplos aislados y conserva tus archivos. Sus solicitudes habituales de conservación de solo lectura pueden añadir entradas al registro del servidor y aumentar los recuentos de solicitudes; no se convierten en evidencia de la evaluación del alumno.

El desafío independiente te da una lista de despliegues y direcciones nueva. Aplica el mismo contrato de respuesta y el mismo rigor con los errores, manteniendo disponibles el uso público de los talleres y el acceso de mantenimiento autorizado.

Resumen

Has escrito una plantilla HTTP nativa de Nuclei que combina estado, tipo de contenido y campos de diagnóstico normalizados. Has probado diferencias entre respuestas, conservado la portabilidad de BaseURL y evaluado todos los sitios aprobados sin tratar un fallo de ejecución como resultado negativo. Tu entrega consiste en la plantilla real, los hallazgos y el registro nativo de errores de solicitud correspondiente.