Как обойти str_replace?

[ewi]

Здрасте! У меня может быть последняя соломинка залить .htaccess )) Дайте может подсказочку! Точно знаю, что в исходном коде есть строка:

$FILE_NAME = str_replace('.hta', '_hta', $FILE_NAME) ;

То есть аплод файла .htaccess так и получается _htaccess

Есть ли способ обойти???

[devv]

Нулл байт.
Не юзай, не поможет.

[madhatter]

С вероятностью чуть более, чем никакой, вам может повезти с нечувствтительной к регистру фс, в то время как str_replace к регистру чувствтительна. В стандартной конфигурации веб-серверы понимают только читый '.htaccess', в нижнем регистре и мусора справа-слева. Если нормализация пути не проводится, можно посмотреть в сторону каталогов выше('../'). Лично я не в курсе, как оно будет вести себя с хитровыдроченными формами записи через юникод и "\xFF"-подобную нотацию, но попробовать стоит.

Также, возможно, стоит проверить другие расширения, которые может понимать сервер: cgi, scgi, pl, rb, py, pm, erb, php3, php5 и так далее.

[ewi]

cgi, scgi, pl, rb, py, pm, erb, php3, php5 и так далее

исключены на заливку все. Только htaccess заливается с заменой точки.

Теперь проверяю заливку файла с верхним регистром:
str_replace действительно чувствительна к регистру - файлы залились, но
.Htaccess - не включился
.HTACCESS - не включился
остальные капсы проверять нет смысла уже...

А юникод и "\xFF" - как это проверять не понял?
И про мусора хотелось бы подробнее...

[madhatter]

Сообщение от ewi

cgi, scgi, pl, rb, py, pm, erb, php3, php5 и так далее

исключены на заливку все. Только htaccess заливается с заменой точки.

Теперь проверяю заливку файла с верхним регистром:
str_replace действительно чувствительна к регистру - файлы залились, но
.Htaccess - не включился
.HTACCESS - не включился
остальные капсы проверять нет смысла уже...

А юникод и "\xFF" - как это проверять не понял?
И про мусора хотелось бы подробнее...

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

UPD: объясню про нечувствительные фс. Заливая woot.pHp, вы обойдете фильтр через str_replace и пхп запишет файл woot.pHp, однако, обращаясь к веб-серверу по /woot.php, вы получите выполнение кода, т.к. pHp == php. Аналогично, проверьте shtml, html, htm. Иногда в них включают выполнение.

[ewi]

Проверил...
К сожалению в коде идет понижение регистра в расширении. Но на htaccess понижение не действует, что интересно.

Однако, согласен, html проверить стоит...

[dharrya]

Еще иногда проходят варианты:
1. Проверить как фильтруется, убедиться что действительно используется блэклист
2. Если таки блэклист - попробовать залить *.pht. Многие при написании блэклистов не догадываются о этом расширении, а между тем такие файлики достаточно часто исполняются как PHP (например, на ванильном ubuntu server + Apache).
3. Попробовать залить *.php.jpg, на многих дефолтных конфигах Apache будет вызван PHPшный хендлер (сначала проверяются хендлеры, а только потом типы). Если файл залился, но PHP не исполняется - попробуй залить *.php.blah (на случай, если PHP подключается типом а не хэндлером). Если все еще никак - убедись, что этот файл не отдает nginx, если это именно так и до Apache дело не доходит - дерни его как "/assets/blah.php.jpg/blah.php" (AcceptPathInfo включен по дефолту).
4. Проверь как работает понижение регистра - для всего имени файла или только расширения
5. Если только для расширения - узнай в какой кодировке работает PHP. Может проверку расширений можно обогнуть невалидным символом. Особенно акктуально для связки UTF-8 + mbstring.func_overload > 2 + PHP < 5.4.0
6. Редко, но встречаются странные фильтрации с ветвлением логики. Попробуй залить ченить типа .htaccess.php, может выполнение пойдет не по тому пути:-)

Это то что первым приходит на ум, все зависит от ситуации и малейших деталей. Нужно фаззить:-)
P.S. Где-то на форуме была хорошая подборка различных вариантов байпаса блэклистов при загрузке файлов

[Pashkela]

Кхм, зачем отвечать на вопроц, где ничего нет, кроме стр_реплейс???

Если говорить о системном подходе - то важен не только фильтр, а еще способ ПОМЕЩЕНИЯ файл на сервер. Для тех, кто не понял сразу - это мув_аплоад, сопи, файл_гет_контентц и т.д. - вот где тоже можно найти изюм.

Почему какой-то имярек решил, что дело только стр_реплейс, и, не глупые вроде люди, ломают голову, когда просто тупо нет инфы? Вам не жаль своё время?

PS: а еще важно откуда берется $FILE_NAME и еще кучища параметров (ось, цмс, тмп_дир и прочее, да блин что вообще происходит ДО и ПОСЛЕ этого стр_реплейс, а тут мозг ломают над одной строчкой вырванной из контекста - ппц!)

PSS: Хотя, если бы ТС изначально размышлял бы на предложенном (в этом посте) уровне анализа, то, наверное, вопроса и не было бы (с) Р. Шекли "Верный вопрос"

[ewi]

Pashkela, я просил только подсказку, но не ломать голову, т. к. что идет до str_replace у меня нет исходника. Я точно знаю, что дело только в str_replace и далее сразу идет простой move_upload - это всё, что у меня имеется из кода.

[}{оттабыч2]

Сообщение от ewi

Здрасте! У меня может быть последняя соломинка залить .htaccess )) Дайте может подсказочку! Точно знаю, что в исходном коде есть строка:

$FILE_NAME = str_replace('.hta', '_hta', $FILE_NAME) ;

То есть аплод файла .htaccess так и получается _htaccess

Есть ли способ обойти???

а если там не Apache, то .htaccess до одного места.
Сделайте http fingerprint
Вот сервис нашел кстате https://w3dt.net/tools/httprecon