Переход на php5

[timoshenkov]

Переход на php5

Скрипт на php 4 работал без ошибок

Положил скрипты на PHP 5.2 появилась ошибка

Warning: mb_ereg_replace() [function.mb-ereg-replace]: mbregex compile err: invalid wide-char value in ....

Вот из этого места, когда английские символы то ошибка не вылезает, так как кодировка определяется как ASCII

$mbEncod=my_mb_detect_encoding($str);
mb_regex_encoding($mbEncod);
$str=mb_ereg_replace("/[^\x20-\xFF,\x0A]/","",$str);

В чем проблема? что не нравится PHP в этом куске?

-~{}~ 10.03.08 04:01:

заменил регулярное выражение на "простое" ошибка пропала
получается что нужно "правильно" переписать эту ([^\x20-\xFF,\x0A]) регулярку под UTF-8

$str=mb_ereg_replace("/[^0-1]/","",$str);

-~{}~ 10.03.08 04:01:

как это сделать?

 

[dimagolov]

timoshenkov, а что ты хотел сказать этим классом?

 

[timoshenkov]

Автор оригинала: dimagolov
timoshenkov, а что ты хотел сказать этим классом?

что значит классом?

этой регуляркой я отрезаю все не печатные символы

 

[dimagolov]

timoshenkov, в регулярках [...] называется классом символов. ты задаешь 16-ричные однобайтовые значения в классе и просишь их понимать как UTF-8. Логично предположить, что некоторое из представленных значений не является однобайтным символом, а частью многобайтного.
вообще странные действия ты исполняешь. пока не раскажешь зачем такое надо, почему некие символы ты считаешь непечатными и почему их надо убирать решения мы не найдем.

 

[timoshenkov]

да я входящие данные проверяю, и то что не жду откидываю в сторону
Если есть другая регулярка, то готов выслушать с благодарностью

А как задать это для utf-8 не понимаю, наверное потому что не так уж силен в регулярных выражениях

 

[fixxxer]

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

 

[timoshenkov]

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

 

[dimagolov]

timoshenkov, повторю вопрос.
почему и зачем ты что-то считаешь недопустимыми символами? откуда береться строка, в которой ты хочешь их убрать и куда девается?

 

[timoshenkov]

Такой строкой я проверяю все входные данные через post и get
То есть это строчка из класса получения входящих данных
Что не произошло explot-a в системе я отсекаю все не текстовые символы

Эта проверка достаточно стандартная и про этот совет я читал в совершено разных источниках, зачем мне да вать возможность попадать в систему байтам, которых я совсем не жду?

 

[baev]

По-моему, топик явно просится в «Юмор».

timoshenkov, читайте это:
http://phpfaq.ru/slashes

 

[berkut]

тогда и htmlspecialchars()

 

[timoshenkov]

а что входные данные сразу в базу засовываются и больше ни куда?
или ребятя не перенеся топик в юмор уже шутить начали?

то есть вы хотите сказать что получив из $POST['str'] в переменую $str
которая может быть очень большой длинны (текстовое содержание страницы на сайте)
опастность в это переменой только в неэкранированных кавычках?

и что с версии php4 у пользователей нет ни каких шансов подсудуть другие данные в эту переменную?

 

[berkut]

и какая опасТность может там быть?

 

[timoshenkov]

Посмотрел среди php форумах это ни где не обсуждается кроме как вот сдесь
http://phpclub.ru/talk/showthread.php?s=&threadid=69904

эту регулярку я ее с перла перетащил, так как в сети есть чуть ли не готовые примеры как сделать explode серваку - написано кукую страру из шела кинуть на сервер
так вот там как раз таки и идет набор левых символов которые приволят к переполнению памяти и выполнению системных команд на сервере

почему я выше спросил, что с версии php 4 этого не требуется, то потому что не знаю, может php эту задачу на себя берет и выкусывает символы сама, которые пользователь не может передать, если не будет их посылать из терминала

если эта проблема пережитки прошлого то буду рад убрать эту строчку из кода

 

[dimagolov]

Автор оригинала: timoshenkov
так вот там как раз таки и идет набор левых символов которые приволят к переполнению памяти и выполнению системных команд на сервере

бред.
потому что если это exploit в php core, который вызывает переполнение внутри него, то никак кодом на php это не исправишь.
если это нечто другое, то проблема может быть только в использовании полученных от пользователя данных неправильно и опять таки, решать это надо правильным подходом к пользовательским данным, а не заклинаниями в виде непонятно каких регулярок.

 

[berkut]

потому что если это exploit в php core, который вызывает переполнение внутри него, то никак кодом на php это не исправишь.

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

 

[dimagolov]

berkut, ок, мы хотим защищаться от exploit-ов, о которых не знаем, методов их использования мы тоже не знаем, но почему-то думаем, что вырезав некоторое множество символов из полученных данных мы проблему решим? Что-то сомневаюсь. Скорее уж ради этого стоит ограничевать размер получаемых данных неким разумным значением и обрезать более длинные строки.
Есть ф-ии binary-safe, в которые можно передавать любые аргументы, и есть не binary-safe. Более того, кол-во ф-й для работы с UTF-8 весьма ограниченно, а именно в этой кодировке у нас данные. Перед использованием любый не mb_ ф-й мы все равно обязаны производить конвертацию.
Так что вырезать что-то ради непонятно чего да еще с отнюдь не очевидным результатом (очевидно будет только ощущение того, что данные типа безопасны, мы ведь их почистили, что на сомом деле не так) я считаю бессмысленным.

 

[berkut]

а я разве говорил что это хорошая практика вырезать непонятно что и городить тучу проверок непонятно для чего? я просто ответил на

то никак кодом на php это не исправишь.

-~{}~ 13.03.08 20:01:

вообще это бредятина, как ни крути. ахтунг может затаиться в том-же прег_реплэйс-е - тогда ничего уже не спасёт. а если-б фигнёй не страдал и не резал чё попало, то мог-бы и не напороться на "эксплоит" прег_реплэйса

 

[timoshenkov]

ну спасибо за просветление
сейчас вроде как и правда не могу вспомнить этот совет для php и через броузер

для перловый скриптов это точно было, но они и из командной строки запускаются

вот я и перенес этот приемчик лет 5 назад в php и особо не задавался вопросом меняет он что то или нет