не так давно узнал что в тег <img> в src можно не только файл картинки писать, а например php-скрипт который генерирует картинку.. Так фот у меня возник вопрос в плане безопасности.. а если пользователь будет загружать файл картинки, он же может выбрать файл скрипта и тогда может случиться мало чего приятного... Как такого можно избежать? Можно проверять расширение файла.. Вот интересно, а если он php расширение сменит например на jpg, то скрипт выполнится?

Чего именно? И почему нельзя загружать файл скрипта?


какой скоипт?

ты не мог бы свои фантазии описывать более конкретно? Не в виде "сменить шило на мыло", а с конкретными именами файлов и видимыми опаснстями.

ОК.. Есть форма для загрузки картинок, после загрузки эти картинки отображаются в <IMG>.. Вот я и предположил, если загрузить не картинку(*.jpg, *.gif, *.png) а php-скрипт(*.php), так вот по идее он выполнится, а это уже дыра в безопасности.. Чтобы этого не произошло, можно проверять расширение загружаемых файлов, т.е. файлы *.php НЕ загружать.. Но тут тоже можно попробовать обойти это... Написать скрипт, сохранить с расширением как *.jpg, тогда файл проверку на расширение пройдет и загрузится на сервер.. А вот при отображении, если в этом файле не картинка а скрипт, выполнится ли этот скрипт???

Скрипт с расширением жпг выполнится как скрипт, только если в настройке сервера прописано обрабатывать  файлы жпг как php-скрипты. Короче говоря, не выполнится.

Другое дело, что содержимое загружаемых изображений(и вообще любого отображаемого в браузере фала) хорошо бы проверить на наличие html-кода, при отображении некоторых видов изображений в браузере выполняется этот код, в том числе и яваскрипт, а это уже возможность XSS. Пример из IP.B:

ок, подскажите тогда пожалуйста, какие файлы не следует загружать... Я для себя составлю списочек  Пока он такой:

.php
.phtml
.phtm
.php3
.html
.htm
.pl

надо составлять список не тех файлов, которые нельзя загружать, а тех, которые можно.

GeneralElectric, похоже, не шутка. Есть у IE такая подлая черта - "MIME sniff". Пример Sannisа, судя по всему, ссылается вот на это.


Абсолютно верно (например, для картинок - .gif, .png, .jpg, .jpeg, можно еще .bmp). Для пущей уверенности можно на всякий случай проверять их ф-цией Sannisа. 

ок, тогда вот так:

.jpg
.jpeg
.gif
.bmp
.png

есть еще какие-нибудь расширения картинок отображаемые <IMG>?

зависит от браузера.
к примеру, текущий вариант FireFox умеет работать с SVG, некоторые браузеры работают с VML(Internet Explorer). Не делать же полный список всех возможных графических типов? Проще определить, что "я, мол, поддерживаю только то-то, то-то и то-то; остальное идет лесом".

Нет, вполне серьёзно. Мало кто может сфабриковать картинку для такой уязвимости, но пренебрегать ей не стоит.

Это сообщение отредактировал(а) Sannis - 28.1.2008, 00:54

Sannis, SelenIT, спасибо за интересную информацию

Sannis, кстати, я тут задумался: а как можно использовать эту уязвимость? Скрипт в картинке ведь сработает, только если вызвать ее напрямую (в крайнем случае, через iframe/object), со стандартным <img src="..."> ничего страшного не грозит. Единственное, что приходит на ум - это сделать какую-нибудь пакость от имени авторизованного юзера (вроде такого, причем предложенная там защита по рефереру в этом случае как раз не поможет). Но такой случай, имхо, сам по себе довольно экзотичен, к тому же вскользь упомянутое там же "железное" решение (с уникальным идентификатором формы в сессии) не позволит и этого...

Но вообще, конечно, приведенный код (как и само поведение IE, правда) отдает каким-то шаманством. Ну почему '<a href=...' заставляет картинку отображаться как html, а '<a id=... href=...' - уже нет? Кто знает, нет ли еще подобных "волшебных" комбинаций?..

меня по-поводу шаманства преследует такая мысль:

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

(как при производстве памяти: штампуют стандартно 1024Мб, битых 300Мб, они дорезают до стандарта в 512 - вот и результат)

