Модульный паук, ищущий уязвимости на сайтах.

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

Для начала пара примеров: http://cirt.net/nikto2 и https://code.google.com/p/webvulscan/ Это примерно то, что нужно. Однако если вы посмотрите к примеру на этот http://nikto.xmlshop.biz/report.php?id=9101845456 отчет, то увидите что там довольно много ложных срабатываний. В основном они появляются изза того, что паук не интересуется содерджимым ответа и не проверяет очевидные параметры. Скажем последняя ссылка в этом репорте хороший пример.

Я не требую от вас построить паука, который будет находить все ошибки. Мне нудно просто чтобы он во-первых давал мало ложных срабатываний, во-вторых не выводил кучей похожие проблемы, в-третьих не выводил кучу одинаковых ошибок(посмотрите в примере все ошибки вида «Apache default foreign language file found.») и, самое главное, ошибки должны быть страшны для неграмотного человека. Скажем обнаруженый подобный файл http://www.wootronics.com/htaccess.txt - это внушает. Человек, хозяин сайта, глядя на эту ссылку понимает что во-первых на его сайте оказывается есть модули о существовании которых он не знает, а во-вторых там какой-то код, что-то важное и как бы явно что-то не так. Целевая аудитория – владельцы бизнеса, которые хотят проверить что там у них на сайте делается.

Еще момент: От вас требуется только сам паук умеющий принимать запрос и отвечать списком ошибок. Интерфейс, где и как оно работает – это все отдельно будет делаться. В ваш паук отдается запрос (домен + ID запроса + быстрый/медленый скан), вы через какое-то время, после скана, отвечаете в заданый УРЛ списком проблем + ID). Еще к вам могут стукнуться с ID – вы отвечаете процентом выполненого скана примерным, но это так, потом и опционально.

Теперь по работе паука: у вас есть каркас, собственно паук. Ему дается УРЛ, он его забирает, ищет линки, собирает скажем 100 страниц сайта. Одновременно или даже до сбора, проверяются очевидные УРЛы позволяющие определить на каком движке работает сайт (скажем проверяете отзывается ли /wp-admin чем-то похожим на форму логина, проверете /sdfgsdfg отдает ли 404...). Затем в дело вступает модульная часть. Если нам удалось определить движек сайта, то мы начинаем пробовать его на известные уязвимости. Если не удалось, то пробуем общие методы. Типа во все параметры сунуть ;’ и посмотреть не вывалилась ли на страницу ошибка мускуля.

Соответственно работа ваша будет заключаться в том, чтобы все время пополнять библиотеку опознаваемых скриптов и пополнять библиотеку уязвимостей.

В качестве общего случая, когда движек остался неизвестным, тоже добавляем модули. Скажем написали модуль ищущий SQL инъекции. Затем написали модуль проверяющий XSS в форме поиска по сайту. Потом бац, сделали шаг в сторону и стали использовать гугль вот примерно таким методом https://www.google.com/search?q=SQL+site%3Acosmopolitan.com Затем бац, добавили модуль ищущий опубликованые ошибки в версии ПХП выложеной навесь мир... То есть работа на очень долго.

Про быстрый/медленый скан. Понятно что полное сканирование займет долго. Минут 5-10-15 на сайт. Надо что бы еще поддерживался быстрый скан. То есть оставляем только наиболее внушающие, но пусть даже и не существенные проблемы. Скажем раскрытие версии ПХП само по себе проблемой не является, но оно для бизнес-клиента во-первых неожидано, а во-вторых ему довольно просто объяснить человеческим языком в чем тут проблема. То есть задача быстрого скана: напугать и показать что пролемы возможны. Задача полного: попробовать какие-то проблемы найти.

Что бы не было разночтений: вам не надо быть супер-дупер мега хакером совсем. Это работа требует умения читать по-английски что бы набирать «корм» с сайтов типа такого http://www.cvedetails.com/ Затем скорость и аккуратность. Мы не ищем новые дыры, мы просто эксплуатируем известные. Наш «клиент» не супер-пупер крутой хакер, а хозяин небольшого сайта, который он сам собрал в 2008 или кому индусы что-то корявое на коленке налабали.

Первые модули которые мне хотелось бы увидеть вместе с каркасом:

1) Модуль SQL инъекций.

2) Модуль нахождения самых распространенных админок и их небольшого брутфорса на 5-10 самымх распространенных паролей.

3) Модуль опознания вордпресса

4) Модуль проверки какого-то серъезного бага в вордпрессе Что-то вроде http://www.cvedetails.com/cve/CVE-2012-2400/

Сами модули с нуля писать тоже не надо, во всяком случае поначалу. Зашли сюда https://github.com/search?q=sql+scanner&ref=cmdform посмотрели что и как сделано, или приспособили или переделали. В первую очередь это работа по исследованию и систематизации.

Мне бы очень хотелось услышать от вас что-то большее, чем «обращайтесь, сделаем!» Постарайтесь, пожалуйста, формулировать какие-то вопросы по теме так, что бы было ясно что вы задачу понимаете.