защита от xss и sql инъекций

Два презерватива и чай вместо секса :)

Зачем в одном месте и urldecode и ту же htmlspecialchars?

Первое нужно использовать при вводе данных перед хранением. И там, где оно реально нужно, в параметрах GET-запросов, например. Но не в POST-данных.

Второе нужно при выводе юзеру, опять же, там, где оно нужно.

Ты mysql_real_escape_string забыл :3

По идее правильно так:

При формировании SQL запроса прогонять все параметры через mysql_real_escape_string или аналог для твоей БД.

При выводе значения из БД в HTML прогонять через htmlspecialchars.

Производить html'лизацию текста в БД не следует - мало ли зачем он потом тебе пригодится. К тому же есть риск переусердствовать и вызвать htmlspecialchars дважды - при сохранении и при выводе. Лучше сохранить исходный вид. SQL Injection возможен лишь в момент запроса, в самой БД можно хранить любые данные совершенно безопасно. А вызов htmlspecialchars это задача функции рендеринга страницы, а не сохранения в БД.

Я обычно реализую функцию-обёртку - она принимает переменное число аргументов (не менее 1), для всех аргументов кроме первого проводит mysql_real_escape_string, затем вызывает vsprintf с первым аргументом в качестве формата и всем остальным в качестве параметров. А уже полученную строку отдаёт mysql_query. В итоге можно очень удобно написать:

query('SELECT * FROM pages WHERE id = «%s»;', $_GET['page_id']);

Просто, безопасно, наглядно.

что только не понапридумывают, лишь-бы не делать prepare

и sql инъекций

Возьми PDO.

mysql_real_escape_string

Оно ж deprecated давно было. Что люди не делают лишь бы PDO не юзать.

Это неправильно. Для занесения данных в базу нужно http://phpfaq.ru/slashes , для вывода текста в html страницу - htmlspecialchars, для генерации javascript - json_encode. Заносить в базу данные, обработанные htmlspecialchars тоже неправильно, это нужно делать при выводе на страницу.

Согласен, но с точки зрения вычислений: селектов с результатами на несколько порядков больше чем инсертов. Мы можем аргументы SELECT'a прогонять через htmlspecialchars, и получим готовый вывод. Да, бд будет больше, но зато мы используем htmlspecialchars только при составлении запроса и при вставке строки, а для кучи полей и кучи строк вызвать каждый раз довольно дорого. urldecode возможно лишний наверное стоит оставить для метода escapeGet, а escapePost может обойтись и без него.

PDO разве поддерживается более?

Жизнь PHP-шника — боль.

Prepared statements

Дело не в размере БД. Эти грабли треснут тебя по лбу как только тебе понадобится редактировать через веб-интерфейс содержание этих полей, как только тебе понадобится использовать эти поля еще где-то, кроме html (JS, XML, почта, IM, вывод в консоль, тысячи их).