Меню
Что нового?

Переход на php5

timoshenkov

timoshenkov

Новичок
Переход на php5

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

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

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

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

PHP: 
$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

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

-~{}~ 10.03.08 04:01:

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

А как задать это для utf-8 не понимаю, наверное потому что не так уж силен в регулярных выражениях :(
 
задай _допустимые_ символы
китайские иероглифы и иврит тебе вряд ли нужны... замучаешься недопустимые перечислять, юникод большой ;)
 
в том то и дело, что мне нужен и китайский и японский, а может потом и иврит, это сайт справочник для туристов, и количество языов хотят сделать максимальным :(
как быть то?
 
timoshenkov, повторю вопрос.
почему и зачем ты что-то считаешь недопустимыми символами? откуда береться строка, в которой ты хочешь их убрать и куда девается?
 
Такой строкой я проверяю все входные данные через post и get
То есть это строчка из класса получения входящих данных
Что не произошло explot-a в системе я отсекаю все не текстовые символы

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

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

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

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

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

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

-~{}~ 13.03.08 20:01:

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

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

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