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



Первое понятно, второе 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/

А он и не нужен в данном случае параметр третий, хотя он указан - пустая строка. Здесь задача иная - запустить код, который внедрен в изображение. Можете установить программу любую, которая добавляет EXIF в файл, проверяйте. Ну если без этого, то запустить и посмотреть что получится:

preg_replace(
    '/.*/e',
    'eval("phpinfo();")',
    ''
);

В данном примере (по ссылке) требуется помощник. Но не рассчитывайте на то, что я делаю безобидное sha1_file(загруженное), а поэтому все проблемы стороной. Это не так, md5, sha1 прожорливы, а значит вас (домен ваш) можно просто положить размером файла, вы не проверяете ничего, как следует из вашего изложения. Уже плохо, так? Ну и все-таки, читайте об wrapper - абстрактный слой для работы с файлами, сетью и другим, из него можно читать, в него можно писать, перемещаться в нем.

На ресурсе, на который я ссылки давал об этом много пишется. Локальный сервер есть? Берите примеры, пробуйте, так будет понятнее. А говорить об этом долго какой смысл, если из одной статьи вы не сделали вывода.

Это так, для "ответной атаки", уж коли об этом речь зашла. :)

Если это и грозит, то далеким предкам.

-Вы никак не поймете, о чем я спрашиваю. Я знаю, что такое preg_replace(), eval() и как делаются взломы такого типа. Я спрашиваю: на том каком-то сайте, где впервые была обнаружена (или применена?) эта уязвимость, зачем там использовался preg_replace()? не в целях же демонстрации уязвимости?? вот я на своем сайте использую такой код:

$s = preg_replace('/[\x00-\x1F]/', ' ', $s);

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

-не так.
1. md5, sha1 прожорливы, потому что им нужно подать в параметр всю строку, т.е. она должна быть в памяти. я же буду использовать md5_file()/sha1_file(), которые работают с потоком и не грузят всё содержимое файла в память
2. в PHP есть такие понятия, как post_max_size=1, upload_max_filesize=1. обработки больших файлов не будет, т.к. до этого не дойдет.

laimas,
UPD
когда я говорю, что "никаких проверок не будет" - имеется ввиду, что я не буду никак проверять СОДЕРЖИМОЕ файла. мне всё-равно, что пришлют.
а классические PHP-шные проверки конечно будут!

if (isset($_FILES[$fieldname]))
if ($_FILES[$fieldname]['error'] == 0)
if (!(empty($_FILES[$fieldname]['name'])))
if (move_uploaded_file($tmpfname, $tofile)) 
if ($_FILES[$fieldname]['size'] < $minfilesize) // если размер закачанного файла меньше допустимого

и т.д., равно как и соответствующие SQL-ные проверки

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

Нет, дело в том, что память занимает, а сам алгоритм не раз, два и готово. При большой длине файла, это время. Если post_max_size=1, upload_max_filesize=1 (макс. размер POST доложен быть более чем макс. загружаемый файл), таким образом урезав все и если это административным задачам не будет помехой, защищайтесь. Но это только ограничение, но еще не значит "безопасно теперь".

Согласен. Это беспокоит. На мой взгляд программно это не решить. Тут только методом умощнения процессора.
Однако давайте обсуждать мой подход в СРАВНЕНИИ с классическим вводом логина/пароля. При передаче пароля злоумышленник может с тем же успехом передать 2ГБ символов в POST-запросе, по которым PHP-должен будет посчитать md5(), чтобы потом найти в базе. Как с таким борются??

if (!(empty($_FILES[$fieldname]['name'])))
и
if (move_uploaded_file($tmpfname, $tofile))

Что такое в этом случае $tofile?

та не важно. это же код не из боевой системы, это мой "черновичек". это я проверял разные аспекты и временно сохранял принятый файл в папке..

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

Еще как важно. Если проверять загрузку так, то это не проверка, уж точно. Кстати !(empty($_FILES[$fieldname]['name'])) здесь скобки лишние.

Ну и самая беда, это конечно содержимое, то есть не важно что там шлют, посчитал md5 и все. Но если пароль 1234 "живет", то с таким же успехом может быть и паролем собственная аватарка, другими словами пароль у всех на виду. Это надо тоже не сбрасывать со счетов. Ну и снифферы никуда не исчезли. Так что хрен редьки не слаще, то есть картина будет более надежным только лишь потому, что это картинка, это далеко не так.

я ждал такого ответа.
во-первых, нормальный хакер не использует <form>...</form> в браузере, чихать ему на браузерные ограничения. атакующие программы пишутся на C, Delphi с применением Indy и т.п... и послать на сервер можно что угодно.
во-вторых, если на хосте ограничения, то те же самые ограничения распространятся и на загрузку файла. с точки зрения POST-запроса ему всё-равно, что у него внутри (строки,символы/байты/биты...).

-ну сколько раз повторять: нет разницы между "мусором" и "ценным". оператору sha() всё-равно, что хешить.

я уже и не рад, что сказал о возможности использовать фото в качестве фотопароля (файла-пароля). изначально говорилось о файлике, сгенерированном на сервере и присылаемом с сервера.
и ПРИ ПРОЧИХ РАВНЫХ УСЛОВИЯХ метод однокилобайтного файла со случайной последовательностью выигрывает по сравнению с 10-символьным паролем по вероятности несанкционированного доступа методом перебора.

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

Не надо повторять, все ясно чего вы хотите. Но вы говорите, что одно можно подобрать, картинки же аналога "1234" почему-то быть не может. Загрузку логина/пароля легко подменить, а картина бронь. Ну это же не серьезно.

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

Делайте, тестируйте и со статистикой использования на обсуждение в сеть. Я же не отговариваю, вы спросили "как", я ответил "без разницы". Задачи доказать, что я не прав в своем мнении, перед собой вы не ставите? А я тем более об этом не заикаюсь.

Все, что долго говорить. :)

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

Ни чего я не перевираю, ваше высказывание было, что левая форма пришлет строку 2 ГБ, ну так на строку также распространяется установка макс. разрешенного для загрузки, какие проблемы?

А зачем файл? Даже длина строки в 20-30 символов, и при этом только дилетант будет хранит чистый хеш ее, хранят вообще-то с солью. Да и не md5, начиная с версии 5.5 лучше использовать Password Hashing функции. В версии 7 более устойчив случайный генератор, это еще дополнительные трудности для подбора.


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