Авторизация на сайте без ввода логина/пароля

[laimas]

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

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

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

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

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

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

сли в РФ принудят ВСЕ сервисы иметь авторизацию по телефону

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

[Маэстро]

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

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

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

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

md5, sha1 прожорливы, а значит вас (домен ваш) можно просто положить размером файла, вы не проверяете ничего, как следует из вашего изложения. Уже плохо, так?

-не так.
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-ные проверки

[laimas]

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

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

md5, sha1 прожорливы, потому что им нужно подать в параметр всю строку

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

[Маэстро]

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

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

[laimas]

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

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

[Маэстро]

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

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

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

[laimas]

При передаче пароля злоумышленник может с тем же успехом передать 2ГБ символов в POST-запросе, по которым PHP-должен будет посчитать md5()

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

[laimas]

та не важно.

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

[laimas]

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