реврайтинг и sql инъекции

[saen]

Зачем мудрить с mod_rewrite, когда ты знаешь какие данные должен получить скрипт и фильтровать их перед запросом в БД

 

[antn]

SQL-инъекций вообще не существует в принципе. Если вы передаёте данные от пользователя прямиком в запрос, без приведения к формату строк языка SQL, значит вы принимаете от пользователя кусок запроса, это не ошибка, это нормальная логика и она может быть применена во благо (живой пример - phpMyAdmin). Другой вопрос, если у вас с логикой проблемы, хотите вставить в запрос строку, принятую от пользователя, а вставляете кусок запроса, принятый от пользователя. Никакие регекспы не нужны, не нужно никаких фильтров и параноидальных функций, достаточно просто следовать правилу:
если передаём данные из одного языка в другой => не забываем применять правила преобразования именно в момент передачи, не раньше и не позже. Это касается и PHP => MySQL (mysql_escape_string), и PHP => HTML (htmlspecialchars), и PHP => RegExp (preg_quote), и любых других направлений.

 

[saen]

SQL-инъекций вообще не существует в принципе. Если вы передаёте данные от пользователя прямиком в запрос, без приведения к формату строк языка SQL, значит вы принимаете от пользователя кусок запроса, это не ошибка, это нормальная логика и она может быть применена во благо (живой пример - phpMyAdmin). Другой вопрос, если у вас с логикой проблемы, хотите вставить в запрос строку, принятую от пользователя, а вставляете кусок запроса, принятый от пользователя. Никакие регекспы не нужны, не нужно никаких фильтров и параноидальных функций, достаточно просто следовать правилу:
если передаём данные из одного языка в другой => не забываем применять правила преобразования именно в момент передачи, не раньше и не позже. Это касается и PHP => MySQL (mysql_escape_string), и PHP => HTML (htmlspecialchars), и PHP => RegExp (preg_quote), и любых других направлений.

Не совсем согласен с тобой по данному поводу.
1) mysql_escape_string не учитиывет кодировку БД, что создает дополнительную головную боль в utf-8 при работе с мультибайтовыми строками.
2) от XSS(как пассивных так и автивных) mysql_escape_string не спасает

 

[antn]

1) mysql_escape_string не учитиывет кодировку БД, что создает дополнительную головную боль в utf-8 при работе с мультибайтовыми строками.

Ну mysql_real_escape_string, суть от этого не меняется.

2) от XSS(как пассивных так и автивных) mysql_escape_string не спасает

Кто бы спорил. Я и пишу о том, что соответствующие функции нужно применять при передаче данных в конкретном направлении. Действитьельно XSS к MySQL не имеет ни малейшего отношения, потому и ф-я mysql_escape_string тут бессильна. XSS возникает при преобразованиях PHP => HTML и PHP => JS, соответственно и спасательными функциями будут htmlspecialchars и addslashes в момент отдачи данных браузеру.

 

[serjinio]

...
RewriteRule ^([A-Za-z0-9_]+)/([0-9]+)$ index.php?url_path=$1&page=$2&key=good123
...
быдлокод. ты при каждом обновлении страницы будешь htaccess перезаписывать? или того хуже у тебя параметр key будет статичным?

интересно, с каких пор, разбор URI апачем (модреврайтом) стал быдлокодом..покажите что ж НЕ быдлокод

 

[baddan]

дает ли это 100% гарантию от инъекций , если данные из форм не вводятся, только запрос через урл

нет не дает

если на сайте стоит реврайт а магик квоте не отключен, то такое запросто проканает

Для просмотра ссылки Войди или Зарегистрируйся

реврайт все переделает сам на

Для просмотра ссылки Войди или Зарегистрируйся

в результате всеравно увидим ошибку

 

[serjinio]

нет не дает
если на сайте стоит реврайт а магик квоте не отключен, то такое запросто проканает
Для просмотра ссылки Войди или Зарегистрируйся
реврайт все переделает сам на
Для просмотра ссылки Войди или Зарегистрируйся
в результате всеравно увидим ошибку

интересно, а как /'100/ проскочит через шаблон /([0-9]+)/$ ???
ошибка будет 404...