27.07.2017, 15:19
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Сообщение от Маэстро
|
|
причем тут вообще JPEG? файл никак не может быть изменен скриптом загрузки от Клиента на сервер, независимо от его типа, формата, назначения! то, что Вы сказали, у меня просто в голове не укладывается.
|
Это у вас спросить надо, вы же принимать фото пользователей собираетесь и сравнивать их хеш по сохраненному. А насчет "не может быть изменен", ну так что долго проверить и убедиться, что будет иной, и кстати скрипт тут не причем. Охота лицезреть воочию, пожалуйста, если сами не можете сделать или не охота:
Первое понятно, второе md5 их. Как видите простая передача. |
|
27.07.2017, 15:42
|
|
Профессор
|
|
Регистрация: 02.07.2010
Сообщений: 642
|
|
Сообщение от laimas
|
|
Это у вас спросить надо, вы же принимать фото пользователей собираетесь и сравнивать их хеш по сохраненному. А насчет "не может быть изменен", ну так что долго проверить и убедиться, что будет иной, и кстати скрипт тут не причем. Охота лицезреть воочию, пожалуйста, если сами не можете сделать или не охота:
|
-скрипт тут как раз "причем"! Вы показали скриншот содержимого массива. где код эксперимента? подозреваю, что Вы таки грузите фото функциями 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 а у ВАС?
?>
|
|
27.07.2017, 16:24
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Если через GD и рабатать на разных платформах и хоть что-то по минимуму изменить, то естественно могут быть разночтения, это понятно. Нет, но это не скрипт какой-то виноват, получается сразу загруженное:
md5(file_get_contents($_FILES['file']['tmp_name']);
Удачно как, думаешь об одном, делаешь иное и обнаруживаешь странности - бинарная загрузка, файлы (любые) кроме JPEG/PNG24 дают разный результат (файл конечно цел). Это работа локального сервера, в нем есть один косяк, но он связан с mod_rewrite.
Пока дискуссии в сторону, надо понять причину.
Да, у меня такой же хеш.
|
|
27.07.2017, 16:29
|
|
Профессор
|
|
Регистрация: 02.07.2010
Сообщений: 642
|
|
|
Сообщение от laimas
|
|
Это работа локального сервера, в нем есть один косяк, но он связан с mod_rewrite.
|
-никогда не сталкивался с таким. по-моему такого тоже не должно быть. иначе как тогда работал бы FTP??
Ну, как разберетесь - сообщите, как так сервер может искажать принятые файлы? |
|
27.07.2017, 16:42
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Сообщение от Маэстро
|
|
иначе как тогда работал бы FTP?
|
Ну так это же не FTP работа. То что цвет на разных платформах будет различен это естественно, так же и работа ПО, той же GD, реализованная под разные платформы может давать различия, это тоже понятно. Если бы я исполнял imagecreatefromstring(file_get_contents($_FILES['file']['tmp_name']))), пусть чисто для отсеивания мусора, сохранял, тогда бы понятно было что да, возможно. Но это обычная загрузка бинарника по HTTP.
Какой-то кошмар творится. Структуру файлов проверим сейчас. |
|
27.07.2017, 16:47
|
|
Профессор
|
|
Регистрация: 02.07.2010
Сообщений: 642
|
|
laimas,
отсеките file_get_contents(), попробуйте ещё проще:
echo 'md5_file='.md5_file('http://javascript.ru/forum/images/ca_serenity/misc/logo.gif');
// md5_file=49e34ee0b1a64997cfe07f7f2ef188b1
|
|
27.07.2017, 18:09
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
Нет, все правильно, сам идиот, делал и забыл.  Почему может быть разный результат и с чем это связано (выше говорилось), а также что все надо проверять и т.п.. Когда-то ради эксперимента сделал слежение за каталогом - время последнего доступа к файлу изменилось, меняем ему 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/ |
|
27.07.2017, 19:00
|
|
Профессор
|
|
Регистрация: 02.07.2010
Сообщений: 642
|
|
|
Сообщение от laimas
|
|
... время последнего доступа к файлу изменилось, меняем ему EXIF
|
аа.. теперь ясно. меняете 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-атака на скрипт регистрации. Вот это меня беспокоит больше всего..
|
|
27.07.2017, 19:38
|
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,989
|
|
|
Сообщение от Маэстро
|
|
Вы снимаете своё обвинение
|
А были обвинения? ) Речь о том, что требуется проверка всего и вся, а из статей, думаю понятно, что опасность может хранить и безобидная загрузка файла. Ведь и ежику понятно, что если вы цель направленной атаки, то ник-то не станет пользоваться вашей "правильной" формой, атака может быть с домена, который может "лежать" даже рядом с вашим.
|
Сообщение от Маэстро
|
|
непонятно, нахрена это надо было делать
|
Это разъяснение сути механизма. Попробуйте просто вывести такую картинку под корректным mime type, и страшного не случится. Но ведь такая атака как раз рассчитана на беспечность, статью о фильтрах и потоках прочли? А если загрузить кроме картинок "вредных" еще и мастера ими управляющего, то поле деятельности богатое для них будет. Здесь когда-то был вопрос о "непонятных файлах" оказавшихся на сервере, распаковка которых показала, что они модифицируют php.ini.
Не использовать preg_replace с модификатором е, об этом и в руководстве предупреждается, для таких случаев предлагается preg_replace_callback().
|
Сообщение от Маэстро
|
|
я считаю, что предложенный мною метод безопасен в смысле взлома/подмены передаваемых от Клиента на сервер данных
|
Нет, с этим согласится трудно, что логин и пароль подвержен атаке, что и файл изображения.
|
Сообщение от Маэстро
|
|
При анализе принятого файла я не использую никакие графические, музыкальные и прочие библиотеки.
|
Значит не прочли как следует о фильтрах и потоках. Если ваша загрузка файла отвечает безопасности, тогда да, если есть слабые места, то могут выполнить и произвольное.
Делайте, обрадуйте своих пользователей, именно им решать примут ли они такой подход или нет. Если при регистрации я вижу, что от меня обязательно требуют номер телефона, а ресурс обычная серость которой в Интернете тысячами, я просто ухожу с такого ресурса и сожаления нет. Свой телефон я могу оставить на важных и нужных ресурсах, например на портале Госуслуг.
Если я зайду к вам и меня будут просить что-то хранить на флешке, отправлять с нее, или слать картинки себя любимого, ... тоже парится не буду, уйду. Это менталитет. Другое дело ваши целевые клиенты, если ваш ресурс для них важен, то даже действуя методом кнута, заставив их использовать флешку-ключ или еще что либо, они будут вынуждены принять такие условия. Это се ля ви.
Ну а насколько "защита картинкой" будет не по зубам хакерам покажет время или закажите атаку себе специально, чтобы не ожидать времени.
|
|
27.07.2017, 19:59
|
|
Профессор
|
|
Регистрация: 02.07.2010
Сообщений: 642
|
|
|
Сообщение от laimas
|
А были обвинения? )
-ага. вот:
вы же принимать фото пользователей собираетесь и сравнивать их хеш по сохраненному. А насчет "не может быть изменен", ну так что долго проверить и убедиться, что будет иной, и кстати скрипт тут не причем. Охота лицезреть воочию, пожалуйста, если сами не можете сделать или не охота
|
|
Сообщение от laimas
|
|
Не использовать preg_replace...
|
-та я спрашивал, с какой целью в том скрипте вообще использовали preg_replace()? и не очень понимаю почему там третий параметр (строка поиска) пустой
|
Сообщение от laimas
|
|
Нет, с этим согласится трудно, что логин и пароль подвержен атаке, что и файл изображения.
|
-приведите пример атаки на изображение, которая мне повредит? как?
|
Сообщение от laimas
|
|
Если ваша загрузка файла отвечает безопасности, тогда да, если есть слабые места, то могут выполнить и произвольное.
|
- я же показал практически весь код скрипта для анализа принятого файла. вот он:
sha1_file($_FILES['file']['tmp_name']);
В чем здесь уязвимость?
|
Сообщение от laimas
|
|
Если я зайду к вам и меня будут просить что-то хранить на флешке, отправлять с нее, или слать картинки себя любимого, ... тоже парится не буду, уйду. Это менталитет
|
-ммда.. против менталитета наверное нет никаких аргументов.
хотя.. если в РФ принудят ВСЕ сервисы иметь авторизацию по телефону (со всеми паспортными данными и вытекающими последствиями), то посмотрю куда Вы пойдете.. может и ко мне.. файлик на флэшке держать
https://daily.afisha.ru/technology/6...schie-polgoda/
|
|
|
|
