сайт для поиска багов
Как искать баги начинающему тестировщику?
Перед тем как начать поиск, вспомним что такое баги. Баги и дефекты обнаруживаются тестировщиком при сравнении ожидаемого и реального результата работы программы. Багом может быть любая ошибка, которая вызывает неправильную или непредсказуемую работу приложения.
Что должен знать тестировщик?
В процессе тестирования специалисту приходится работать с большими объемами информации. QA-инженер старается удержать в голове различные варианты проверок. Структурно их можно заключить в следующие вопросы:
Ответом на этот вопрос должна быть четко сформулированная цель и назначение программы. В случае если тестировщик знаком с продуктом поверхностно, процент пропущенных дефектов сильно возрастет. Определите области, которые будут протестированы, а также основные пользовательские сценарии.
Это взаимосвязь глобальной цели приложения и его более мелких задач. После того как мы удостоверились, что основная функциональность работает, переходим к менее стандартным сценариям.
Провести тестирование программы с негативной точки зрения. Сюда входит ввод неверных данных и вызов исключительных ситуаций. Сценарии в этом случае направлены на проверку устойчивости системы.
В этом случае речь идет о пользователях, для которых предназначена разработка. Зачастую тестировщики проверяют продукт, ничего не зная о тех людях, которые будут использовать приложение.
Как взаимодействуют с приложением разные пользователи?
Попробуйте описать портреты разных пользователей и их взаимодействие с приложением в зависимости от определенных параметров. Такими параметрами могут быть сфера занятости, интересы, особенности поведения, черты характера и привычки.
Сценарии тестирования, построенные на основе этих данных, помогут оптимизировать продукт под потребности потенциальных пользователей.
Персонализирование – это мощный инструмент, который позволяет осознанно перенять чувства и привычки разных людей. Применение такого инструмента в тестировании помогает обнаруживать различные по типу дефекты и прийти к нестандартным сценариям. В то время как отсутствие персонализации может привести к потере контакта между приложением и потенциальными пользователями.
Приведем пример из шести универсальных персонажей, которые могут использовать приложение.
Менеджер
Менеджер – занятой человек, он работает с приложением между встречами. Он нетерпелив и иногда не сосредоточен, так как все делает в спешке.
Для менеджера будут приоритетными горячие клавиши, максимально быстрое заполнение полей, отсутствие ошибок при быстром завершении, автосохранение, скорость загрузки.
Ищем баги в процессе заполнения форм, скорости их отправки, адресов, по которым идет отправка, проверяем точно ли описаны этапы заполнения и требования к итоговому варианту.
Хипстер
Хипстер любит исследовать новые функциональные возможности и области приложения, которые находятся за пределами главного экрана. Он заядлый исследователь.
Хипстера будут интересовать новые функции, недавно добавленные в приложение, непопулярные области приложения, нестандартный ввод данных, доступ к приложению из необычных браузеров, операционных систем, устройств.
Баги стоит искать в кроссплатформенности, адаптивности, проверке введенных данных, взаимодействии старой и новой функциональности приложения.
Осторожный
Осторожный пользователь предпочитает рутинные операции, которые должны хорошо работать. Его процессы будут повторяться в каждой сессии.
В этом случае для пользователя будут важны популярные функции приложения. Он также обратит внимание на любые изменения интерфейса, заполнит все поля в форме наиболее полно, будет многословен в полях для комментариев и терпеливо подождет ответа приложения.
Поиск багов стоит начать с наиболее используемых функций, затем следует проверить ограничения по количеству символов в полях форм, убедиться в работоспособности всех элементов интерфейса, а также в том, что при долгой загрузке приложение остается работоспособным.
Проказник
Проказник любит ломать вещи. Он знает о проблемах безопасности и любит исследовать, чтобы убедиться в том, что приложение может защитить его данные.
Его заинтересуют SQL и JavaScript-инъекции, манипулирование URL-адресами, получение доступа к личной информации, нарушение ограничений на поля ввода и генерация сообщений об ошибках.
Ищем баги в доступе к секретной информации, проверяем работоспособность всех уведомлений об ошибках и ограничений.
Путешественник
Путешественник сейчас на другом конце света. Он использует приложение редко и в основном в нерабочее время.
Путешественник будет получать доступ к приложению из разных мест и часовых поясов. Он попытается использовать различные браузеры и устройства, а также медленный и ненадежный интернет.
Проверяем наличие дефектов в кроссплатформенности и адаптивности, возможности использования различных раскладок клавиатуры, ограничений на ввод символов иностранных языков, а также стабильности работы приложения при плохом подключении к сети.
Взрослый
Взрослый относится к старшему поколению и имеет небольшие знания в области вычислительной техники. Имеет определенные трудности с пониманием работы приложения.
Взрослый пользователь будет медленно прокручивать экран и подолгу оставаться на одной странице, часто использовать кнопки «Назад» и «Отменить».
Здесь необходимо искать баги в настройках шрифта, яркости и других элементах интерфейса. Проверяем, срабатывают ли окна онлайн-помощи, работает ли приложение с устаревшими технологиями, включая старые версии браузеров и операционных систем.
В заключение
Как мы видим, даже тестировщик без опыта работы сможет справиться с поиском некоторых багов. Попробуйте протестировать знакомый сайт или приложение, а если понравится – обязательно подавайте заявку на курсы по тестированию.
Изучайте теорию, практикуйтесь в тест-дизайне. Чтобы стать QA-инженером, важно желание разбираться в том, как этот продукт работает сейчас и как он должен работать в принципе.
Если же вы уверены в своих силах, перед собеседованием на должность тестировщика обязательно подготовьтесь к задачкам на логику.
Вопрос от новичка! Нужно найти баг где угодно!?
В общем для прохождения собеседования дали задание:
1. Найти баг на любом популярном сайте (контакт, фейсбук, инстаграмм, olx и т.д.). Критичность бага не имеет значения.
2. Зарегистрироваться в багтрекере Mantis по адресу http://mantisx.cf/ (если письмо подтверждения регистрации не пришло, проверьте папку «спам» или используйте другой почтовый сервис).
3. Занести найденный баг в багтрекер
С Мантисом проблем не будет. Но сама постановка задачи меня смутила. Перерыв пару десятков популярных ресурсов и потратив 2 дня в пустую (хотя может и не впустую), я не обнаружил ничего. Понимание что я или ничего не знаю или не понял суть задачи не выходит у меня из головы.
Нужно Ваше мнение по данному вопросу?
Выберите какой-нибудь любимый сайт, например, интернет-магазин, спортивный сайт и т.п.
И поищите там баги
Вот и я в недоумении, или я чего-то не понимаю-не знаю или задание поставлено некорректно.
Корректно или нет, это смотря зачем задача поставлена именно так, и сознательно ли она поставлена так.
ИМХО, она даст ответы на следующие вопросы:
1. Понимает ли кандидат в каких продуктах( типах сайтов, зависимость от серьёзности разработчика) стоит начать искать баги в первую очередь и как он обоснует свой выбор.
2. Какого типа баги будет искать кандидат, предполагая уровень исследуемого объекта, в первую очередь.
По вашим «2 дням потраченным вхолостую» можно сделать определенные выводы.
Корректно или нет, это смотря зачем задача поставлена именно так, и сознательно ли она поставлена так.
ИМХО, она даст ответы на следующие вопросы:
1. Понимает ли кандидат в каких продуктах( типах сайтов, зависимость от серьёзности разработчика) стоит начать искать баги в первую очередь и как он обоснует свой выбор.
2. Какого типа баги будет искать кандидат, предполагая уровень исследуемого объекта, в первую очередь.
По вашим «2 дням потраченным вхолостую» можно сделать определенные выводы.
Я в стартпосте не совсем правильно выразился. Не совсем впустую, я написал целый ряд тест-кейсов протестировав юзабилити/кроссбаузерность/кроссплатформенность ресурса. В код я лезть немогу т.к. у меня нет ТЗ или спека. Багов за данный период в том разрезе что я делал не нашёл. Согласен что имею весьма малый опыт тестирования веб-ресурсов, возможно не всё что нужно сделать знаю.
Корректно или нет, это смотря зачем задача поставлена именно так, и сознательно ли она поставлена так.
ИМХО, она даст ответы на следующие вопросы:
1. Понимает ли кандидат в каких продуктах( типах сайтов, зависимость от серьёзности разработчика) стоит начать искать баги в первую очередь и как он обоснует свой выбор.
2. Какого типа баги будет искать кандидат, предполагая уровень исследуемого объекта, в первую очередь.
По вашим «2 дням потраченным вхолостую» можно сделать определенные выводы.
Я в стартпосте не совсем правильно выразился. Не совсем впустую, я написал целый ряд тест-кейсов протестировав юзабилити/кроссбаузерность/кроссплатформенность ресурса. В код я лезть немогу т.к. у меня нет ТЗ или спека. Багов за данный период в том разрезе что я делал не нашёл. Согласен что имею весьма малый опыт тестирования веб-ресурсов, возможно не всё что нужно сделать знаю.
Если вы за 2 дня тестирования » пары десятков популярных ресурсов » не нашли совсем ни одного бага, то возможно вы не понимаете что такое баг? 🙂 Например, в ФБ есть группа Панбагон, там ежедневно люди выкладывают по несколько интересных багов, на которые они наткнулись просто используя повседневные продукты.
Если вы за 2 дня тестирования «пары десятков популярных ресурсов» не нашли совсем ни одного бага, то возможно вы не понимаете что такое баг? 🙂 Например, в ФБ есть группа Панбагон, там ежедневно люди выкладывают по несколько интересных багов, на которые они наткнулись просто используя повседневные продукты.
Если вы за 2 дня тестирования «пары десятков популярных ресурсов» не нашли совсем ни одного бага, то возможно вы не понимаете что такое баг? 🙂 Например, в ФБ есть группа Панбагон, там ежедневно люди выкладывают по несколько интересных багов, на которые они наткнулись просто используя повседневные продукты.
а кто тут говорил про главную яндекса? 🙂 речь шла о » паре десятков популярных ресурсов «, вы хотите сказать, что на паре десятков ресурсов за два дня тщательного изучения невозможно найти ни одного бага? 🙂
Если вы за 2 дня тестирования «пары десятков популярных ресурсов» не нашли совсем ни одного бага, то возможно вы не понимаете что такое баг? 🙂 Например, в ФБ есть группа Панбагон, там ежедневно люди выкладывают по несколько интересных багов, на которые они наткнулись просто используя повседневные продукты.
Одна на главной странице и еще одна на странице Яндекса, которая открывается с главной)
Тыкните меня носом в баги на главной Яндекса?
1. Заходим на www.yandex.ru и мотаем вниз до значка
ya-help.png 4,18К 6 Количество загрузок:
2. Переходим на страницу помощи (https://yandex.ru/support) и в самом низу ищем строку копирайта 2015-2016 ya-copyright.png 1,94К 3 Количество загрузок:
На странице https://yandex.ru/company тоже самое ООО «Яндекс» идет 1997-2016
И вообще у них с этим копирайтом полный бардак на каждом сервисе))
P.S. Не смог найти форму обратной связи, чтобы выяснить подробности у службы поддержки.
На странице https://yandex.ru/company тоже самое ООО «Яндекс» идет 1997-2016
И вообще у них с этим копирайтом полный бардак на каждом сервисе))
P.S. Не смог найти форму обратной связи, чтобы выяснить подробности у службы поддержки.
Я конечно не юрист, но даты указывают время первой публикации защищаемых копирайтом материалов (диапазон дат для нескольких материалов). Логично, что разные сервисы и страницы, созданные в разное время, имеют разные даты копирайта.
У меня другая информация, поэтому я и хотел найти форму обратной связи.
С Мантисом проблем не будет. Но сама постановка задачи меня смутила. Перерыв пару десятков популярных ресурсов и потратив 2 дня в пустую (хотя может и не впустую), я не обнаружил ничего. Понимание что я или ничего не знаю или не понял суть задачи не выходит у меня из головы.
Как по мне, задача поставлена хоть и простецки, но вполне имеет право на существование.
К примеру, я почти каждый день сталкиваюсь с багами на сайтах, даже недавно решил в блог выкладывать, адрес блога кстати в подписи.
9 лучших инструментов для отслеживания багов и проблем
Работа тестировщика заключается в обнаружении, записи, отслеживании, управлении и составлении отчетов об ошибках. Кроме того, вы можете с любовью относиться к тестеру как к искателю ошибок. Мы, конечно же, можем легко отслеживать или записывать все ошибки или проблемы, которые мы находим в писке Еxcel, и изучать его, когда в чем-то сомневаемся. Но, по мере расширения проекта, количество задействованных процессов и вовлеченной команды растет – что, в конечном счете, означает, что помимо ручного тестирования, которое мы использовали на начальных этапах, необходимо изменить методы, поскольку нам нужно обеспечить эффективное управление всем. Это поможет нам легко и последовательно находить больше проблем, чем те, которые были обнаружены ранее на предыдущих этапах.
И до настоящего времени мы сталкивались с различными программным обеспечением для отслеживания ошибок и даже инструментами управления дефектами.
Прежде всего, важно понять, зачем нужны инструменты отслеживания ошибок.
Когда дело доходит до любого веб-проекта или программного обеспечения, отслеживание ошибок — столь необходимый инструмент. Кроме того, необходимость этого инструмента понимается лучше, когда мы боремся с определенными аспектами проекта, в том числе отчетностью, документацией и отслеживанием ошибок, таких как проблемы, баги или сбои, которые могут приводить к искажению вашего веб-сайта или приложения. Здесь пригодится такой инструмент, как баг-трекер.
Итак, каковы некоторые из основных функций, которыми должен обладать инструмент отслеживания ошибок? Рассмотрим эти факторы:
Всякий раз, когда вы выбираете любой инструмент отслеживания ошибок, необходимо убедиться, что вышеупомянутые критерии выполняются.
Итак, давайте посмотрим, какие инструменты мы можем использовать, как часть системы отслеживания ошибок.
Plutora Test
Один из самых современных и корпоративных инструментов управления тестированием, Plutora, является эффективным инструментов, который будет оставаться прекрасным помощником в процессе всего тестирования программного обеспечения. Это будет сильная поддержка, начиная с этапа разработки (включая Каскадный процесс) и заканчивая подходом непрерывной поставки. Основанный на одном экземпляре, он работает одинаково для всех проектов, начиная с тестирования дизайна, планирования, автоматического и ручного выполнения, отслеживания дефектов, отчетности о ходе и повышении эффективности. Все эти процессы выполняются поэтапно. Он позволяет интегрироваться с набором связанных инструментов и систем, таких как Selenium и Jira. В отличие от других инструментов, Plutora обладает способностью создавать ощущение сотрудничества между командами, инструментов и систем — таких как Selenium и Jira. В отличие от других инструментов, Plutora обладает способностью налаживать взаимодействие между командами, работающими по аналитике, метрикам и возможностям отчетности — некоторые из основных моментов, которые вы можете найти только у этого инструмента. Еще одним важным моментом использования этого инструмента является то, что он настраивается и может быть адаптирован к отдельным командам, а также обеспечивает единый вид всей команды.
Bugzilla
Bugzilla была разработана командой Mozilla в 1998 году. И что интересно, Bugzilla является одним из наиболее широко используемых программных решений с открытым исходным кодом для отслеживания ошибок, которые доступны сегодня. Некоторые из функций включают в себя:
Вы можете добиться всего этого, запустив Bugzilla. Некоторые другие интересные факты о Bugzilla — это то, что инструмент написан на Perl. Кроме того, он совместим с несколькими базами данных, такими как Oracle, MySQL и PostgreSQL. Хотя команда Mozilla рекомендует использовать его с Apache 2.2 для обеспечения оптимальной производительности, на самом деле нет минимальных требований к веб-серверу. 
Backlog
Это онлайновое программное обеспечение для отслеживания ошибок и управления проектами, которое было создано для групп разработчиков. С помощью этого инструмента всем становится легче сообщать об ошибках вместе с полной историей проблем, комментариями, обновлениями и изменениями в статусе. Используя параметры поиска и фильтрации, вы можете легко найти сообщения о проблемах.
Помимо отслеживания этих ошибок, инструмент можно также использовать для управления ИТ-проектами с некоторыми интересными функциями, такими как диаграммы Gantt и Burndown, хранилища SVN, управление доступом к IP и Wiki и подзадачами. Кроме того, он хорошо работает с приложениями для Android и iOS.
Fossil
С помощью этой системы конфигурации программного обеспечения, также известной как Fossil, вы можете легко отслеживать ошибки. Кроме того, вы можете отслеживать ход разработки проекта. Хотя вы можете выбрать Fossil как решение для отслеживания ошибок, факт заключается в том, что он поставляется с множеством других интересных функций. В случае если вы хотите баг-трекер, скомпилированный со службой разработки, то это идеальный выбор для вас.
Он поставляется с некоторыми интересными функциями, такими как:
Когда вы выбираете Fossil для своей системы, вы предоставляете полный пакет инструментов для разработки и отслеживания ошибок, которые вы можете использовать для своего собственного веб-сервера или базы данных. Здесь система будет хранить информацию в SQLite. Этот SQLite фактически обеспечивает контроль версий с помощью Fossil. Вы должны архивировать все содержимое в ZIP-файл, а не оставлять их разбросанными по диску, что может затруднить доступ
Вместо того чтобы говорить, что Trac является своего рода специализированным инструментом отслеживания ошибок, мы бы сказали, что это больше система отслеживания проблем. Этот веб-инструмент отслеживания ошибок написан на Python. Интеграция Trac с системой SCM поможет вам загружать историю просмотров, код, просматривать изменения и многое другое. Проблемы, отслеживаемые Trac, часто называются «билетами», и эта система управления билетами также может использоваться для управления дефектами, если вам необходима помощь. 
Web Issues
Основной задачей Web Issues было помочь в совместной работе. Поскольку это настраиваемый инструмент с открытым исходным кодом, он предоставляет вам доступ к нему из любого веб-браузера или настольного клиента, который вы хотите.
Он поставляется с некоторыми из следующих функций:
Все просто, не правда ли? Возможно, это были инструменты отслеживания ошибок, которые вы искали.
Для веб-проблем потребуется PHP. Он будет работать в операционных системах OS X, OS / 2, Linux и Windows. И, как вы, возможно, не ожидали, он совместим с PostgreSQL, SQL Server и MySQL.
OTRS — это решение ITSM и справочная служба с открытым исходным кодом, которая в основном помогает отслеживать ошибки. С более чем 5000 членами сообщества и 170 000 установками, она широко используется в телекоммуникациях, образовании, потребительских продуктах, производстве, здравоохранении, правительственных и ИТ-отраслях. Независимо от вашего промышленного домена, это лучшая система, которую вы можете использовать для удовлетворения всех ваших потребностей. OTRS также является системой оформления билетов. Благодаря этому вы можете помочь в управлении ИТ-услугами, которые вы предоставляете, и они включают в себя покрытие всех ошибок. Некоторые из особенностей OTRS:
Test Track
Это лицензионный продукт. Вы можете найти его в разделе инструментов ALM. Кроме того, он обеспечивает полный набор решений для выполнения, управления дефектами и создания тестовых примеров.
Request Tracker
Этот инструмент доступен абсолютно бесплатно. И, как видно из названия, он помогает отслеживать запросы. В любой конкретной ситуации вы можете использовать его для обработки каждой ошибки, для которой вы получаете билет. Помогает. Попробуйте и посмотрите сами.
Всем успешной работы!
Vulners — Гугл для хакера. Как устроен лучший поисковик по уязвимостям и как им пользоваться
Часто нужно узнать всю информацию о какой-нибудь уязвимости: насколько найденный баг критичен, есть ли готовые сплоиты, какие вендоры уже выпустили патчи, каким сканером проверить наличие бага в системе. Раньше приходилось искать вручную по десятку источников (CVEDetails, SecurityFocus, Rapid7 DB, Exploit-DB, базы уязвимостей CVE от MITRE/NIST, вендорские бюллетени) и анализировать собранные данные. Сегодня эту рутину можно (и нужно!) автоматизировать с помощью специализированных сервисов. Один из таких — Vulners, крутейший поисковик по багам, причем бесплатный и с открытым API. Посмотрим, чем он может быть нам полезен.
Что это такое
Vulners — это очень большая и непрерывно обновляемая база данных ИБ-контента. Сайт позволяет искать уязвимости, эксплоиты, патчи, результаты bug bounty так же, как обычный поисковик ищет сайты. Vulners агрегирует и представляет в удобном виде шесть основных типов данных:
Все это обрабатывается, каталогизируется, структурируется и доступно для поиска в любой момент.
Вендоры, от которых собирается и анализируется инфа в Vulners
В отличие от других баз, которые описывают баги в специальном формализованном виде (например, на языке OVAL-баз CIS или SecPod), Vulners хранит данные в формализованном виде и автоматически устанавливает связи между ними, быстро ищет и красиво отображает результаты поиска. Что с этим делать, целиком зависит от фантазии конечного пользователя.
Кто и на чем пишет Vulners?
Весь движок Vulners написан на Python + Django, в качестве базы взята MongoDB + Elasticsearch. MongoDB используется только для закладки данных роботами — сборщиками информации, Elasticsearch только для фронтенда. Деплой производится с Bitbucket’а скриптом. Масштабирование заложено прямо в ядре: MongoDB и Elasticsearch шардятся. Фабрика роботов написана хостонезависимой и может гоняться отдельно от всего проекта. Одна из крутых фишек — ребята уже полностью перешли на Python 3.5+ и asyncio в своем проекте. Так что поиск не всегда работает точно, но всегда очень быстро :).
На текущий момент в базе Vulners 319 557 бюллетеней и 144 684 эксплоита. А занимает все это в базе меньше 2 Гбайт. Такая компактность достигается за счет дедупликации и упаковывания. Все лежит в оперативной памяти, поэтому скорость поиска значительно увеличивается. Стоит упомянуть и то, что Vulners защищается WAF Wallarm, работающим в блокирующем режиме.
Архитектура Vulners
Но довольно слов, давай попробуем что-нибудь поискать.
Пробуем искать
Первое, что видишь, когда заходишь на Vulners, — это, конечно же, строка поиска. Просто введи название приложения, сайта или CVE-код уязвимости, и Вульнерс выдаст тебе все последние публичные баги по этому продукту со ссылками на эксплоиты, плагины для детекта и различные публикации.
Типовая выдача Vulners по багам WordPress. Обрати внимание: данные обновляются постоянно и в автоматическом режиме
Естественно, простые запросы вроде «wordpress» или «xakep.ru» рассматривать скучно, с этим ты и сам разберешься. Давай посмотрим, что интересного умеет Vulners.
Задача: найти критичные баги CentOS со ссылками на сплоиты
Запрос: type:centos order:published
Vulners позволяет фильтровать результаты поиска и/или сортировать их по любому полю баги:
Благодаря этому мы можем сформировать сложный запрос типа type:centos cvss.score:[8 TO 10] order:published, что означает «найди мне все новые баги CentOS, где CVSS Score от 8 до 10, то есть критичный». Поскольку Вульнерс автоматически связывает с багой все собранные данные, на странице CVE ты увидишь доступные патчи и эксплоиты.
Графическое задание запроса
Получаем больше двадцати записей от Vulners
Задача: обосновать IT-департаменту, зачем нужен патч-менеджмент (или просто найти все сплоиты по определенной баге)
Запрос: cvelist:CVE-2014-0160 type:exploitdb
При помощи Vulners сравнительно просто обосновать IT-департаменту, почему уязвимости, обнаруженные сканером, действительно опасны и их стоит патчить. Для этого можно показать список эксплоитов, найденных по номеру CVE или другому идентификатору. Доступен поиск по Exploit-DB или Metasploit. На одной странице будет и описание, и исходники эксплоита, по которым также можно искать.
Ищем сплоиты по CVE–2014–0160
Как видим, на странице эксплоита приводится его полный текст. По этому тексту также можно искать.
Эксплоит можно просмотреть в удобной превьюшке
Задача: узнать, сколько денег и на каких bug bounty заработал определенный хакер
Запрос: isox order:bounty
Уникальная фича Vulners — поиск по баг-баунти. Можно найти, какие уязвимости софта зарепортил исследователь, и посмотреть его достижения в bug bounty программах. Результаты можно сортировать по командам, исследователям, цене и прочему.
Например, ищем по нику, сортируем по размеру вознаграждения за баг-баунти:
Пример поиска по bounty
Вульнерс нашел зарепорченную багу в Mail.Ru, за которую заплатили 400 долларов
А если уточнить в запросе reporter, можно считать чужие деньги, что стыдно, но любопытно.
Ищем зарепорченные на HackerOne баги по сервису Vimeo
Задача: найти баги по плагинам Nessus
Запрос: type:nessus order:published
Поиск по плагинам Nessus — также уникальная фича Vulners. Так, запрос выше выведет список последних добавленных плагинов.
Пример поиска по Nessus
Найденная уязвимость с GNU C Library
Задача: найти потенциальные уязвимости мобильных приложений
Еще одна крутая особенность Vulners — возможность искать по уязвимостям более чем 13 000 топовых Android-приложений из Google Play! Store US через базу HackApp. HackApp — это условно-бесплатный тулкит и сервис для поиска багов в мобильных приложениях. HackApp ведут свою базу найденных уязвимостей, где подробно описывают векторы атак и уязвимые версии.
С помощью Vulners и HackApp можно искать по уязвимостям более чем 22 025 топовых Android-приложений из Google Play! Store. Для поиска нужно указать тип type:hackapp. В результатах поиска отображается тайтл, количество уязвимостей по степени критичности и информация о приложении.
Поиск уязвимостей по базе HackApp
Работа с API
На момент написания статьи публично доступен только поисковый API. В JSON передается запрос и количество результатов (size), которое хочется получить. Максимальный размер выдачи — 10 000 записей. Хватит, чтобы утащить все бюллетени CentOS сразу. А чтобы забрать что-то совсем большое, за несколько раз, можно задать смещение с помощью параметра skip.
Поскольку Vulners использует Elasticsearch, любой запрос обрабатывается Apache Lucene. А это значит, что запросы к Vulners строятся точно так же, как к Lucene. Имена полей для поиска можно узнать в помощнике API. Любой ключ «схемы» для каждого типа коллектора можно использовать в качестве «ключа» в запросе Lucene, например:
Ответы также в JSON:
Бот для Telegram с подписками на результаты запроса
В апреле Vulners запустили бота для мессенджера Telegram. Пользоваться просто. Отправь боту сообщение /subscribe и свой поисковый запрос и получай новые результаты поиска, как только они будут появляться на Vulners. Но главное — с его помощью можно создавать настраиваемые подписки на security content.
Бот позволяет делать запросы, так же как на сайте.
Этот сервис может помочь безопасникам оставаться в курсе публикации новых уязвимостей. Ребята из эксплуатации могут подписаться на рассылки по программному обеспечению, которое используют. Пентестеры — оперативно получать информацию об эксплуатации уязвимостей на практике.
Хочешь просмотреть свежие публикации CVE? Нет проблем:
Хочешь видеть апдейты по эксплоитам?
Твои серверы работают под Debian? Следи за их безопасностью!
А у Vulners есть альтернативы?
Vulners — не единственный агрегатор уязвимостей. Есть, к примеру, базы Secunia и OSVDB, но одна закрылась 5 апреля, а другая платная.
Еще существует отечественный БнД УБИ ФСТЭК, но они хранят только описания самих уязвимостей и больше ничего (нет данных об эксплоитах), да и те, честно говоря, формализованы не очень. К тому же «Банк данных угроз безопасности информации» не предоставляет открытого API, то есть использовать его в автоматизированных сканерах не получится.
Выводы
Vulners — уникальный и незаменимый помощник любому хакеру и безопаснику. Он очень сильно экономит время при исследовании и эксплуатации сложных векторов атак. Конечно, инструмент только развивается, но уже сейчас он вполне юзабелен. А что еще более важно, Vulners открытый и бесплатный для конечного пользователя и всегда будет таким.