Есть очень популярное мнение, что найти серьезный баг в популярном продукте очень сложно!? Современные разработчики пишут продукты явно с учетом существования различных сообществ и даже любителей одиночек - багоискателей!:)
Однако пусть они хоть обтестируются - проследить все до единой взаимозависимости и вызовы способен способен лишь очень талантливый искатель багов, которых, как известно, в мире очень мало. Зато хацкеров и кракеров, которых хлебом не корми, дай что-нибудь сломать и заломать, пока хватает.
И так, создаем плацдарм:
Первое - поднимаем web-сервачок на своем PC или на физическом сервере для тестирования...не будем палить найденные баги в логах на оф.сайте, что крайне не профессионально:). Еще и настройки чужого сервера могут быть неблагоприятны, и могут мешать в анализе и поиске бага в движках.:(
Поэтому несколько важных "БуквЪ":) для настройки веб-сервера на максимальное отображение всех возможных простых и сложных ошибок!
PHP.ini
register_globals=ON ; глобализация переменных - потенциальная брешь в безопасности...
magic_quotes=OFF ; отключаем магические кавычки для GET/POST/COOKIE - благоприятствует выполнению SQL-inj....
magic_quotes_runtime=OFF ; тоже что и выше в тексте....
magic_quotes_sybase=OFF ; применяется также для SQL-inj...
mysql.trace_mode=ON ; показ ошибок в MySQL^)...
allow_url_fopen=ON ; разрешает удаленное открытие файлов файловыми функциями...
allow_url_include=ON ; разрешает удаленно инклудить файлы...
error_reporting=E_ALL ; показ всех ошибок...
error_log= /var/log/httpd/php_error ; логирование ошибок...
sgl.safe_made=OFF ; очень благоприятствует совершению SQL- inj
настраиваем конфиг Апача:
DirectoryIndex [пусто] ; нет стартовой страницы
Options Indexes ; листинг директорий - это позволит сканеру свободно проиндексировать и анализировать все скрытые скрипты....
И так плацдарм готов, для анализа бажных движков...:))))))))))
Аудит цели почти все привыкли начинать с нехитрых запросов в поисковых системах...классика жанра так!:) и для аудита кода:)
Второе -
1. Ничто нам не мешает обратить обновление движка против его самого, тупо берем две соседних версии проекта и сравнением изменений пытаемся найти баг. Смотрим HISTORY.txt - в нем помимо всяческих фиксов багов, может быть готовое, правда скудное описание найденных закрытых уязвимостей. Но здесь еще одна фича для анализа, так сказать - то что пофиксено - не обязательно пофиксено повсеместно!:)
2. Выполнение произвольного кода с привилегиями веб-сервера, то ради чего мы мучаемся...
нехитрый вариант:
UPDATE cms_config SET lang=concat (' rus/.../.../.../../etc/passwd' ,0x00) ; смотрим базу аккаунтов на сервере...
еще...в случае недостаточной фильтрации можем вписать в конфиг произвольный PHP-code, что-то типа: phpinfo().
Было...:
$db_host = ' localhost ' ; а.....бой баррабанов...
будет...:
$db_host = ' localhost ';phpinfo() ;\\' ;
об остальных интересных штуках....надеюсь написать в второй части....Спасибо за внимание тем, кто дочитал первую часть!!!:)
Поднял web-сервер на Django — у меня нет перечисленых файлов. ЧЯДНТ?
Если автор креатива не против, отвечу «специалисту» я.
Нет такого. В технологическом стеке, Джанго базируется на web-сервере (apache, nginx и т.п.), а не наоборот.
Во-первых, «перечисленных» пишется с двумя «н». Во-вторых, могу предположить, что Вы все делаете так, просто у Вас запотели очки и Вы не увидели заголовок. Ключевое слово в нем "PHP-движков". Джанго же — не движок, а фрэймворк, и не на PHP, а на Python.