Использую на сайте авторизацию из форума phpbb (он тоже там установлен).
Проблема в том, что список запрещенных имен в настройках форума не работает. Поэтому не получается запретить использовать в логине при регистрации на форуме символы одинарной кавычки и символы треугольных скобок.
А так как я использую логин пользователя в очень многих местах моих скриптов остальных сервисов сайта, то, чтобы лишний раз подстраховаться от sql-инъекций и xss я просто хочу запретить пользователям с такими именами пользоваться остальными сервисами сайта (об этом я уже предупредил всех вежливо в тексте соглашения при регистрации на форуме).

Итак, во всех скриптах, использующих логин, я буду проверять логин с помощью следующего условия:

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

не понял вот этого ;)


Вот проверка логина..Выдаст ошибку, если в нике будет использована и латиница и кирилица одновременно ( $CheckLoginRegExp ), или если в нике будут символы ' } {

P.S. Не понял, что значит "трехуголные скобки" ;)
   

Треугольные скобки я имел ввиду эти: <>
Я думаю, будет правильнее найти в скриптах phpbb место, где проверяется логин при регистрации нового пользователя, и вставить там эту проверку.
Осталось найти то место..   

Кто-нибудь может подсказать где это?
Я опасаюсь, что если сейчас сам полезу, могу убить форум. А ведь там уже куча пользователей...

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

XSS возможен только при выводе - думаю, найти все места, где выводится логин, и поставить там htmlspecialchars (если его еще нет) не проблема даже вручную. Вставка же логина в SQL-запрос, по хорошему, нужна только в одном месте - самой авторизации (ну, может, еще в фильтре для поиска, как на этом форуме), во всех других местах в грамотно сделанной системе используется заведомо безопасный id юзера и "переподстраховываться" нет никакого смысла.

Так что рекомендую не высасывать проблемы из пальца и "не лечить перхоть гильотиной", делая доступность серсивов для юзеров зависимой от весьма странного и нелогичного критерия...

В одной из своих задач я весь введенный юзером ввод (кроме паролей, т.к. они нигде не оторбражаются) обрабатывал с помощью htmlspecialchars() c параметром ENT_QUOTES и в таком виде вставлял в БД. 
По-моему достаточно оптимальный вариант. Да, хтмл-код в базе не нужен, но и вреда от него нет. А проверок меньше. Могу ошибаться, но кажется IPB также хранит пользовательский ввод сразу в html, по крайней мере текст сообщений.

Добавлено @ 23:51

Имена, в которых хотя бы один первый символ - кириллица, (остальные могут быть и латиницей) пройдут.
Чтобы проверить именно выражение "использование кириллицы и латиницы", можно составить 2 регулярки для латиницы и кириллицы.

Это сообщение отредактировал(а) flashaa - 31.10.2007, 00:05

flashaa, между HTML в базе и результатом htmlspecialchars в базе есть существенная разница. Предложенный вариант оптимален для единственного случая - когда информация не используется ни для чего иного, кроме вывода на экран.

Кроме того, у beginа вопрос об изменении представления логина в базе и не стоит - логины уже есть от форума, он лишь боится, что они "чего-нибудь ему испортят" в других местах...

Это сообщение отредактировал(а) SelenIT - 31.10.2007, 00:10

Проверить только кириллица или только латиница можно и одним выражением, вот так:
/(^[a-z]+$|^[а-я]+$)/i

SelenIT, согласен, что можно разделить очистку и форматирование сообщений на два этапа. При вводе очистка, при выводе - форматирование. Форматирование сразу может быть реализовано. Но это может помешать допустим если изменятся настройки форматирования.
Скажем, изначально в тексте "активировались" ссылки, теперь после вставки в базу у нас уже будет полностью обработанный код, правила оформления которого с точки зрения html нам уже проблематично изменить. Но в случае с логинами пользователей(о которых изначально шла речь),  ведь кроме вывода нам ничего не будет требоваться?

Это сообщение отредактировал(а) flashaa - 31.10.2007, 00:14

Гм... а если после ввода юзером логина в базу помещать urlencode($login) и далее в коде везде использовать именно его? и соответственно при выводе на экран делать urldecode?
Какая тебе по сути разница, в каком виде все это валяется в БД - в оригинальном или как-то преобразованном? лишь бы было однозначное соответствие в обе стороны...
И плевать на скобки да кавычки...

flashaa, Akina, запись логина в базу у beginа уже реализована - в форуме, и


Akina, чем urlencode при вводе и urldecode при выводе принципиально лучше, чем mysql_real_escape_string при вводе и htmlspecialchars при выводе? Так и так ведь везде руками прописывать, к тому же второе после urldecode все равно понадобится, иначе риск XSS остается. А вот если понадобится, например, сортировать пользователей по русским буквам без учета регистра, наличие в базе результата "левых" преобразований существенно усложнит жизнь...