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



Первое понятно, второе md5 их. Как видите простая передача.

-скрипт тут как раз "причем"! Вы показали скриншот содержимого массива. где код эксперимента? подозреваю, что Вы таки грузите фото функциями GD и смотрите, какие параметры она выдает (чего я предупреждал не делать!).
вот мой скрипт:

<?
// проверка md5() загружаемого файла

$s = 'http://javascript.ru/forum/images/ca_serenity/misc/logo.gif';
$v = file_get_contents($s);
if ($v !== false) echo md5($v);
// у меня  49e34ee0b1a64997cfe07f7f2ef188b1 а у ВАС?
?>

Если через GD и рабатать на разных платформах и хоть что-то по минимуму изменить, то естественно могут быть разночтения, это понятно. Нет, но это не скрипт какой-то виноват, получается сразу загруженное:

md5(file_get_contents($_FILES['file']['tmp_name']);

Удачно как, думаешь об одном, делаешь иное и обнаруживаешь странности - бинарная загрузка, файлы (любые) кроме JPEG/PNG24 дают разный результат (файл конечно цел). Это работа локального сервера, в нем есть один косяк, но он связан с mod_rewrite.

Пока дискуссии в сторону, надо понять причину.

Да, у меня такой же хеш.

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

Ну так это же не FTP работа. То что цвет на разных платформах будет различен это естественно, так же и работа ПО, той же GD, реализованная под разные платформы может давать различия, это тоже понятно. Если бы я исполнял imagecreatefromstring(file_get_contents($_FILES['file']['tmp_name']))), пусть чисто для отсеивания мусора, сохранял, тогда бы понятно было что да, возможно. Но это обычная загрузка бинарника по HTTP.

Какой-то кошмар творится. Структуру файлов проверим сейчас.

laimas,
отсеките file_get_contents(), попробуйте ещё проще:

echo 'md5_file='.md5_file('http://javascript.ru/forum/images/ca_serenity/misc/logo.gif'); 
// md5_file=49e34ee0b1a64997cfe07f7f2ef188b1

Нет, все правильно, сам идиот, делал и забыл. :) Почему может быть разный результат и с чем это связано (выше говорилось), а также что все надо проверять и т.п.. Когда-то ради эксперимента сделал слежение за каталогом - время последнего доступа к файлу изменилось, меняем ему EXIF. При этом EXIF это "жук". Так и осталось, хотя эксперимент давно закончен.

Это почитать, станет понятно:

https://xakep.ru/2013/07/17/60928/
https://xakep.ru/2012/10/01/php-vulnerabilities/

Есть у них еще одна отличная статья, но читал давно, пытался найти по воспоминаниям, но не нашел. А это как под видом JPEG файла можно загрузить на сервер объект посредством подмены Content-Type и произвести CSRF-атаку:

https://labs.detectify.com/2014/05/2...-your-website/

аа.. теперь ясно. меняете EXIF - меняется файл - меняется хеш файла.
Ну так что, Вы снимаете своё обвинение насчет того, что у мнгократно загружаемого JPEG файла хеш меняться не будет?! а то я тут чуть не поседел тут уже.. ;)

вообще мне непонятно, нахрена это надо было делать:

$exif = exif_read_data('/homepages/clientsitepath/images/stories/food/bun.jpg');
preg_replace($exif['Make'],$exif['Model'],'');

про preg_replace() и его модификатор /e не знал. это ужас. ну благо в PHP7 хоть его вообще убрали.

Делаем выводы: я считаю, что предложенный мною метод безопасен в смысле взлома/подмены передаваемых от Клиента на сервер данных. При анализе принятого файла я не использую никакие графические, музыкальные и прочие библиотеки. Подмена Content-Type ничего не меняет, т.к. мне всё-равно если злоумышленник поставит Content-Type:jpg, а пришлет mp3 или наоборот. Обственно анализа никакого файла не производится. Будет работать только sha(файл).
Жаль, что другие посетители форума молчат. Странно, неужели все такие "чистые" javascript-программисты??

В описываемом механизме, в отличие от систем с SMS-паролями есть одна большая проблема: DDOS-атака на скрипт регистрации. Вот это меня беспокоит больше всего..

А были обвинения? ) Речь о том, что требуется проверка всего и вся, а из статей, думаю понятно, что опасность может хранить и безобидная загрузка файла. Ведь и ежику понятно, что если вы цель направленной атаки, то ник-то не станет пользоваться вашей "правильной" формой, атака может быть с домена, который может "лежать" даже рядом с вашим.

Это разъяснение сути механизма. Попробуйте просто вывести такую картинку под корректным mime type, и страшного не случится. Но ведь такая атака как раз рассчитана на беспечность, статью о фильтрах и потоках прочли? А если загрузить кроме картинок "вредных" еще и мастера ими управляющего, то поле деятельности богатое для них будет. Здесь когда-то был вопрос о "непонятных файлах" оказавшихся на сервере, распаковка которых показала, что они модифицируют php.ini.

Не использовать preg_replace с модификатором е, об этом и в руководстве предупреждается, для таких случаев предлагается preg_replace_callback().

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

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

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

Если я зайду к вам и меня будут просить что-то хранить на флешке, отправлять с нее, или слать картинки себя любимого, ... тоже парится не буду, уйду. Это менталитет. :) Другое дело ваши целевые клиенты, если ваш ресурс для них важен, то даже действуя методом кнута, заставив их использовать флешку-ключ или еще что либо, они будут вынуждены принять такие условия. Это се ля ви. :)

Ну а насколько "защита картинкой" будет не по зубам хакерам покажет время или закажите атаку себе специально, чтобы не ожидать времени. :)

-та я спрашивал, с какой целью в том скрипте вообще использовали preg_replace()? и не очень понимаю почему там третий параметр (строка поиска) пустой

-приведите пример атаки на изображение, которая мне повредит? как?

- я же показал практически весь код скрипта для анализа принятого файла. вот он:

sha1_file($_FILES['file']['tmp_name']);

В чем здесь уязвимость?

-ммда.. против менталитета наверное нет никаких аргументов.
хотя.. если в РФ принудят ВСЕ сервисы иметь авторизацию по телефону (со всеми паспортными данными и вытекающими последствиями), то посмотрю куда Вы пойдете.. может и ко мне.. файлик на флэшке держать ;)
https://daily.afisha.ru/technology/6...schie-polgoda/