Как я могу дальше исследовать причину ошибки сервера, вызывающей утечку информации?

Вопрос или проблема

Короче говоря, я случайно обнаружил, что на одном из внутренних сайтов на работе есть какая-то ошибка входа. В течение дня, когда я пытаюсь войти, я могу получить доступ к панели управления другого пользователя. Учитывая мои ограниченные возможности, я могу видеть только саму ошибку, но не знаю, как исследовать её дальше. Я пробовал много вещей, но идей у меня больше нет.

##Дополнительная информация:

#Процесс входа:

Сайт требует простой GET-запрос для входа, где имя пользователя и пароль отправляются в полезной нагрузке в двух простых текстовых переменных. Затем сайт возвращает куки .ASPXAUTH, которое используется для дальнейших запросов для аутентификации.

#Ошибка:

Кажется, в случайные моменты времени, когда я вхожу, сайт возвращает панель управления другого человека. Если я быстро обновлю страницу, я могу получить ту же неправильную панель несколько раз, прежде чем снова увижу свою. Обычно я использую программу на Python для парсинга этого сайта для получения информации, и программа входит каждые несколько минут, чтобы проверить данные. Но то же самое происходит время от времени, если я использую браузер.

#Настройка:

Сайт использует какое-то решение Microsoft для хостинга на локальном сетевом сервере. Все в компании используют VPN-клиент, что означает, что каждый компьютер доступен с локальным адресом, однако каждое устройство получает IP-адрес из подсети /24, и трафик между подсетями управляется тем же компьютером, который управляет шлюзом. Сервер тот же, но сайт доступен только через определённый порт.

#Что я проверил:

Вскоре после того, как я это обнаружил, я создал программу мониторинга, которая входит каждые пять секунд и записывает большинство процессов. У меня есть логи моего локального и глобального IP-адреса, времени, которое требуется серверу для ответа, содержимого полученных заголовков после входа, куки, предоставленные сервером, времени между ошибочными ответами и содержимого панели управления, когда происходит ошибка.

  • На протяжении всего дня IP-адреса не изменялись.
  • Время, которое требуется серверу для ответа, стабильно, связи с ошибкой нет.
  • Повторного использования каких-либо аутентификационных куки, которое я заметил, не было.
  • Нет изменений маршрута сети, связанных с ошибкой.
  • Не замечено истечения времени аренды DHCP в момент возникновения ошибки.
  • Я пробовал изменить свой IP на тот, который, как известно, используется для входа, и проверял, использует ли сервер это для подтверждения входов, но тоже не повезло.
  • Время между каждым ошибочным ответом, похоже, случайное, и нет видимого шаблона (нет связи с занятостью офиса).
  • Чаще всего пользователь, с чьей панели управления я вижу, новый, но есть несколько пользователей, которые появлялись несколько раз раньше.

#Что я не могу сделать:

Поскольку это корпоративный ноутбук, я не смог углубиться в мониторинг сети. У меня есть права администратора в терминале и оболочке, но есть некоторые ограничения. Я могу запускать скрипты на Python, так что есть довольно много вещей, которые я могу зафиксировать, но библиотеки для глубокого мониторинга сети не работают. У меня нет доступа ко всем сетевым устройствам и серверам, так что я не могу проверять вещи с другой стороны.

##Какие у меня варианты? Я не вижу причин или шаблона, почему эта ошибка происходит, и у меня больше нет идей, что проверить. Как мне двигаться дальше с этого момента?

(Чтобы быть ясным, я сообщил об этой проблеме управляющему персоналу, но прошло больше года, и ее все еще не исправили, так что я хочу обратиться напрямую к разработчикам. Но без какой-либо информации о том, почему это происходит, я не вижу смысла. И, похоже, гораздо интереснее провести небольшое расследование, чтобы выяснить причину иLearn from it.)

Любая помощь будет очень appreciated.

Ответ или решение

Как провести исследование причины ошибки сервера, вызывающей утечку информации

Открыть проблему утечки информации в веб-приложении требует системного подхода и тщательного анализа. В данной ситуации, для расследования ошибки, связанной с доступом к чужим панелям управления, предлагаю следующий план действий:

1. Анализ процесса аутентификации

Первый шаг в диагностике проблемы — это глубокий анализ процесса входа в систему. Поскольку информация о пользователе отправляется через GET-запрос, важно убедиться, что:

  • Передача данных: Проверьте, как передаются данные аутентификации, и убедитесь, что они не кэшируются. Возможно, сервер неправильно обрабатывает запрос, что приводит к возврату информации о другом пользователе.

  • Проверка сессий: Убедитесь, что система правильно контролирует сессии пользователей. Вероятно, что проблема заключается в неправильной реализации механизма сессий, где одна сессия может быть перепутана с другой.

2. Проверка куки и заголовков

Следующим шагом будет анализ кук и заголовков ответа от сервера. Обратите внимание на следующее:

  • Куки: Убедитесь, что уникальные идентификаторы сессии (например, .ASPXAUTH) генерируются и ассоциируются с конкретным пользователем. Если кук используется несколько раз для разных пользователей, это может быть источником проблемы.

  • Заголовки ответа: Анализируйте заголовки, возвращаемые сервером после входа. Убедитесь, что информация о пользователе в заголовках не смешивается.

3. Логирование

Вы уже начали протоколировать важные аспекты, но вы можете расширить свою систему логирования:

  • Запись полных запросов и ответов: Создавайте лог-файлы, которые содержат как запросы, так и ответы сервера, включая все заголовки и тело. Это поможет выявить аномалии.

  • Мониторинг состояния сервера: Попросите администратора сервера о возможности временного подключения к системам мониторинга. Это даст доступ к лечению производительности и активности сервера.

4. Анализ кода

Хотя у вас нет доступа к коду, попробуйте получить подробности о реализации аутентификации:

  • Системная документация: Запросите техническую документацию или схему архитектуры приложения у разработчиков. Концептуальное понимание системы может дать подсказки о возможных проблемах.

  • Обратный подход: Попробуйте создать большее количество сценариев, при которых происходит ошибка, тем самым демонстрируя наличие уязвимости, чтобы привлечь внимание разработчиков.

5. Обсуждение с разработчиками

Как только вы соберете достаточно данных, попытайтесь организовать встречу с разработчиками или техническим специалистом. Поделитесь собранными логами и объяснениями. Возможно, они смогут оценить проблему более детально.

6. Этические аспекты

Помните, что рассматривать любую информацию, к которой вы получаете доступ, следует с соблюдением этических норм. Убедитесь, что все ваши действия соответствуют внутренним регламентам компании.

Этот план действий стоит рассмотреть как основу для дальнейшего углубленного анализа. Проявляя настойчивость и проактивный подход, вы сможете не только выявить корень проблемы, но и узнать больше о веб-разработке и системном администрировании. Ваши усилия могут оказать значительное влияние на безопасность сервиса и его пользователей.

Оцените материал
Добавить комментарий

Капча загружается...