LINUX.ORG.RU

Что за веб-сервер крутится, скажите для начала. Например, я сталкивался один раз с таком самописным движком на PHP, который не проверял все входящие данные от пользователя (речь ниже о заголовках), и те же программисты, похоже, еще и администрировали VDS, на котором он крутился. Вообщем, простыми словами, там суть была в том, что в связке nginx+php-fpm у nginx-а тупо не было задано конкретное fastcgi_param HTTP_HOST в конфиге, а недодвижок тот, как раз добавлял что-то в БД, связанное с разными регионами, основанными на поддоменах. Суть, юзали _SERVER[HTTP_HOST], даже не обработав переменную. Это при том, что писали на симфони, и вроде код на быдло особо не смахивал (ну всмысле не было желание пойти на govnokod.ru, если вы понимате о чем я :)), но видать вот так вот бывает у людей. Ну и, грубо говоря, SQL-инъекция через любой безобидный telnet-запрос:

GET test HTTP/1.1
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:windows-1251,utf-8;q=0.7,*;q=0.3
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Host:{YOUR_SQL_INJECTION}
Referer: test
User-Agent:test
По логике вещей программисты и виноваты, но я считаю что такие вещи можно отлавливать еще до фактической обработки запроса. Столь длинное лирическое оступление я написал вот в чему. Трудно тестировать что-либо без минимально-предоставленных данных. (сервер, версия, другое ПО взаимодействующие с сервером, какие-либо прослойки и т.д.).

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

znenyegvkby
()
Ответ на: комментарий от Manhunt

Спасибо за ссылку, не знал, надо будет глянуть скрипт изнутри. Я мельком поглядел скриншот, правда не понял закономерности в тесте уязвимостей. Вроде относительно недавно обновлялся скрипт (уязвимости 2015 есть), но вот многих за 2014 не хватает, в частности 3470/0221/0198/0195, да и других не мало. Пока некогда скрипт посмотреть, мысль сразу пришла в голову что скорее всего какие-то уязвимости не получится протестировать через bash, да и не на все еще написаны реализации.

Мне сама идея понравилась прогнать ПО на все известные уязвимости с cve.mitre.org. Так-то больше половины решается простым обновлением, но я вот только недавно сталкивался с openSSL 0.9.4/5, ЕМНИП:(.

Если у вас есть еще инфа о таких скриптах, пожалуйста, поделитесь ссылками, вы меня очень обяжите. Я пробывал спрашивать такими и похожими запросами: bash/perl/python auto-detect vulnerabilities, но в-основном информация кусками, либо для конкретных CVE.

znenyegvkby
()

OWASP scanner, например. там же куча гайдов и ссылок на более другое ПО. жабаклована не слушай

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

спросили про тулзы

награфоманить про не имеющих отношения к делу говнокодеров

в конце написать что в тулзах не понимаешь нихрена

суть жабапетухов

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

Off-topic

Ваше величество, вы так четко видите всю ситуацию, что мне, смертному, даже нечего вам возразить :( Посыпаю голову пеплом, и ухожу под ваше неудержное гиканье.

По теме

Крутится самописный (на голом C++) HTTP-сервер: http://obsuditor.ru/chat/

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

Сканнерами из разряда OWASP (oscanner/websecurity/w3af/sslstrip/etc) неплохо прогонять сервер на CSS/CSRF/FPD/ED/etc, т.к. их действительно просто обнаружить, но как я сказал выше, для более глубоких уязвимостей сервера, этого будет мало, да и полагаться в таком вопросе на программу (при учете создания своего web-сервера) как-то не комильфо. Скорее всего вам захочется избежать тех же граблей nginx'а (CVE-2013-4547/CVE-2009-2629/etc), допустим. Поэтому с такими вопросами, считаю уместным изучить каталог (тем паче, что не весь, а тех же известых web-серверов), чтобы быть в курсе специфичных для web-серверов уязвимостей.

Off-topic

не видеть дальше CSS/CSRF

суть анонiмуса.

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