отсюда и проблемы в разнице стандартов

п.с. шутка, хотя кто его знает...

SelenIT, довольно просто. http://www.securitylab.ru/contest/291564.php, как раз годичной давности.

Sannis, спасибо за ссылку!

значит, при загрузке картинку придется обработать(приводимый в статье по ссылке Sannis говорится о растяжении/сжатии, но я бы предложил просто открыть и сохранить со сменой формата). и проблем не будет. по крайней мере с IE. так?

Странно, а почему выполняется такое условие?



загружаю *.jpg пишет что "неизвестное расширение файла", выводил echo $bnfiletype; все правильно - пишется "jpg".. непонятно..

Это сообщение отредактировал(а) Dmitry_177 - 2.2.2008, 18:44

Dmitry_177, ничего странного. Условие ИЛИ выполняется, когда хотя бы один из вариантов истинен, а "jpg" действительно не равно "png" 

Вообще я бы рекомендовал делать проверку через !in_array(<массив допустимых расширений>) - и короче, и нагляднее.

по идее $bnfiletype != "jpg" не должно же выполняться, т.к. равно этому.. отсюда все условие по идее должно было бы НЕ выполниться..

Посмотрю как через массив сделать, может переделаю..

Это сообщение отредактировал(а) Dmitry_177 - 2.2.2008, 19:03

Dmitry_177, до него просто не доходит, потому что условие ИЛИ, а if в PHP "короткозамкнутый" - обнаружив первое сработавшее условие, дальше просто не проверяет. В данном случае первым сработавшим, и, тем самым, последним проверенным условием оказывается $bnfiletype != "png". Но дело не в этом, а в неправильной логике - по смыслу тут нужно условие И.

в качестве саморазвития 

чтобы мое условие заработало, так правильно будет?




через массив, вот так?

и еще ИМХО, лучше перевести $bnfiletype в нижний регистр..

По-моему, да - для обоих вариантов...

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

Для данного случая справедливо. Но вообще желательно работать на правильной локали.

Цитата из ссылки Sannis





Получается, если я создам 1.jpg с текстом <script>alert('a');</script> и открою его в ИЕ, то выскочит алерт? Что-то он не выскакивает.
К тому же никто не обратил внимания на комментарий к статье, в котором говорится, что примеры  XSS через картинку повторить не удалось.
То ли эта уязвимость была закрыта (пробовал в ИЕ6) и не так уж важна, толи это вообще утка какая-то.

в статье приводятся "внешние ссылки". так вот, одна из них намного информативнее указанной статьи на securitylab.

Насколько я понял, в этой статье описаны разные XSS через HTML-код страницы. Я же выше говорил о том, что содержимое самого файла изображения может трактоваться IE как код 

А о методах XSS и защиты от него, я надеюсь, разработчики знают...

Посмотрел ссылку. Но к моему вопросу она не имеет отношения.
Мой вопрос был таков: если файл картинки .jpg содержит html-код, который выполняется в браузере при открытии этой картинки, то можно привести пример или объяснить такой случай? 
В cтатье securitylab говорилось именно про картинки. Про различные вариации html-кода со скриптами я вопросов не имею.
Так вот сама идея интерпретации картинки .jpg как скрипта - маразматична. Поэтому я усомнился в этом и пытаюсь уточнить, правда ли это. 
Допустим у меня есть файл image.jpg. Я пишу в него <script>alert('aa');</script> и открываю в браузере ИЕ6. Почему то у меня отображается красный крестик, но нет никакого скрипта? 
Ведь


Это сообщение отредактировал(а) flashaa - 29.2.2008, 12:52

кроме проверки по расширению файла, можно еще попробовать
http://ru2.php.net/manual/en/function.getimagesize.php
данная функция кроме размера возвращает еще и тип файла (jpeg, png, ....)

flashaa, вы же ставите время от времени заплатки, не так ли? Сейчас, думается мне, Микрософт уже закрыл это на уровне браузера...

Sannis, ну и тогда следует принять к сведенью то, что данный баг давно устарел. В связи с его маразматичностью, думаю он устарел очень и очень давно. Ещё до выхода ИЕ7. А статья автора относится к желтой прессе )

flashaa, не спорю 

А статья автора уже более чем годичной давности, тогда ещё не закрыли .