Подтвердить что ты не робот

Может ли что-то "плохое" произойти через img src?

Я знаю, я знаю, название довольно плохое, но я попытаюсь объяснить, что я имею в виду здесь. Поэтому я прошу своих участников показать свои фотографии. Они загружают его где-то, а затем вставляют URL-адрес своих фотографий на вход, и я сохраняю его в своей базе данных (MYSQL). Затем фотография просматривается на их профилях. Я получаю URL из базы данных и делаю что-то вроде этого: <img src="<?=$photo;?>" height="123px" width="123px">"> где $photo - URL, взятый из MYSQL. Это абсолютно безопасно? Может кто-нибудь загрузить, например, файл .php и повредить мой сайт? Нужно ли проверять, заканчивается ли URL.gif,.png,.jpg?
Спасибо.

Изменить: Да, конечно, я бы защитил свой сайт от SQL-инъекций и атак XSS. Но есть ли способ повредить мой сайт другим способом?

4b9b3361

Ответ 1

То, что вы описали, может быть уязвимым для атаки XSS (Cross-Site Scripting). По сути, гнусный пользователь может использовать javascript-код, который может делать плохие вещи, выполняя роль вашего сайта.

Пример этого вектора атаки: http://jarlsberg.appspot.com/part2#2__stored_xss_via_html_attribute

РЕДАКТИРОВАТЬ: Похоже, вы уже защищаете себя от SQL-инъекций и XSS, и вам интересно, есть ли у кого-то способ ввести PHP-код на ваш сайт. Я не думаю, что это возможно, так как ваш серверный код не будет выполнять эту строку. Вы просто поручаете браузеру клиента загрузить изображение с URL-адреса.

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

Ответ 2

Нет, это небезопасно, атаки XSS могут выполняться с помощью тегов изображений.

Простым примером может быть:

<IMG SRC=j&#X41vascript:alert('test2')>

http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

Ответ 3

Одна вещь, которую вы должны учесть - я мог бы связать вам мой образ "XUltra highres" с примерно 200 мегабайтами. Я предполагаю, что это может нарушить загрузку вашего сайта (в зависимости от дизайна). Таким образом, помимо "script атак", пользователи могут часто ссылаться на контент на ваш сайт.

Ответ 4

Несколько вещей, чтобы сделать, это проверить, что это реальный образ в принятом формате (tpyically jpg, png и gif), а также дезинфицировать и изменять имя файла.

Вы можете использовать функцию PHP getimagesize, чтобы проверить, действительно ли это изображение и какой формат. Вы получаете предполагаемый тип MIME при загрузке файла, но это не имеет смысла для проверки. Таким образом, следующее должно работать, поскольку функция getimagesize также проверяет изображения и возвращает тип exif.

$image_info=getimagesize($tempname);

$allowed_types=array(IMAGETYPE_PNG,IMAGETYPE_JPEG,IMAGETYPE_GIF);//these are actually the integers 1, 2 and 3

if(in_array($image_info[2],$allowed_types)){
   //image is a valid image. You can also check the height and width.
   }

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

Изменить: Я заметил, что вы ссылаетесь на пользователей, которые предоставляют URL-адрес изображения.

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

Те же принципы применяются, однако, для отображения URL-адреса изображения. Вы можете получить изображение через cURL или fopen, сохранить его в временном файле, а затем проверить, действительно ли это изображение, как описано выше. Это также может уловить пользователя, связанного с несуществующим или недопустимым изображением, чтобы вы могли их предупредить. Кроме того, соблюдайте ограничение на размер файла/размер - вы не хотите, чтобы кто-то ссылался на изображение размером 5 ГБ в своем профиле (хотя это была бы их проблема с пропускной способностью), так как это может привести к неудобствам для ваших других пользователей. Тем не менее, пользователь всегда может изменить файл на другое. Вы можете проверять один раз каждые х часов и предупреждать людей, которые делают что-то подозрительное, но это кажется большим усилием в конце.

Вы также можете применять правила имени файла, не указывая в Unicode имена файлов, и имя не должно содержать < > '' "" # -, которые являются символами, которые редко находятся в допустимых URL-адресах изображений.

Ответ 5

Предполагая, что вы уже дезинфицируете SQL-инъекцию. Вам нужно запретить пользователю делать что-то вроде этого:

<img src="http://usmilitary/launchAllNukes?When=Now" />

или

<img src""<script>//Evil code</script>" height="123px" width="123px" />

Ответ 6

Перед вставкой в ​​db используйте imagemagik для проверки того, что фотография является реальным изображением, а не что-то еще, и вы должны быть в порядке.

Ответ 7

Если вы разрешаете пользователям указывать какой-либо URL в качестве изображения профиля, злоумышленник может использовать это, чтобы облегчить атаку отказа в обслуживании на меньшем веб-сайте. Его влияние на целевой веб-сайт эквивалентно тому, чтобы быть разреженным. Например, злоумышленник может изменить свой URL-адрес изображения на большой ресурс, размещенный на целевом веб-сайте. Каждый раз, когда посетитель вашего сайта видит профиль злоумышленника, целевой сайт тратит трафик, обслуживающий ресурс посетителя.

Решением этого будет только разрешение URL-адресов изображений, которые ссылаются на сайты размещения изображений.

Ответ 8

Строго говоря - да. Я могу опубликовать изображение на вашем сайте, размещенном на моем сервере.

<img alt="Kobi Photo" src="http://example.com/photo.jpg" />

Кажется невинным, но на самом деле, каждый посетитель вашего сайта, наблюдая за моим изображением, можно отслеживать и записывать. Каждый посетитель получит сеанс на моем сервере и может даже получить куки файл (а не забавный вид). Чтобы все было еще хуже, я могу отслеживать каждую страницу просмотра ваших посетителей, которая отображает мою фотографию - браузер отправляет каждый URL-адрес, где фотография отображается через заголовок реферирования.
Позволяя людям размещать свои собственные фотографии, вы отдаете конфиденциальность своих посетителей.

Ответ 9

Нет смысла проверять расширение файла, поскольку это не гарантирует, что он не обрабатывается script. Запросы GET (как используется img src) должны быть безопасными и не должны вызывать существенное изменение состояния (например, покупка, удаление пользователя и т.д.). Тем не менее, есть багги сайты, которые делают это.

Таким образом, самым безопасным решением является требование, чтобы пользователи загружали изображение на ваш сайт. Если вы разрешаете удаленные изображения, вам необходимо, по крайней мере, потребовать схему http или https.

Ответ 10

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

Если вы действительно разрешаете пользователям загружать изображения, вы можете проверить тип mime (функция PHP getimagesize() может предоставить вам эту информацию). Это тоже не пуленепробиваемый, но лучше, чем просто проверка расширения.

Ответ 11

Загружая "где-то", вы будете размещать файлы на своем веб-сервере?

Есть много потенциальных проблем:

<img src="http://hacker.ru/badtimes.php" />
<img src="javascript:alert(String.fromCharCode(88,83,83))" />

Кроме того, специально созданные jpg могут заражать компьютеры пользователей: http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx

Ответ 12

Вы можете использовать регулярное выражение для фильтрации URL-адреса в PHP. Таким образом, вы можете запретить создание тегов javascript и указать допустимые расширения файлов.