Форум PHP

Cookeis ничего не дают, я например, кода пишу ботов никогда не держу ненужные Cookies.

А поступал я вот как для антифлуда: у меня есть лимит --- пятьдесят модификационных действий в 15 минут с одного IP и 150 модификаций в 30 минут из одной подсети (храню модификации в таблице MySQL), как только лимит превышен, если это с одного IP, то полностью баню его (при этом если в одной подсети более четырёх забаненных IP --- баниться подсеть, об этом позже), а все действия отменяю (у меня был хороший механизм для отмены модификаций). Затем, когда просматриваю базу забаненых пользователей, смотрю, действительно ли он флудер, если произошла ошибка, то извиняюсь и возвращаю всё обратно.

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

И ещё обязательно забаньте сразу все IP всех проксей, какие сможете найти в интернете.

Ну, а если вам нужно всего лишь сдержать, то можете установить таймаут на модификации (например, не более одной в пятнадцать секунд, не более пятнадцати в 15 минут с одного IP, я думаю, это будет вполне разумно, однако, когда будет много посетителей, это число нужно увеличить, чтобы при попадании двух пользователей с одного IP не было лишних недоразумений)

Кроме того на большинство форм я поставил картинку, защищающую от ботов.

>Если включены - экранировать ничего не нужно - об этом заботиться сам сервер,
Это утверждение как минимум неполное.

Если данные, помещаемые в запрос, взялись не из GET POST COOKIE или REQUEST ,
а из любого другого источника - например,
из загруженного пользователем файла
из файла находящегося на сервере, или полученного по FTP
из сокета, curl , imap и других методов получения чужих данных
и так далее!!!!
=-то экранирование потребуется.

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

Именно поэтому этот кошмар (magic quotes) из php6 выкинут.

Данная конструкция определяет включены или отключены магические кавычки - автоматическое экранирование спец-символов в POST-, GET-, COOKIE- данных - они могут быть включены на сервере, а могут быть отключены. Если включены - экранировать ничего не нужно - об этом заботиться сам сервер, если отключены - нужно. Конструкция get_magic_quotes_gpc() и позволяет добиться универсальности при обработке текстовых значений, которые заключаются в кавычки перед помещением в базу данных. Все числовые значения, которые в кавычки, как правило, не помещаются проверяются либо при помощи спец-функций PHP (например, intval()), либо при помощи регулярных выражений.

PS Вы можете ориентироваться на исходные коды этого форума в разделе downloads (все коды тщательно комментированы на русском языке) - в нём защита от SQL-инъекций вылизана.
PPS Функции stripslashes() вообще не должна использоваться в обработке текста перед помещением в базу данных.

Вот в этой теме я как-то сделал попытку раскрыть суть метаморфоза строк на пути от формы ввода к браузеру через БД.
Возможно, Вас заинтересует.
http://softtime.ru/forum/read.php?id_forum=3&id_theme=14355

if (!get_magic_quotes_gpc()) {...}

Что проверяет данная конструкция? Впервые такое вижу. И еще, нельзя ли просто этот код впихнуть в мою функцию? Я стремлюсь к тому, чтобы сделать что-то универсальное и не писать определенную последовательность фильтрации каждый раз, когда я загоняю данные в бд или вытаскиваю из нее что-то. Вобщем, я понял, что делаю что-то не так, а по сему прошу, будьте добры, напишите, чем бы вы фильтровали все данные на входе в БД и чем бы на выходе преобразовывали в нормальное представление. Это форум, очень важно, чтобы вероятность дыры в инъекциях и не только сводилась к минимуму.

Дело в том, что stripslashes() не решает проблему кавычек и нарушения синтаксиса... если вы хотите защититься от SQL-инъекции лучше использовать конструкцию

<?php   if (!get_magic_quotes_gpc())   {     $some_string = mysql_escape_string($some_string);   } ?>

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

function get_safe_string ($some_string) {        $safe_string = trim($some_string);   // Удаляем пробельные символы        $safe_string = stripslashes($safe_string);   // Удаляем обратные слеши        $safe_string = htmlspecialchars($safe_string, ENT_QUOTES);   // Конвертируем спецсимволы в строке в HTML-представление.               return $safe_string;  }

Так проблема решена? Меня больше волнует то, надо ли эту строку прогонять через данный фильтр - строка будет использована для запросов в БД.

Вот этим я бы не пожелал обрабатывать никаких данных. Разве что врагу.
Особенно захватывает дух удаление экранирующих слэшей уже после преобразования (кавычек например) в html-эквиваленты.

И вроде как комментарии стоят.... Значит Вы знаете, что делаете. Тогда почему опять такой компот?

См. задачу 21. В разделе "задачи".

Спасибо. Я потом по этой строке в базе буду искать. Мне надо будет ее обрабатывать вот этим?

function get_safe_string ($some_string) {       $safe_string = trim($some_string);   // Удаляем пробельные символы       $safe_string = htmlspecialchars($safe_string, ENT_QUOTES);   // Конвертируем спецсимволы в строке в HTML-представление.       $safe_string = stripslashes($safe_string);   // Удаляем обратные слеши       return $safe_string; }

echo $_SERVER['QUERY_STRING'];

[поправлено модератором]