Нашел 2 статьи возможностях взлома PHP приложениях, они описывают баги и дырки в интерпритаторе и некоторых функциях. Читать всем, кто не читал это ещё. Новичкам must read (только не нужно изобретать монструозную защиту, она делается легко и парой небольших функций, а так же правильной настройкой как сервера, так и проектированием приложения) http://vingrad.ru/blogs/dominus/rokovyie-oshibki-php/ http://vingrad.ru/blogs/dominus/rokovyi ... ki-php-v2/ Добавляйте прочие статьи, только следите что бы не пересекалось. Дубли и бред буду удалять, дабы не захламлять. Так что не обижайтесь если ваше сообщение съест НЛО © Habrahabr
register_globals off и mysql_escape_string основа основ безопасных приложений. Фильтрация хорошо, но экранировать лучше все данные, которые идут в базу. Ну и до кучи: http://php.net/basename если нужно подключить файл основываясь на внешних данных http://php.net/escapeshellcmd для данных идущих в консоль Соблюдение этих правил минимизирует возможность взлома приложения.
почитал сабжевые ссылки, ни одной "баги" у себя не увидел ввиду отсутствия всяких регистров_глобалс и прочей мути. еще пара статей банальной "мудрости".
antonn а move_uploaded_file и copy_uploaded_file ? И прочие. Поверьте, через это взламываются сайты и довольно много. Сами ломали конкурентов и делали дефейсы именно через такие глюки
Psih move_uploaded_file использую. какие в нем баги, с учетом того, что url-имена отключены (как и удаленные инклуды), инклуды не делаются, меджики включены, регистр_глобалс отключен, все запросы проходят через прцоедурку, которая экранирует автоматически, а в htaccess не дается пхп выполнять код в папке, куда аплоадится?
Просто прочитай внимательно про null-byte. Он между прочим определяет конец строки, поетому вполне возможно, что проскочит. Проверь
Добавлю ещё, что все данные приходящие в регулярку извне должны обрабатываться функцией http://php.net/preg_quote
Kreker Поидее должна и это обработать, т.к. она безопастна для обработки данных в двоичной форме. Ну а если хочешь знать 100% - проверь!
Я знал, что глобалс - зло, но не подозревал, насколько злое это зло! :twisted: Про нулевой байт тоже стало новостью. А регулярки их разве не обрабатывают? о_0
Psih ты конкретно скажи где там подвох, дай конкретную ссылку. Потому что после заявлений "сами ломали конкурентов" я не отстану. Вот даже пример набросал. Некоторые настройки я выше перечислил. Код (Text): $attach=$_FILES['attach']; if ($attach['name'] != "" && is_uploaded_file($attach['tmp_name']) ) { $attach['name']=stripslashes($attach['name']); if (preg_match("/^[-0-9A-Z_]+$/i", $attach['name'])){ $attachname=md5($attach['name']); move_uploaded_file($attach['tmp_name'], "./forum/attachments/".$attachname); } }
А если просто не давать загружать файлы .php и т.д.? Ну, что-то типа PHP: <?php ... ... $file_ext = explode(".", $userfilename); $num_parts = count($file_ext); if($file_ext[($num_parts - 1)] == "jpg") { # сохраняем } else { # так нельзя } ... ... ?>
а еще плюс к этому всему рекомендуется читать раз в месяц журнал Хакер.ru, там очень много полезного, и эксплойты можно посмотреть какими вас будут атаковать...
sobachnik Прикол с null byte именно в том, что он указывает на окончание строки, поетому то, что находится за null byte функции могут не увидеть, в итоге получится взломать вас
То есть (применительно к моему примеру выше) что получится? Функция explode будет разбивать по точке переменную $userfilename до тех пор, пока не наткнётся на этот null byte? А дальше? Последнему элементу массива $file_ext будет присвоено всё, что осталось после null byte? Что там произойдёт-то?
короче он напишет .jpgNULL-BITE.php у тебя загрузит как картинку, а на сервере получится что загрузился скрипт
Факт в том, что этим грешили move_uploaded_file, copy_uploaded_file. Как щас - незнаю. Мысль в том, что не известно, какие функции подвержены таким проблемам, тут нужно методом тыка проверять.