Одной из самых распространенных и болезненных задач, с которыми вам придётся сталкиваться, проводя тестирование на проникновение - это повторное тестирование.
Если вам повезет, то повторное тестирование будет быстрым и безболезненным!
Однако в большинстве случаев у вас будут те же проблемы, которые могут возникнуть во время основного тестирования: ожидание среды, ожидание учетных данных, ожидание действительных учетных данных ... Иногда вам будет предоставлен отчет (в некоторых случаях от вашего соперника) со списком проблем, и вы поймете, что это довольно хороший способ оценить качество чужого отчета!
Всегда составляйте свой отчет так, будто человек, который в конечном итоге будет перепроверять ваши результаты, является яростным психопатом, знающим ваш домашний адрес.
Никому не хочется, чтобы повторное тестирование занимало столько же времени, сколько и основное!
Сколько времени вам может понадобиться, чтобы перепроверить проблему из отчета, который вы никогда не видели раньше?
Во время повторного тестирования вы быстро узнаете разницу между:
Во втором предложении у вас есть практически все необходимое для повторного тестирования проблемы; в первом предложении, у вас нет практически ничего.
Быть готовым - это лучший способ избежать траты времени!
Самый простой способ - иметь скрипт для повторной проверки каждой проблемы. Я знаю, по крайней мере, одну компанию, которая использует автоматизацию браузера (то есть: управление браузером с помощью таких инструментов, как Watir, Selenium или
Другие компании сохраняют запросы Burp, чтобы обеспечить, по крайней мере, необходимый минимум относительно данной уязвимости. Вероятно, намного лучше держать каждый случай тестирования уязвимости в отдельном файле, чем иметь один большой файл (опция по умолчанию в Burp Suite) со всеми деталями о проведенном вами тестировании (важно помнить, что повторное тестирование может понадобиться даже несколько лет спустя). Наряду с этими файлами, как правило, необходимо сохранять поэтапное объяснение того, каким образом вы получили те или иные результаты.
Например, для уязвимости к Межсайтовому скриптингу:
Войдите как user1 или как любой другой пользователь, который обладает правами “Стандартного пользователя”
Вы сохраните себе огромное количество времени (или сохраните кому-то огромное количество времени) если вы потратите совсем немного больше вашего времени на то, чтобы указать все необходимые детали.
Вы можете предоставить всю эту информацию как часть отчета (в разделе Приложение) или в папке со всей информацией, которую вы использовали/используете во время тестирования, а также всеми журналами и выводами всех ваших инструментов. Исключая эту информацию из основного отчета, вы делаете более точным описание, и размер отчета становится приемлемым.
Еще один момент заключается в том, что если у вас есть положительный или отрицательный результат тестирования, то это позволит вам провести быструю проверку для того, чтобы убедиться в том, что что-то изменилось. Это не обязательно означает, что уже какие-либо проблемы были исправлены. Вы возможно найдете другой payload, который позволит вам обойти исправления, сделанные разработчиками или системными администраторами.
Вы также должны быть готовы к случаям, когда вас попросят провести повторное тестирование приложения, в котором, не смотря на ваши рекомендации и предостережения, ничего не было изменено, и оно остается настолько уязвимым, насколько было на момент основного тестирования. Это довольно неприятная (но, к сожалению, частая) ситуация, особенно если вы работаете на большую компанию, но важно понимать, что вашим клиента не обязательно видеть сам процесс исправления. Иногда вы даже сталкиваетесь с людьми, которые сообщают команде по обеспечению безопасности, что всё было исправлено и восстановлено, не смотря, что абсолютно ничего из сказанного не было сделано. Они так говорят только для того, чтобы избавиться от лишних задач и перейти к своим повседневным обязанностям.
Надеюсь, эта статья убедила вас в том, что повторная проверка может быть намного проще, если вы потратите немного больше времени на то, чтобы максимально точно записать то, что вы делали во время основного тестирования.
Источник:
Если вам повезет, то повторное тестирование будет быстрым и безболезненным!
Однако в большинстве случаев у вас будут те же проблемы, которые могут возникнуть во время основного тестирования: ожидание среды, ожидание учетных данных, ожидание действительных учетных данных ... Иногда вам будет предоставлен отчет (в некоторых случаях от вашего соперника) со списком проблем, и вы поймете, что это довольно хороший способ оценить качество чужого отчета!
Всегда составляйте свой отчет так, будто человек, который в конечном итоге будет перепроверять ваши результаты, является яростным психопатом, знающим ваш домашний адрес.
Никому не хочется, чтобы повторное тестирование занимало столько же времени, сколько и основное!
Сколько времени вам может понадобиться, чтобы перепроверить проблему из отчета, который вы никогда не видели раньше?
Во время повторного тестирования вы быстро узнаете разницу между:
- “Приложение уязвимо к XSS”
- “Параметр под названием msg на странице/login.jsp отсылается обратно, без кодирования, что приводит к XSS”
Во втором предложении у вас есть практически все необходимое для повторного тестирования проблемы; в первом предложении, у вас нет практически ничего.
Быть готовым - это лучший способ избежать траты времени!
Самый простой способ - иметь скрипт для повторной проверки каждой проблемы. Я знаю, по крайней мере, одну компанию, которая использует автоматизацию браузера (то есть: управление браузером с помощью таких инструментов, как Watir, Selenium или
Ссылка скрыта от гостей
), чтобы выполнить большую часть необходимого повторного тестирования. Это позволяет тестировщикам легко перепроверять проблему в полностью работающем браузере и быстро получать обратную связь о том, были ли изменены какие-либо вещи или нет.Другие компании сохраняют запросы Burp, чтобы обеспечить, по крайней мере, необходимый минимум относительно данной уязвимости. Вероятно, намного лучше держать каждый случай тестирования уязвимости в отдельном файле, чем иметь один большой файл (опция по умолчанию в Burp Suite) со всеми деталями о проведенном вами тестировании (важно помнить, что повторное тестирование может понадобиться даже несколько лет спустя). Наряду с этими файлами, как правило, необходимо сохранять поэтапное объяснение того, каким образом вы получили те или иные результаты.
Например, для уязвимости к Межсайтовому скриптингу:
Войдите как user1 или как любой другой пользователь, который обладает правами “Стандартного пользователя”
- Нажмите на ссылку «Мой профиль» (“My profile”)
- Нажмите “редактировать”
- Затем нажмите “сохранить” с помощью Burp в режиме «Перехват» (“Intercept”).
- Поместите свою payload (обычно <script>alert(1);</script>) в параметр “firstname” используя Burp
- Выйдите из системы и войдите в систему под тем же пользователем и посетите страницу «Мой профиль» (“My profile”), появится окно с предупреждением
- Вы уже знаете, какого пользователя и с какими правами вам нужно использовать, чтобы протестировать данную проблему.
- Вы знаете, куда вам необходимо поместить payload.
- Вы знаете, что должны быть некоторые проверки JavaScript, препятствующие прямому использованию payload в браузере (“используя Burp”).
- Вы знаете, какой именно payload работает.
- Вы знаете, что ответ не содержит payload напрямую, и что вам сначала нужно выйти из системы (возможно для того, чтобы избежать определенного механизма сессии/кэширования) .
- Вы знаете, куда нужно заглянуть, чтобы найти, где запущена payload.
Вы сохраните себе огромное количество времени (или сохраните кому-то огромное количество времени) если вы потратите совсем немного больше вашего времени на то, чтобы указать все необходимые детали.
Вы можете предоставить всю эту информацию как часть отчета (в разделе Приложение) или в папке со всей информацией, которую вы использовали/используете во время тестирования, а также всеми журналами и выводами всех ваших инструментов. Исключая эту информацию из основного отчета, вы делаете более точным описание, и размер отчета становится приемлемым.
Еще один момент заключается в том, что если у вас есть положительный или отрицательный результат тестирования, то это позволит вам провести быструю проверку для того, чтобы убедиться в том, что что-то изменилось. Это не обязательно означает, что уже какие-либо проблемы были исправлены. Вы возможно найдете другой payload, который позволит вам обойти исправления, сделанные разработчиками или системными администраторами.
Вы также должны быть готовы к случаям, когда вас попросят провести повторное тестирование приложения, в котором, не смотря на ваши рекомендации и предостережения, ничего не было изменено, и оно остается настолько уязвимым, насколько было на момент основного тестирования. Это довольно неприятная (но, к сожалению, частая) ситуация, особенно если вы работаете на большую компанию, но важно понимать, что вашим клиента не обязательно видеть сам процесс исправления. Иногда вы даже сталкиваетесь с людьми, которые сообщают команде по обеспечению безопасности, что всё было исправлено и восстановлено, не смотря, что абсолютно ничего из сказанного не было сделано. Они так говорят только для того, чтобы избавиться от лишних задач и перейти к своим повседневным обязанностям.
Надеюсь, эта статья убедила вас в том, что повторная проверка может быть намного проще, если вы потратите немного больше времени на то, чтобы максимально точно записать то, что вы делали во время основного тестирования.
Источник:
Ссылка скрыта от гостей
