Насколько повысит безопасность сайта принцип хранить картинки на другом сервере?

Question

[Антон Р.]

Много читаю про то что при загрузке картинок пользователями часто можно подхватить вредоносный скрипт (шелл, бэкдор и пр.), но если я буду хранить все картинки на совершенно другом сервере с другим доменом и вообще на разных аккаунтах хостинга - насколько это поможет защитить программную часть самого "движка"?
Ну и еще вопросец по теме - почему на многих сайтах запрещено загружать гифки хотя встроить кусок php-кода можно и в джипег?

Comments

[Kerm]

Ты когда загружаешь файл на сервер то проверяешь его Mime тип и расширение и если расширение файла не "png","jpg","gif","jpeg" то файл не грузишь, далее проверяешь Mime тип и если он не 'image/jpeg', 'image/gif', 'image/png', 'image/jpg' то файл не грузишь и в nginx к примеру можно сделать запрет на запуск PHP кода для определенной категории.

[Антон Р.]

Kerm, на хабре в статье писали интересные примеры когда даже в корректном файле картинки прямо в коде в начале файла был забит php-код, и еще куда то пихали не помню куда, в общем как один из вариантов убить такой скрипт - сделать резайз картинки на 1 пиксель (в комментах предлагали), тогда вся левая инфа из тела картинки удаляется.
https://habr.com/ru/post/44610/

[Kerm]

Антон Р., все зависит от настроек сервера, можно работать с файлом в процессе его сохранения на сервере в плоть того же ресайза на 1 пиксел или снижения качества.

Answer 1

[Adamos]

Картинки могут использовать три вида уязвимостей:
1. В настройках вашего сервера. Если у вас можно загрузить картинку и обратиться к ней, и она останется неизменной и может оказаться не картинкой, а скриптом, который выполнится на сервере. Искореняется проверкой MIME и отдачей статики без обработки.
2. В библиотеках пользователя (старые версии libpng, например). В дикой природе практически не встречается, но если угодно, можно перекодировать файлы, используя ImageMagick.
3. И вот тут всплывает третий вариант: атака самого IM всякими форматами, в которых поддерживаются внешние ссылки. Искореняется ограничением того, что вообще можно загрузить и обработать, PNG и JPG, и последующей обработкой их IM.
На практике получаем, что проверка MIME и перекодирование IM решает все ваши проблемы. Заодно и еще одну - вам не навалят файлы такого размера, что внезапно кончится место на хостинге.
А вынос на другой сервер - вообще ни о чем. Только лаги увеличивать. Так делают для очень высоконагруженных проектов... но там и таких вопросов не задают ;)

Comments

[Антон Р.]

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

[Антон Р.]

"и последующей обработкой их IM." - что такое IM и зачем оно нужно если ресайз или кроп можно сделать средствами php напрямую?

[Adamos]

Антон Р., отдача статики без обработки - это, например, в связке nginx + apache Апачу передаются на исполнение только php-скрипты, а картинки и css/js nginx отдает сразу, никак не обрабатывая. Так скрипт, залитый с расширением картинки, на сервере никак не исполнится.

IM - ImageMagick строчкой выше. РНР для обработки картинок использует как раз эту библиотеку.

Answer 2

[Kerm]

spoiler

Это тот случай где читать надо меньше

Comments

[Антон Р.]

предлагаете загружать картинки сразу на основной сервер сверяя только расширение? А вы любите рисковать )

[Kerm]

Антон Р., я не чего не предлагал.

[Kerm]

Антон Р., а по поводу предложений, почитайте про mime_content_type для начала, после можно да, именно, проверять по расширению файла, далее можно переименовывать сохраненные картинки и можно запретить использование php в папке куда сохраняете картинки.

Answer 3

[SagePtr]

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

Если при сохранении файла полагаться на то имя, что юзер передал - то да, будет огромная дыра. А если имя в скрипте как-нибудь безопасно генерировать, то никакой дыры не будет, сервер не будет исполнять эти файлы PHP-интерпретатором. К примеру, в качестве имени - хэш от содержимого файла (заодно поможет бороться с дублями), в качестве расширения - либо jpeg, либо gif, либо png, исходя из первых нескольки байтов файла (если не попадает ни под один из указанных форматов - то отказ)

Comments

[Антон Р.]

Генерация рандомного имени это первое что я сделал, например так:

//Генерация случайного имени картинки:
	$image_extension = strtolower(substr(strrchr($_FILES['image']['name'], '.'), 1));
	$_FILES['image']['name'] = md5(time() . uniqid($more_entropy=true)) . "." . $image_extension;

[SagePtr]

$image_extension = strtolower(substr(strrchr($_FILES['image']['name'], '.'), 1));

Но тут расширение файла берётся из $_FILES['image']['name'] - а его передаёт на сервер именно браузер пользователя. В этом и заключается у вас дыра, а что если расширение файла будет php или любое другое, обрабатываемое сервером как интерпретируемый скрипт.
Так делать не надо, нужно завести список допустимых расширений и уже из этого списка выбирать наиболее подходящий вариант.

[Антон Р.]

SagePtr, да, проверками еще не обвешивал скрипт.
Вот только что написал такую обработку:

// Узнаем всю информацию о файле
	$imageInfo = getimagesize($_FILES['image']['tmp_name']);
	list($width, $height, $type, $gabarite, $bits, $channels, $mime) = $imageInfo;
	
	// Проверяем тип и mime
	if($type != 2 && $mime != 'image/jpeg'){
		$errors[] = "Ошибка! Допускаются только картинки в формате jpg!";
	}
	else {
		$image_extension = 'jpg';
	}
	
	// Проверяем вес картинки
	$volume = $_FILES['image']['size'];
	if($volume > 2097152){
		$errors[] = "Ошибка! Файл превышает допустимый объем 2 мегабайта!";
	}

Ну и дальше если массив $errors пустой то есть ошибок нет то заносим картинку в папку предварительно переименовав и добавив .jpg в конце

[Антон Р.]

SagePtr, блин, прочитал что нельзя доверять mime информации из функции getimagesize(), завтра немного по-другому сделаю.

[Kerm]

Антон Р., а для кого я писал про mime_content_type