LINUX.ORG.RU

Тестирование на SQL Injection


0

1

Дано: куча веб-сайтов, написанных разными людьми на разных самопальных фреймворках.
Надо: протестировать в более-менее автоматическом режиме всё это дело на уязвимости к sql инъекциям. К сайтам есть полный доступ, т.е. достать информацию не интересно, интересно найти уязвимый скрипт.

Пересмотрел кучу софти для поиска инъекций(WebCruiser, SQL Power Injector, sqlmap, Havij и ещё кучу названия которых просто не запомнил), но так и не нашёл программы своей мечты.
Программа мечты должна уметь делать хотя бы один из пунктов ниже, а лучше оба.
Первое: прога должна уметь сканировать сайт и находить скрипты на которые идёт обращение(в идеале даже ajax) и параметры, которые туда уходят. Потом бежать по этому списку и пытаться сотворить инъекцию. В случае успеха, показывать какой скрипт уязвим.
Второе: В прогу должна быть возможность загрузить файл определённого формата, в котором будет список скриптов для тестирования и для каждого скрипта будет указан метод(Post/Get) и список параметров с дефолтными(рабочими) значениями. Прога соответственно бежит по этому списку и ищет уязвимые скрипты.

Подскажите, есть ли подобные программы? Самому писать не хочется да и некогда. Платные решения приемлемы. Без разницы под Linux или оффтопик.

З.Ы. а чем вы ищите sql инъекции?

★★★★

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

а чем вы ищите sql инъекции?

Руками.

winddos ★★★
()

надо писать с использованием orm, тогда искать sql инъекции не нужно будет вовсе

anonymous
()
Ответ на: комментарий от winddos

>Ни одна автоматика не найдет ошибку программиста-идиота лучше, чем другой программист.

Это да, но когда сайтов под 2 сотни и они написаны сильно по разному и людьми которых уже давно нет в команде, то это займёт слишком много времени. Ну и ни о каком переодическом тестировании, тестировании после крупного апдейта и проч. речи не идёт. А этого очень хочется.

Xspider, Nessus.

Спасибо, Xspider посмотрим. Nessus тоже надо будет поковырять с модулем для поиска sql-инъекций.

Руками

Это конечно хорошо, но, если вам достанется довольно увесистый проект на саппорт со словами «работает, не трожь», а потом попросят проверить на тему sql инъекций, то вы будете ковыряться у него внутрях неделю?

WARNING ★★★★
() автор топика
Ответ на: комментарий от WARNING

Все мои проекты написаны так, что там даже в теории не может быть SQL INJ.
Аудит я провожу, обычно, для чужих проектов.

Ну и под проверкой руками я подразумеваю проверку снаружи, без кода.
И да, я буду ковыряться руками. Т.к моя цель сделать работу хорошо, заодно найдется другая пачка дыр/багов/раскрытий инфы

Практика доказала, что сканеры так или иначе ошибаются или пропускают вполне очевидные (для человека) дырки. А безопасность требует серьёзного, комплексного подхода.

Но если вам надо «для галочки» провести эту проверку - то автоматики вполне хватит, она даст увесистый отчет который оценит начальство.

winddos ★★★
()
Ответ на: комментарий от winddos

Автоматика необходима, но после неё обязательно и руками проверить.
В противном случае это не проверка, а просто отмазка.

winddos ★★★
()
Ответ на: комментарий от pento

Спасибо, по описанию похоже на то что надо. Посмотрю обязательно.

WARNING ★★★★
() автор топика
Ответ на: комментарий от pento

Для тестирования использовал профиль full_audit, тестировал на реальном проекте. Отработал он как-то подозрительно быстро, буквально за минуту. Карту сайта построил вроде правильно(не внимательно смотрел, красиво). Это собственно всё, что я могу хорошего о нём сказать. Теперь что не понравилось:
1) Нет базы CVE. Оно вроде не критично, но приятно когда есть.
2) Алгоритм поиска sql-инъекций убил. А вот это критично.
3) Нет сканера портов. Опять же не критично, но приятно.

WARNING ★★★★
() автор топика
Ответ на: комментарий от WARNING

1. Каким образом ты связываешь поиск SQL-инъекции и базу CVE, а главное зачем? Тогда уж уместнее CWE.
2. Чем именно убил алгоритм поиска?
3. Зачем тебе при поиске SQL-инъекций сканер портов?

pento ★★★★★
()
Ответ на: комментарий от pento

1. Это в сравнении с нессусом. Там есть, тут нет. Когда есть лучше. Но я написал, что это не критично.
2. Насколько я понял, алгоритм состоит в том, чтобы посылать строку d'z"0 в каждый параметр и искать вывод sql-ошибки в браузер. Это, во-первых, бессмысленно на живых системах, во-вторых, элементарно пропускает union all.
3. Аналогично первому пункту.

По поводу второго пункта. Тут поковыряли нессус, возникло предположение, что он действует не сильно умней. Если так, придётся лепить самопал. Возможно, как плагин(или что там у него?) к w3af.

WARNING ★★★★
() автор топика
Ответ на: комментарий от xtraeft

1. Отнюдь. Особенно, если проект делал и сервер настраивал человек, которого уже давно нет. Да и на собственную память полагаться в вопросах обновления софта - это не очень хорошая идея.
3. Не спорю. Но ведь приятно же, черт побери, обнаружить торчащий наружу 3306.

WARNING ★★★★
() автор топика
Ответ на: комментарий от WARNING

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

2. причем тут union all? Ты различаешь поиск уязвимостей и их эксплуатацию? Важно как веб-приложене реагирует на необычные для него значение параметров входных.

Если у тебя есть идеи как улучшить sqli плагин для w3af, то без проблем. Сформулируй их и с большой долей вероятности сделаем.

pento ★★★★★
()
Ответ на: комментарий от pento

1. Возможно. Ещё не разобрались с нессусом. Будем проверять.

2. Ну хотя бы вот такой говнокод, так сказать, с пылу с жару:
get.php?id=1
if (strrchr($_GET['id'], «'»)) {
$id = 1; //нас пытаются взломать, но мы готовы!
} else {
$id = $_GET['id'];
}
$sql = «select * from news where id=$id»;

w3af не найдёт в нём sql-инъекции. Надо расширять способы обнаружения.

То что полагается только на вывод ошибки в браузер, это не страшно. сторожевой скрипт на логах оповестит об ошибке.

WARNING ★★★★
() автор топика
Ответ на: комментарий от WARNING

>Но ведь приятно же, черт побери, обнаружить торчащий наружу 3306.

извиняюсь, что влезаю, но nmap уже отменили, да?

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

WARNING ★★★★
() автор топика
Ответ на: комментарий от WARNING

>нет, конечно. Просто когда есть список серверов и волшебная кнопка пыщь, то такой мониторинг может делать хоть QA, после небольшой тренировки. А для nmap либо знания нужны, либо интерфейс ваять. В общем всё решит тест-драйв Нессуса.

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

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Если у вас работают обезьянки, то мне вас жаль, и обезьянок тоже.
У нас работают нормальные люди, хотя работа у них, конечно, адская.

WARNING ★★★★
() автор топика
Ответ на: комментарий от WARNING

у нас QA не боятся ни nmap'а ни умных книжек, ни консоли со скриптами. а еще они знают, что есть два вида инструментов: у одних есть большая блестящая кнопка, но они не работают, а у других кнопки нет, зато они работают.

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

>есть два вида инструментов: у одних есть большая блестящая кнопка, но они не работают, а у других кнопки нет, зато они работают.

в квотезы, срочно!

Pinkbyte ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.