Проверьте пожалуйста регулярку для URL-ов

Проверьте пожалуйста регулярку. Будет использоваться для обработки всех URL-ов, по которым обращаются к сайту, чтобы исключить любые SQL инъекции.

Регулярка
$str = preg_replace('/[^a-zа-яA-ZА-ЯёЁ0-9\s"\/?&_=-]/u', '', $str);

Список допустимых символов:
a-zа-яA-ZА-ЯёЁ - все буквы
0-9 - все числа
\s - пробел
" - двойные кавычки
\/ - слэш
? для параметров в адресе
& для параметров в адресе
= для параметров в адресе
_ нижнее подчеркивание
- тире
Все остальные символы исключены.

Правильно ли составлена регулярка?
Тире правильно прописано? (если его поставить не последним, то работает не корректно).
Может что-то изменить/добавить?
Есть альтернативные варианты полного экранирования ссылок на сайте?
Я конечно же проверил, но действительно ли ссылки, имеющие кириллические слова будут корректно обрабатываться данной регуляркой(для этого указан флаг /u)?

Улучшил регулярку:
$str = preg_replace('#[^a-zа-яё0-9\s"\/\?&_=-]#ui', '', $str);

(Отредактировано автором: 05 Декабря, 2018 - 18:01:31)

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

Согласен, но в запросы попадают данные из URL, например сортировка, номер страницы, которые нужно обезопасить, так почему бы не экранировать сразу весь URL, а потом уже разбить на составные части и использовать в запросах...

Rinker, вы действительно думаете, что в PDO забыли предусмотреть безопасную передачу данных из пост, гет, и т.п. источников? Я уверен, что вы просто не внимательно читали мануал.

На счёт регулярных выражений - их тут использовать конечно можно. Только зачем? Ради использования регулярных выражений? )

Зачем?

Не шутка. Зачем?
Вы должны корректно использовать значения, а не мифически обезопасить.

Сортировка? Так вы заранее знаете, по чему сортировать можно и в каких направлениях. Вот и проверяйте по белому списку.
Номер страницы? Даже если строить пагинацию отталкиваясь от неверного способа смещения через offset - почему об этом должен беспокоиться роутер? У вас заведомо будет отдельный код, высчитывающий нужные значения окна данных для страницы, где куда уместнее проверка, что номер страницы должен быть числом больше нуля.

https://ru[dot]stackoverflow[dot]com/a/571274/203622
https://ru[dot]stackoverflow[dot]com/q/637185/203622

-----
PostgreSQL DBA

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

Возник немного другой вопрос: регулярка '#[^a-zа-яё0-9\s"\/\?&_=-]#ui' вырезает плохие символы, если они переданы в обычном виде, например "abcd * & = -", но что если символы передадут в виде кодов DEC, OCT, HEX, HTML, например "& # 37 ; & # 39 ; & # 43 ;"(без пробелов), регулярка не вырежет плохие символы?

согласен


Есть у людей интересная особенность: быть уверенными в том что видят причинно-следственную связь там её нет и никогда не было.
Почему вы считаете что эта часть цитаты каким-либо образом связана с предыдущим высказыванием?
И тем паче, при чём тут регулярка?

Не существует мифических плохих символов. Существует безалаберный разработчик, не обеспечивший корректный транспорт или представление полученного значения.
Ещё раз предлагаю прочитать ответы на ruSO, на которые я дал ссылки.

-----
PostgreSQL DBA