Pull to refresh

Comments 57

общая лента = плохо
личное сообщение(хабрапочта) = хорошо
Отличный цикл статей на очень актуальную проблему.
Пракически каждый второй самописный проект с формой заливки изображения имеет подобные уязвимости, как это ни печально :(
UFO landed and left these words here
Причитайте вторую часть, там рассказано про это.
Если у изображения будет расширение php5 или какое-то другое неучтенное в blacklist, то скрипт успешно выполнится. Имхо намного безопаснее использовать whitelist: array('gif',jpg, ...)
Файлы с расширением php5 — выполняются? Первый раз слышу. Блеклист и whitelist — оба плохих решения, лучше всего как я сказал присуждать расширение файла автоматически, на основе его проверенного типа.
php5, php4, php3 исполняются — бывают всякие настройки
Если вам нужно сделать загрузку картинок, то лучше использовать белый список расширений, если же просто загрузку аттачей, то блеклист исполняемых расширений.
добавляем в Apache2\conf\httpd.conf
AddType application/x-httpd-php .php5

Расширение может быть любым, хоть jpg и gif :)
tapin13, но если злоумышленник получит доступ к httpd.conf или хоты бы .htaccess, то можно считать, что безобасность сервера уже нарушена и его уже ничто не спасет. Поэтому стоит признать, что whitelist намного более безопасен.
Вообще надо сразу делать resize картинки, в итоге если бы это был скрипт — будет ошибка, если ошибка — удаляем.
Даже если будет замаскирован скрипт, то «внутренности» файла сильно изменятся и соответсвенно скрипт не сработает.
Это так сказать самый простой вариант «борьбы»
Ну и почему минус?
Аргументы можно?
Я опущу ошибки в путях сохранения файла (по умолчанию надо «разбирать» get post cookie и проверять)

При resize файл изменяется содержимое файла — если скрипт, он просто не заработает, так как тоже подвергнется видоизменениям. Если функция resize выдаст ошибку — просто удаляем файл.

Ну и почему минус? Троллим?
объясните плиз, как проверять Content-Type не изображения (скажем .avi) в случае подмены MIME-типа?
Обычно с помощью тех модулей, которые отвечают за обработку данного типа. В случае avi это будет ffmpeg.

Хотя вроде я видел специальные библиотеки для вычисления MIME-типа файлов. Но может ошибаюсь.
ну в случае использования ffmpeg понятно — там можно тупо конвертировать файл при загрузке и вредоносный код перестает существовать.

интересно тогда знать, ну допустим подменил я mime-тип засунув пхпшный файл с раширеним .avi.
неужели его открытие в браузере вызовет исполнение php-кода?
Если .avi — нет, т.к. этот формат не будет выполним. А вот если ваш avi имеет расширение php то да, выполнится.
Не совсем. Злополучный IE пытается казаться умным и может выполнить код в image/jpeg например. Но это правда уязвимости другого рода — сервер *.avi файл не будет выполнять ;)
прочитал последний абзац второй главы и нашел ответ на вторую часть вопроса.
получается единственно безопасное для видео файлов, помимо всех проверок — конвертировать их при аплоаде.
Ресурсоемко. Достаточно изменить расширение.
ясно. проверка на Content-Type не имеет особого смысла, если MIME все равно можно сделать любым. достаточно проверять на whitelist расширений.
Для PHP есть расширение «fileinfo», прекрасно работающее под *nix'ами
У вас там «загрузка фалов» в первом предложении.

Так выглядит фал
А можно просто запретить выполнение PHP-скриптов из директории uploads директивой в .htaccess:
php_flag engine off

