Introducción
Fieldwork Studio organiza talleres de artesanía abiertos al público. Su programa debe poder consultarse y descargarse fácilmente, mientras que los diagnósticos de mantenimiento deben requerir autorización. Tu tarea consiste en confirmar qué respuestas exponen realmente los datos de diagnóstico internos de esta aplicación.
Primero usarás el sitio normalmente. Después compararás tres respuestas reales y ejecutarás una comprobación inicial de Nuclei deliberadamente amplia. Terminarás con conclusiones vinculadas a las respuestas que has inspeccionado, en lugar de considerar que cada hallazgo del escáner es un problema confirmado. Toda la configuración y las identidades son sintéticas; las solicitudes HTTP y la ejecución del escáner son reales.
Solo necesitas saber introducir comandos básicos en la terminal y comprender las rutas. El laboratorio explica HTTP, JSON y la salida del escáner a medida que aparecen. El auditor Kali y el objetivo son contenedores aislados que comparten el kernel de una VM. Prueba únicamente el ámbito suministrado, realiza solicitudes de solo lectura y conserva el sitio y el programa de talleres. Calcula unos 50 minutos, incluida la lectura y los errores habituales; es una estimación del autor.
Usa el programa público de talleres
En este paso establecerás qué debe conservar el acceso público normal. Abre Workshops. La página presenta las sesiones de artesanía de Fieldwork Studio. Sigue Get the workshop schedule para descargar fieldwork-schedule.csv. Contiene el nombre, la hora y la sala de los talleres Printmaking y Bookbinding. El acceso público a esta información es intencionado.
Las dos tarjetas de sesiones y el enlace verde al programa constituyen el servicio público normal. Conserva la información real de los talleres mientras evalúas los diagnósticos.
Cambia a Auditor, la terminal Kali. Se inicia en /home/labex/project. La entrada del navegador y esta terminal acceden al mismo servicio de talleres; no representan máquinas objetivo distintas.
cat muestra un archivo de texto. Lee el ámbito autorizado antes de enviar comprobaciones de seguridad:
cat scope.txt
Solo están autorizadas las solicitudes HTTP GET de solo lectura a las URL base de targets.txt. Una URL base identifica un sitio; a ella se añade la ruta de diagnósticos. Muestra la lista:
cat targets.txt
Deberías ver studio, archive y manual bajo http://workshop.test:8080/. El puerto 8080 identifica el servicio de este curso. Conserva todos los sitios, la configuración y los datos de los talleres. Estás evaluando el acceso, no modificando la aplicación.
Si falla una ruta de archivo relativa, usa pwd para mostrar el directorio actual y vuelve con:
cd /home/labex/project
Cerrar Auditor o volver a conectarte no recrea los sitios. Tus archivos permanecen en este espacio de trabajo.
Lee las respuestas antes de decidir
En este paso compararás el punto de acceso de diagnósticos de cada sitio aprobado. Permanece en Auditor. HTTP es el protocolo de solicitud y respuesta que utiliza este sitio. curl envía una solicitud e imprime el cuerpo de la respuesta. Su opción -i también imprime las cabeceras de respuesta, incluidos el estado y el tipo de contenido.
curl -i http://workshop.test:8080/studio/maintenance/diagnostics
La respuesta comienza con HTTP/1.0 200 OK. Esto significa que el servidor ha devuelto correctamente el recurso solicitado; por sí solo no demuestra un problema de seguridad. Content-Type: application/json; charset=utf-8 indica que el cuerpo es JSON codificado como texto UTF-8. JSON representa valores con nombre entre llaves. Las comillas dobles rodean los nombres y los valores de texto; los valores numéricos no llevan comillas.
El objeto plano contiene service, visibility, database_file y request_count. Para esta aplicación, service es workshop-portal, visibility es internal, el archivo de base de datos es una ruta absoluta y el recuento de solicitudes es un entero no negativo. La ruta del archivo procede de la configuración del sitio en ejecución: su página pública de talleres y su descarga CSV leen esa base de datos SQLite real. SQLite almacena una base de datos pequeña en un archivo. El recuento cambia a medida que llegan solicitudes. Esta combinación es el contrato de diagnósticos publicado en scope.txt. No es una definición universal de vulnerabilidad.
Una solicitud sin autenticación ha recibido esos valores internos. Fíjate en su cabecera X-Audit-Event: el servidor asigna un identificador distinto a cada respuesta real. Anota el identificador en un lugar privado para la evaluación final. Es una evidencia que puedes referenciar sin copiar los valores internos en tu resumen.
Compara el segundo sitio:
curl -i http://workshop.test:8080/archive/maintenance/diagnostics
Espera 401 Unauthorized y una explicación de que se requiere una credencial de mantenimiento. Este rechazo es intencionado. No tienes ninguna credencial dentro del ámbito autorizado y no debes intentar eludirlo. curl -i puede finalizar normalmente mientras muestra HTTP 401: entregar correctamente un rechazo es distinto de obtener autorización.
Ahora inspecciona el tercer sitio:
curl -i http://workshop.test:8080/manual/maintenance/diagnostics
Devuelve HTTP 200 y JSON, pero los campos de diagnóstico están anidados dentro de un objeto example. Documentan un formato de respuesta; no son el objeto de diagnóstico activo de nivel superior de este sitio. Compara la estructura y el significado, en lugar de limitarte a buscar la palabra internal. Conserva también el identificador de evento de esta respuesta.
Si ves 404, compara cuidadosamente la URL con la ruta suministrada y repite la solicitud corregida. Could not resolve host o Failed to connect significa que la solicitud no obtuvo la respuesta prevista; no permite concluir que el sitio es seguro o que está expuesto. Comprueba la escritura y el nombre de host y puerto exactos del curso. No sustituyas el objetivo por un sitio web público.
Investiga un hallazgo amplio de Nuclei
En este paso verás cómo una comprobación puede ejecutarse correctamente y aun así formular una conclusión demasiado amplia. Permanece en Auditor. Nuclei es un escáner basado en plantillas: una plantilla describe las solicitudes y las condiciones de respuesta que producen hallazgos. Un hallazgo significa que se cumplieron esas condiciones; todavía debes juzgar si demuestran el problema que pretendías comprobar.
Lee la plantilla inicial preparada:
cat too-broad.yaml
YAML utiliza la sangría para agrupar ajustes. Esta plantilla inicial envía un GET a la ruta de diagnósticos de cada URL base y después comprueba únicamente el estado HTTP 200. El marcador {{BaseURL}} se sustituye por la URL base aprobada actual. No inspecciona el significado del objeto de diagnóstico.
Ejecuta la plantilla inicial sobre la lista suministrada. -t selecciona una plantilla local; -l lee la lista de objetivos; -o guarda los hallazgos; y -elog guarda los errores de solicitud. -jsonl escribe un hallazgo JSON por línea y -ot omite la plantilla codificada en esa salida. Las opciones de preparación -duc y -ni desactivan las comprobaciones de actualizaciones y las llamadas externas de Interactsh. Nuestra plantilla no necesita ninguna de las dos. Conserva estas opciones para el ejercicio aislado.
nuclei -t too-broad.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o broad-findings.jsonl -elog broad-errors.jsonl
-nc elimina los códigos de color de la terminal. Este comando realiza solicitudes reales de solo lectura. Espera hallazgos tanto para studio como para manual, porque ambos devolvieron 200. La ruta protegida de archive no coincide. Un análisis que no imprime hallazgos no constituye automáticamente una comprobación negativa completada.
Lee el registro nativo de errores de solicitud antes de juzgar los resultados:
cat broad-errors.jsonl
Un registro vacío significa que no se registraron errores de solicitud en esta ejecución. Un fallo de conexión puede dejar el estado de salida del proceso de Nuclei en cero, así que ni el estado de salida ni un archivo de hallazgos vacío bastan por sí solos. Si el registro contiene un error, corrige el problema del objetivo o de la conexión antes de sacar una conclusión. Conserva la evidencia original del error; utiliza un nombre de archivo de salida nuevo al reintentar.
Inspecciona los hallazgos:
cat broad-findings.jsonl
Cada línea contiene una URL matched-at y la evidencia de solicitud/respuesta. Compara el hallazgo de manual con el ejemplo de documentación anidado que ya leíste. Es un falso positivo para la pregunta de exposición de diagnósticos que querías responder, aunque el matcher de estado de la plantilla inicial funcionó tal como estaba escrito. La respuesta de studio sí cumple las condiciones de exposición definidas.
Estas respuestas sintéticas no contienen secretos reales. En una evaluación real, los hallazgos sin procesar pueden contener material sensible y deben tratarse de forma privada. No los subas a un escáner externo ni los pegues en un informe público.
Guarda una evaluación vinculada a evidencias
En este paso separarás tu conclusión de la coincidencia amplia del escáner. Permanece en Auditor. Crea assessment.json con una entrada por sitio. Cada entrada registra el evento de respuesta real que inspeccionaste y tu conclusión. Usa exposed, access-denied y documentation-example para los tres resultados enseñados anteriormente.
Lo siguiente es un here-document completo del shell. cat > assessment.json escribe un archivo; > sustituye su contenido. <<'JSON' hace que el shell copie literalmente el texto siguiente hasta la línea que solo contiene JSON. El delimitador entre comillas impide la expansión del shell dentro del texto. Sustituye cada valor REPLACE_... por un X-Audit-Event real de la respuesta de diagnósticos de ese sitio antes de ejecutar el bloque. Conserva las comillas dobles y las comas de JSON.
cat > assessment.json <<'JSON'
{
"studio": {"event_id": "REPLACE_STUDIO_EVENT", "conclusion": "exposed"},
"archive": {"event_id": "REPLACE_ARCHIVE_EVENT", "conclusion": "access-denied"},
"manual": {"event_id": "REPLACE_MANUAL_EVENT", "conclusion": "documentation-example"}
}
JSON
Si no conservaste un identificador, repite la solicitud curl -i de ese sitio del paso 2 y utiliza su nuevo identificador. Repetir una lectura crea otra respuesta real y puede aumentar request_count; no repara ni cambia la política de acceso del sitio.
Muestra el archivo guardado:
cat assessment.json
Si una comilla, una coma o un valor de evento es incorrecto, repite el here-document completo corregido. No copies los valores literales de los marcadores. Entrega assessment.json como archivo regular legible en este espacio de trabajo. La verificación compara tus conclusiones con respuestas existentes; no genera las solicitudes de evaluación que falten. Tampoco exige que copies el host de diagnóstico o el cuerpo sin procesar en este pequeño resumen.
Tu resultado confirma la exposición en studio, observa un rechazo auténtico en archive y explica la coincidencia engañosa de documentación en manual. No afirma que se hayan probado todas las demás rutas o vulnerabilidades. El siguiente laboratorio guiado inicia una escena nueva y te enseña a sustituir el matcher amplio por una comprobación nativa y portátil de Nuclei.
Resumen
Has utilizado el programa público de talleres, inspeccionado estados HTTP y la estructura JSON, y confirmado una exposición de diagnósticos internos. Has ejecutado una comprobación inicial real de Nuclei y explicado su falso positivo de documentación. Tu evaluación vincula cada conclusión con una respuesta existente y mantiene intacto el acceso público normal.
