Введение
Приложение может исправно работать и при этом раскрывать сведения, которые пользователям не нужны. DeskLite уже запущен, но его ответ о состоянии содержит внутренние сведения для разработки. Вы исследуете ответ, измените один параметр и убедитесь, что сервис сохранил полезные функции.
Достаточно уметь перемещаться по каталогам и читать файлы в терминале. Запросы, ответы HTTP, параметры и готовая команда перезапуска объясняются по мере использования. Это ваш первый цикл DevSecOps: заметить риск, устранить причину и проверить одновременно безопасность и обычную работу.
Исследование и Исправление Ответа Сервиса
На этом шаге вы прочитаете ответ DeskLite, определите лишние внутренние сведения и исправите настройку, которая их раскрывает.
DeskLite — небольшое приложение службы поддержки. Сотрудникам нужны обращения и простое подтверждение работы сервиса, но не внутренние пути файлов и диагностика разработки. Эти внутренние сведения — то, что мы защищаем; аудитория ответа — люди, которые могут его прочитать.
Сервис — программа, которая продолжает работать и отвечает на запросы. HTTP-запрос обращается к веб-сервису; ответ содержит код состояния и тело. Вы будете отправлять запросы из терминала через curl, поэтому браузер и навыки программирования не нужны.
Сервис уже работает. Действуйте только в подготовленном каталоге:
cd /home/labex/project/desklite
URL сообщает curl, куда отправить запрос. В http://127.0.0.1:8080/status часть http задаёт протокол, 127.0.0.1 означает эту лабораторную машину, 8080 выбирает сервис, а /status — конечную точку, то есть определённый ответ сервиса. Настраивать сеть здесь не требуется.
curl http://127.0.0.1:8080/status
Тело имеет формат JSON: именованные поля и значения внутри фигурных скобок. Его нужно только прочитать, а не писать программу.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service и status полезны предполагаемой аудитории. internal_path раскрывает внутренний путь файла, а debug_details — сведения разработки. Знание пути само по себе не даёт доступа к файлу, но лишние подробности могут помочь спланировать дальнейшее исследование. Это раскрытие информации.
Добавьте параметр -i, чтобы увидеть заголовки HTTP над телом:
curl -i http://127.0.0.1:8080/status
В первой строке есть 200 OK: запрос выполнен успешно. Заголовки вроде Content-Type: application/json описывают тело; пустая строка отделяет их от него. Даты могут отличаться. Успех HTTP не означает безопасность ответа — именно этот успешный ответ раскрывает информацию.
Прочитайте конфигурацию сервиса, то есть файл используемых приложением настроек:
cat service.conf
[service] объединяет настройки в группу. Строка с # в начале — поясняющий комментарий. debug = true — логический переключатель: true включает диагностику разработки, false отключает. Комментарий связывает параметр с раскрываемыми полями состояния.
Применение Исправленной Конфигурации
Отладочные сведения помогают разработчикам искать проблемы. Однако полезный при разработке параметр может не подходить аудитории, которой нужен лишь публичный статус. DevSecOps включает безопасность в совместную работу разработки и эксплуатации: определить допустимую видимость, изменить конфигурацию и проверить реальный результат.
Откройте конфигурацию в nano, текстовом редакторе терминала. Перемещайтесь к настройке стрелками. Для следующих сочетаний удерживайте Ctrl при нажатии буквы:
nano service.conf
Замените только debug = true на debug = false. Сохраните заголовок [service] и комментарий. Нажмите Ctrl+O, Enter для сохранения и Ctrl+X для выхода. Проверьте файл:
cat service.conf
Он должен выглядеть так:
[service]
## Include development diagnostics in status responses.
debug = false
Файл на диске и работающая программа — разные вещи. Этот сервис читает настройки при запуске, поэтому сохранение само по себе не меняет ответ. В курсе предоставлен restart.sh, позволяющий применить конфигурацию без самостоятельного управления процессами. bash запускает этот готовый скрипт; редактировать его не требуется.
bash restart.sh
Ожидаемый вывод:
DeskLite restarted.
Снова запросите ту же конечную точку с заголовками:
curl -i http://127.0.0.1:8080/status
Ожидаются 200 OK и такое тело:
{
"service": "DeskLite",
"status": "running"
}
Оба внутренних поля исчезли, а полезный статус сохранился. Если поля остались, проверьте сохранение service.conf и выполнение перезапуска. Если скрипт сообщает об ошибке конфигурации, восстановите заголовок и написание логического значения по образцу выше и повторите. Не заменяйте приложение и не останавливайте сервис, чтобы скрыть ответ.
Совместная Проверка Безопасности и Бизнес-Функции
На этом шаге вы проверите, что исправление сохраняется после ещё одного перезапуска и DeskLite продолжает обслуживать пользователей.
Поломка сервиса тоже убрала бы ответ, но вместе с полезными возможностями. Поэтому нужны два свидетельства: чувствительных полей нет, а штатный сервис работает. Проверка работоспособности показывает базовую готовность; бизнес-запрос тестирует функцию, которая действительно нужна пользователям.
Перезапустите сервис ещё раз, чтобы подтвердить применение сохранённого параметра:
bash restart.sh
Снова проверьте состояние:
curl -i http://127.0.0.1:8080/status
Ожидаются 200 OK, service и status, но не internal_path и не debug_details. Теперь запросите конечную точку работоспособности:
curl -i http://127.0.0.1:8080/health
Ожидаются 200 OK и:
{
"status": "ok"
}
Наконец, запросите бизнес-функцию:
curl -i http://127.0.0.1:8080/tickets
Ожидаются 200 OK и исходное обращение:
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
Здоровый процесс сам по себе не доказывает доступность обращений. Вместе эти запросы показывают устранение раскрытия и сохранение нужной функции. curl может также показывать индикатор передачи; оценивайте код HTTP и тело, а не этот индикатор.
В завершение объясните себе, почему 200 OK сам по себе не доказывает безопасность и почему одной проверки работоспособности недостаточно для подтверждения бизнес-функций. Это размышление для понимания; письменный ответ не требуется.
Резюме
Вы использовали curl и curl -i для чтения HTTP-ответа, отличили успешный запрос от безопасного ответа и связали раскрываемые поля с логическим переключателем. Вы сохранили настройку, перезапустили DeskLite и подтвердили, что статус, работоспособность и обращения доступны без внутренней диагностики.
Вы проверили реальную конфигурацию и работающий сервис, включая ещё один перезапуск. Этот небольшой процесс связывает параметры разработки, работу сервиса и проверку безопасности. Следующее испытание переносит те же навыки на другой подготовленный сервис.
