Introducción
Una aplicación puede funcionar correctamente y revelar información que sus usuarios no necesitan. DeskLite ya está en ejecución, pero su respuesta de estado incluye detalles internos de desarrollo. Investigarás esa respuesta, cambiarás una opción de configuración y confirmarás que el servicio sigue siendo útil.
Solo necesitas conocimientos básicos para navegar por directorios y leer archivos en la terminal. Las peticiones, las respuestas HTTP, las opciones de configuración y el comando de reinicio se presentan al utilizarlos. Este es tu primer ciclo DevSecOps: observar un riesgo, corregir su causa y verificar tanto la seguridad como el funcionamiento normal.
Observar y Corregir la Respuesta de un Servicio
En este paso, leerás una respuesta de DeskLite, identificarás detalles internos innecesarios y corregirás la opción que los expone.
DeskLite es una pequeña aplicación de asistencia. El personal necesita información sobre los tickets y una indicación sencilla de que el servicio funciona, no ubicaciones internas de archivos ni diagnósticos de desarrollo. Esos detalles son la información que queremos proteger; quienes pueden leer una respuesta constituyen su audiencia.
Un servicio es un programa que sigue ejecutándose y responde a peticiones. Una petición HTTP solicita algo a un servicio web; su respuesta contiene un código de estado y un cuerpo. Usarás curl desde la terminal, sin necesitar navegador ni conocimientos de programación.
El servicio ya está preparado y en ejecución. Trabaja únicamente en su directorio:
cd /home/labex/project/desklite
Una URL indica a curl dónde enviar la petición. En http://127.0.0.1:8080/status, http es el protocolo, 127.0.0.1 representa esta máquina de laboratorio, 8080 selecciona el servicio y /status selecciona un endpoint, una respuesta concreta que ofrece. Aquí no necesitas configurar redes.
curl http://127.0.0.1:8080/status
El cuerpo está en JSON: campos con nombre y sus valores entre llaves. Solo debes leerlo, no escribir un programa.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service y status son útiles para la audiencia prevista. internal_path revela una ubicación interna y debug_details información de desarrollo. Conocer una ruta no concede automáticamente acceso al archivo, pero los detalles innecesarios pueden ayudar a planificar otras investigaciones. Esto es divulgación de información.
Añade la opción -i para incluir las cabeceras HTTP sobre el cuerpo:
curl -i http://127.0.0.1:8080/status
La primera línea contiene 200 OK: la petición tuvo éxito. Cabeceras como Content-Type: application/json describen el cuerpo; una línea vacía los separa. Las fechas pueden variar. Un estado HTTP satisfactorio no significa que la respuesta sea segura: esta respuesta correcta filtra información.
Lee la configuración del servicio, el archivo de ajustes que utiliza la aplicación:
cat service.conf
[service] agrupa los ajustes. Una línea que comienza con # es un comentario explicativo. debug = true es una opción booleana: true activa los diagnósticos de desarrollo y false los desactiva. El comentario relaciona esta opción con los campos expuestos.
Aplicar la Corrección de Configuración
La información de depuración ayuda a investigar problemas durante el desarrollo. Una opción útil entonces puede ser inadecuada para quienes solo necesitan un estado público. DevSecOps incorpora la seguridad al trabajo conjunto de desarrollo y operaciones: definir qué debe ser visible, cambiar la configuración y probar el resultado en ejecución.
Abre la configuración con nano, un editor de texto de terminal. Usa las flechas para llegar a la opción. Para los atajos siguientes, mantén Ctrl presionada mientras pulsas la letra:
nano service.conf
Cambia únicamente debug = true por debug = false. Conserva el encabezado [service] y el comentario. Guarda con Ctrl+O, Enter, y sal con Ctrl+X. Comprueba el archivo guardado:
cat service.conf
Ahora debe mostrar:
[service]
## Include development diagnostics in status responses.
debug = false
Un archivo en disco y un programa en ejecución son cosas distintas. Este servicio lee los ajustes al arrancar, por lo que guardar no actualiza la respuesta. El curso proporciona restart.sh para aplicar la configuración sin administrar procesos. bash ejecuta ese script preparado; no debes editarlo.
bash restart.sh
Salida esperada:
DeskLite restarted.
Solicita de nuevo el mismo endpoint, incluidas las cabeceras:
curl -i http://127.0.0.1:8080/status
Espera 200 OK y este cuerpo:
{
"service": "DeskLite",
"status": "running"
}
Los dos campos internos desaparecieron y el estado útil permanece. Si siguen presentes, comprueba que guardaste service.conf y ejecutaste el reinicio. Si el script informa de un error de configuración, restaura el encabezado y la escritura del booleano mostrados arriba y vuelve a intentarlo. No reemplaces la aplicación ni detengas el servicio para ocultar la respuesta.
Verificar la Seguridad y la Función de Negocio
En este paso, comprobarás que la corrección persiste tras otro reinicio y que DeskLite sigue atendiendo a sus usuarios.
Romper el servicio también eliminaría la respuesta, pero haría desaparecer funciones útiles. Necesitamos dos pruebas: los campos sensibles están ausentes y el servicio legítimo funciona. Una comprobación de salud indica la disponibilidad básica; una petición de negocio prueba la función que necesitan los usuarios.
Reinicia otra vez para confirmar que se sigue aplicando la configuración guardada:
bash restart.sh
Consulta de nuevo el estado:
curl -i http://127.0.0.1:8080/status
Espera 200 OK, service y status, sin internal_path ni debug_details. Solicita ahora el endpoint de salud:
curl -i http://127.0.0.1:8080/health
Espera 200 OK y:
{
"status": "ok"
}
Por último, solicita el endpoint de negocio:
curl -i http://127.0.0.1:8080/tickets
Espera 200 OK y el ticket original:
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
Un proceso saludable no demuestra por sí solo que el acceso a tickets funcione. Estas peticiones juntas muestran que se eliminó la divulgación y se conservó la función prevista. curl también puede mostrar un indicador de transferencia; evalúa el estado HTTP y el cuerpo, no ese indicador.
Antes de terminar, explica por qué 200 OK por sí solo no demuestra seguridad y por qué comprobar solo la salud no prueba que funcionen las funciones de negocio. Esta reflexión es para comprender; no se requiere una entrega escrita.
Resumen
Usaste curl y curl -i para leer una respuesta HTTP, distinguiste entre una petición correcta y una respuesta segura, y relacionaste los campos expuestos con una opción booleana. Guardaste el ajuste, reiniciaste DeskLite y confirmaste que estado, salud y acceso a tickets seguían funcionando sin diagnósticos internos.
Verificaste la configuración real y el servicio en ejecución, incluido otro reinicio. Este pequeño flujo conecta ajustes de desarrollo, comportamiento operativo y verificación de seguridad. El siguiente desafío aplica las mismas habilidades a otro servicio preparado.
