Здравствуйте коллеги!

Мне сложно сформулировать вопрос, поэтому и найти на него ответ в поиске форума я не смогу... 

Хочется узнать с вашего опыта в данной области. Как максимально обезопасить форму от недоброжелателей и взломщиков. Т.е. это проверка на валидность/корректность и на вредоносность введенных данных. Какие меры предпринять, чтобы избежать неприятностей. Пример: ограничить макс. кол-во символов для ввода номера телефона. Например не более 10. Проверка на e-mail - простенькая и так же с ограничением. Например не более 100 символов. А вот как обработать текст правильно?? Чтобы избежать таких символов, как ; или проигнорировать скрипт или другие возможные варианты... Надеюсь вы понимаете о чем идет речь... Буду рад от вас услышать хотя бы советы или код. Спасибо.

Это сообщение отредактировал(а) linuxoid - 3.7.2009, 18:19

Ничего не надо "обезопасивать", никакие данные из формы не могут быть опасны, опасно не правильное их использование...

Подробности: http://phpfaq.ru/slashes

используй в обработчике функцию preg_match
И ей передавай регулярные выражения проверки на корректность данных.

1. register_globals = off
2. эскейпить входные данные если ожидается строка - mysql_escape_string();
3. фильтровать теги
4. если ожидается число - приводить его к нужному типу - intval(); floatval();

одним словом - все шо подставляется в запрос, необходимо обрабатывать

patap, вредные советы ?


Тогда давайте ещё дальше пойдём, отменим любой пользовательский ввод. В прочем о чём это я, давайте лучше вообще не будем использовать РНР и будем делать сайты только в статике...

Хотя нет зачем, давайте вообще выключим компьютеры, нет компа нет проблем )))



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

Или вот

допустим есть такое


почему нельзя сделать так 


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



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


Это сообщение отредактировал(а) patap - 3.7.2009, 23:09

linuxoid, юзай регулярки. Вот например регулярка для e-mail:



А вообще вот эта комбинация защитит тебя от хакерских атак типа SQL-injection и XSS:

Ага защитит, а за одно защитит твой сайт от посещений пользователями ))) (точнее один раз может случайно из поиска зайдут, но на этом пожалуй и всё)

Ребята вопрос на засыпку...

Вот я например пишу: "format c:" странно, но сервер на котором работает vingrad.ru почему-то не форматнулся... Посмотрите HTML-код этой странички, фраза "format c:" не отфильтрована и не конвертирована, это так сильно повлияло на безопасность ?

Данные надо обрабатывать не в зависимости откуда они пришли, а в зависимости куда они уйдут ! ©

не вижу связи посещаемости сайта с защитой от ввода некорректных данных в формы.
Приток пользователей с поисковиков зависит от качества внутренней и внешней оптимизацией.

А данные фильтруются, чтоб какой-нибудь "продвинутый юзер" не дропнул тебе все таблице в БД с помощью SQL-INJECTION 

Это сообщение отредактировал(а) zetxi815eb - 4.7.2009, 00:53

Я привёл пример

Я могу написать в эту самую форму (в которую пишу сейчас) опасные данные вроде
format c:
' or 1=1
и прочие...
даже
<?php system('format c:');?>
или
<script>alert(document.cookie)</script>

Ничего из этого не вырезано и не фильтрованно, всё отображается и никаких угроз безопасности нет...

Дальше думайте сами...



И не увидите, если у вас в в блоге фильтруются комментарии то дельные комментарии никто запостить и не сможет (их просто отфильтрует автомат)

 НЕТ.
Эскейпить данные нужно ПРЯМО перед запросом. Как правило современные интерфейсы делают это за тебя и самому ничего не надо эскейпить.
Не нужно юзать устаревние mysql_*

 А еще лучше делать так: $text = 'испорченный текст';
Столько же смысла.
Если кто не понял - то я стебусь над нелепым кодом.

 http://www.php.net/manual/ru/ почитай на досуге. Увидишь ;)
Я серьезгно - твой уровень знаний очень низок. Если ты не будешь воппринимать мою фразу в штыки - то я объясню, почему.

morfus, сам сначала бы посмотрел исходный код страницы

до абсурда, конечно, доводить не надо, но есть определенные действия которые нужно делать. Эскейпить символы ПЕРЕД запросом, следить за тем, чтоб тэги, которые ввел пользователь не вывалились в чистом виде на страницу и т.д.

nerezus, в качестве офтопика - а почему цитаты без привязки к имени пользователя? Вроде бы в Хроме уже действуют "быстрые цитаты", еще есть какой броузер?

Хм, как-то не задумывался о такой фишке =)

Стебаешься? Может лучше объяснишь по конкретней? А то дал ссылку на мануал, а толку.. Тоже говорит об уровне...

Мне понравился ваниант с htmlspecialchars() и mysql_escape_string(utf8_encode()) вместо addslashes(), но многие тут судя по всему не согласны с этим. Объясните плиз почему??

