Ошибки при поиске уязвимостей, которые обычно портят всю картину
 

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

Еще одно слабое место — наложение слишком общих фильтров при тестах, из-за чего реальные проблемы не проявляются или почему-то считаются ложными срабатываниями. Надо всегда пытаться вручную подтягивать детали, просто автоматами здесь не отделаешься. И не забывать, что некоторые типичные уязвимости уже даже не считаются критичными, а вот старые добрые XSS или CSRF стабильно работают против невнимательных.

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

Как обычно у вас с настройкой окружения для тестов? Есть дело с имитацией разных версий веб-серверов в локалке или все на реальном «проде» гоняете? Интересно, кто как работает с этим сейчас, чтобы не пропустить важное из-за мелкой ошибки.

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

Часто сами авторы сайтов оставляют тонкие лазейки, типа default-паролей или debug-режима включенного на проде, и это проходится мимо из-за фокуса на сложных багов. Ну и правда — автоматами проверка базовых настроек почти всегда проскакивает, приходится руками цеплять, особенно если куча разных версий компонентов.