Вот и все. Только, конечно, стоит запретить перезаписть .htaccess (;
Во второй части уже предлагали сделать что-то вроде этого.
Спасибо, а как запретить и в поддиреториях этого каталога?
Можно было бы просто написать — никогда не делайте инклуд пользовательских данных. Проблема, имхо, высосана из неправильного архитектурного решения.
Вчера нарыл: www.getid3.org/ getID3() is a PHP script that extracts useful information from MP3s & other multimedia file formats.

Reads & parses (to varying degrees):
* AIFF
* APE tags: v1 and v2
* ASF: ASF, Windows Media Audio (WMA), Windows Media Video (WMV)
* AU
* BMP
* Bonk
* CD-audio (*.cda)
* FLAC
* Flash
* GIF
* ID3v1 & ID3v1.1
* ID3v2.4, ID3v2.3, ID3v2.2
* ISO-9660 CD-ROM image (directory structure)
* JPEG
* LA (Lossless Audio)
* LPAC
* Lyrics 3: v1 & v2
* Lyrics3 v1 & v2
* MIDI
* Monkey's Audio
* MP3/MP2/MP1
* MPC / Musepack
* MPEG video
* NSV (Nullsoft Streaming Video)
* Ogg (Vorbis, OggFLAC, Speex)
* OptimFROG
* PNG
* Quicktime
* RealAudio, RealVideo
* RIFF: AVI/WAV
* Speex
* VOC
* VQF
* WavPack
* ZIP (directory structure)
классная штука, жаль не в тему
Вы точно читали топик и комментарии?
В части определения типа загружаемого контента.
а зачем вообще использовать имя присланного файла, между прочим это тоже баг. move_uploaded_file перезапишет существующий файл с таким же именем. нужно генерить уникальное имя и цеплять к нему нужное расширение
выше описаные методы работать не будут, в случае kestas.kuliukas.com/JavaScriptImage/forumlogo2.png (Открываем в ИЕ), поэтому делаю ресайз пикчи на 1 пиксель, при желании можно потом на один пиксель увеличить, тогда JavaScript рушится.
Имя генерируем уникальное — в папке запрещаем выполнение скриптов. Вроде все.

А как могут модифицировать изображение, что оно скриптом станет?

По идее можно на сервере настроит, что хоть pdf как php обрабатываться станет.
мда, читаю это всё и думаю, толи php разработчики ничего не знают кроме php, толи они и самого php не знают.
Ну да ладно, для начинающих сойдёт.
а к чему это было сказано? можно обьяснить свою мысль более подробно? мне например интересно Ваш ход мыслей в данном случае
помоему проще и надежней загружать картинки в папочку с .htaccess который запрещает доступ, и выдавать для просмотра картинки через скрипт…
Вопрос, а почему нельзя совсем просто поступить и допускать файлы только с расширениями из white list, не проверяя содержание? Ну и пусть внутри будет находиться вредоносный код, если файл будет с расширением .jpeg, например, то ведь всё равно ничего не выполнится?
ну а если тебе закинут в папочку htaccess с командой которая будет говорить выполнять jpeg как php? :)
да, но я не принимаю файлы, не прошедшие через фильтр допускаемых расширений. Конечно можно директивы .htaccess спрятать в файле под расширением .gif, и он сохранится в папке для картинок, но исполняться-то всё равно не будет? Правильна ли логика?
htaccess с расширением jpg просто не сработает.
хорошая статья. пойду нафиг выкорчую php на сервере.
Как видно, переводчик PHP игнорирует двоичные данных в…


интерпритатор, компилятор, интерпретирующий компилятор, пожалуйста, не обзывайте «переводчик»

а вообще по статье хорошо, но не все. что конкретно картинок касается, то нужно работать по схеме разрешено разрешенное, а не незапрещенное, тоесть пере конвертировать картинку
Это деятельность электронного переводчика. Спасибо, поправил.
поправили на «трансялтор PHP игнорирует двоичные данных» — шикарно! Перечитайте еще пару раз, на всякий случай :)
Это деятельность электронного переводчика. Спасибо, поправил.
Я же не зря сказал «перечитайте пару раз» ;) — трансялтор
Это уже моя невнимательность. Спасибо, поправил.
Вообще-то PHP — транслирующий интерпретатор, но никак не компилятор.
ну да, я согласен. просто с джавой щас работаю — смешалось немного
Нужен не блек лист, а список только разрешённых расширений.
абсолютно верно!
нужно не проверять запрещенные вещи, а пропускать разрешенные!
у меня в папке куда грузятся файлы, кроме общей проверки, еще .htaccess стоит, который всякие cgi скипты в плейн/текст превращает…
UFO landed and left these words here
Вот так всегда. Пример защиты намекает на ее обход.
Only those users with full accounts are able to leave comments. Log in, please.