Из того же мануала: 



Я вижу такой вариант применения. Сначала пропускаем текст через trim(), htmlspecialchars(), потом pg_escape_string(utf8_encode()) и вставляем в базу?? Если нет, то обоснуйте свою позицию, как лучше сделать. Спс.



Это сообщение отредактировал(а) linuxoid - 5.7.2009, 13:01

nerezus, я что-то пропустил? Эти функции уже устарели? А какие новые?

P.S. Не сарказм, действительно интересно..

webevt, Библиотек, которые "за тебя" сделают mysql_real_escape_string дофига. Я пользуюсь библиотекой DbSimple от Котерова и очень доволен, тут тебе и трассировка запросов и подсчет времени исполнения... Однако, когда мне приспичило сделать 6000 запросов в цикле, и я начал профилировать получившийся тормозной кисель, выяснилось, что на полезности и вкусности в таких фреймворках тратится довольно много рессурсов. Когда я честно преписал "циклический" запрос на "чистый" mysql_query, для 6000 запросов в цикле результат меня просто поразил...

Это я про то, что DB-обертки, конечно, очень помогают жить, но нужно понимать, что в некоторых случаях, их магия может мешать...

Как бы есть mysqli и pdo, которые 
1) Безопасность. Можно не бояться забыть заэскейпить данные.
2) Можно использовать все возможности мускула типа курсоров.
3) ООП.
4) Через них работают Zend_Db и т.д.

Добавлено через 1 минуту и 23 секунды
 Странные выводы делаешь o_O
Вместо уменьшения числа запросов до десятка ты решил убить удобство. Не понимаю такого.

Добавлено через 2 минуты и 51 секунду
ksnk, эм, ты говоришь про обертки, а я - про mysqli и pdo.
Так вот, на каких это основаниях они должны быть медленнее?

Это не надстройка, а просто продуманная и удобная альтернативная либа.

нашел интересную информацию:



Т.е. получается так, как я написал выше - делать ненадо... т.е. надо просто сделать trim() и mysql_real_escape_string или mysqli_escape_string() перед вставкой, а при выводе данных, если нужно, делать htmlspecialchars() ?

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

nerezus, в mysqli автоматический escaping параметров достигается комбинацией prepare-bind-execute? В таком случае, у Котерова несколько удобнее сделано "приведение типов". Тип параметра (квотить+ескейпить/неквотить), указывается в самом теле запроса, и сам запрос с параметрами - одна функция, а не размазан по 2-м строчкам.

и 

Ну, конечно, да. Mysqli, который требует отдельной установки своего расширения вряд ли будет сильнее тормозить, чем чистый mysql. Да и PDO, который начинается с 5-го PHP, тоже тормозить, по идее, не должен...

 Спорим на деньги?)
А все потому, что ты использовал обертку к устаревшей библиотеке.
1) pdo поддерживает multiply statements. mysql не поддерживает.
2) LOAD DATA INFILE для особо крупных вставок.
3) Отсутствие смысла делать кучу инсертов многократно.


 Можно сделать обертку через наследование и ~6 строк на php для аналогичной процедуры. Но нет смысла.

nerezus, Можно и поспорить ;-) Я посажу тебя на свой хост с php4 и mysql3, и посмотрим как будут вставляться туда PDO'шные классы... 

А схему вставки я переделал через неделю после разборок с SimpleDb. Просто тупо вклеивал недостающие поля в массив, после чего получился один (~10 кил) запрос на вставку...

 А почему сразу не на pure html 1.0?

php4 умер более чем 2 года назад, а юзающие его - некрофилы.

И ты уверен что он на него сядет ?

Ребята побазарьте в сторонке... жесткий офтоп пошел... :/

linuxoid, так какая база данных у тебя? postgres или mysql?

У меня постгрес. Исходя из того, что я здесь прочел и нашел полезного в интернет, вывод сделал такой:




Что думаете по этому поводу?

magic_quotes специально, блин, отключили, чтобы их не проверять - так нет же, свою функцию пишут.
Правильно работать с ней так: предположить ее значение как false.

Если по какой-то причине она true, то выключается через настройку в панели хостинга. Либо через .htaccess.
Но уже стоит подумать о таком хостинге плохо при этом.

По-моему, в интернете ты нашел кучу бесполезного.
function prepareData работать не будет в таком виде.
почему у тебя stripslashes выполняется два раза, а trim - даже три? одного разве не достаточно?

Потому что я не использую сразу все ф-ии из тех, что я написал.  Каждая используется в соотв-х обстоятельствах.. stripslashes, по идее вообще не нужно делать, когда берем данные из базы...

В общем если бы я сейчас получил из формы текст, который нужно вставить в базу, то я бы его пропустил через prepareText(). Т.е. делаем трим и эскейп 
А если нужно было бы его вызвать из базы и показать на экране, то воспользовался бы этой ф-ей...