букозавр

Рейтинг
5
Регистрация
19.01.2007
Зингельшухер:
Так вот о чём и речь что вам это понятно а автор топика предлагает просто фильтровать ВСЕ данные и только потом уже с "безопасными" данными работать !!!

Уважаемый Зингельшухер,

может быть я и слегка чересчур резко выразился, но ведь именно Вы начали неконкретные наезды, и мне пришлось дать отпор :p

Что касается спорного вопроса о фильтрации ВСЕХ данных - конечно, данная схема несколько утрирована. Может, вы захотите постить у себя на форуме листинги кодов - в таком случае, конечно, фильтровать на входе все тэги и операторы было бы бессмыслицей. Но это - частный случай, и к нему подход нужен особый. В общем же случае, например если у вас на сайте нет форума, или есть форум - но не для программеров, а для микробиологов, то фильтрация всех входящих тэгов и спецсимволов нисколько не помешает, а наоборот, защитит сайт от вероятного злонамеренного кода.

Зингельшухер:
Именно это и говорит о вашем уровне знаний.

(Не принимайте близко к сердцу, тут нет ничего личного, просто через годик другой сами посмотрите на этот топик и будете смеяться)

Зингельшухер,

давайте по существу и конструктивно, либо идите кидать понты в другое место 🙅

Зингельшухер:
Опасных данных не существует, это миф !!!
Опасность представляют не грамотные программисты которые пихают эти данные куда попало не конвертируя их в необходимый формат (для MySQL это mysql_real_escape_string для HTML это htmlspecialchars и.т.д.)

Существуют, существуют :)

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

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

Для того чтоб полностью исключить XSS и SQL-injction нужно 3 уровня обработки полученных от юзера данных...
1 - stripslashes() в случае если включен magic_quotes_gpc (это не касается безопасности)
2 - mysql_real_escape_string() для строк и intval() для чисел при составлении MySQL запросов (этот шаг для SQL-injection)
3 - htmlspecialchars() и nl2br перед выводом в браузер. (этот для XSS)

По другим пунктам (Правило 1 A, C, D, E) в принципе согласен...

"Хороший тон", "дурной тон" - факторы, высосанные из пальца. Можно руководствоваться ими на приеме у королевы Великобритании, но не при разработке системы безопасности :)

Фильтровать (проверять) все данные на входе необходимо, чтобы обеспечить защиту кода приложения.

В принципе, тут есть два варианта:

1) принимать входящие данные как есть, но при разработке кода приложения следить, чтобы в коде не осталось ни одной лазейки для запуска злонамеренного скрипта. Ни функций типа eval(), ни необъявленных явно переменных, etc. Уследить за всеми тонкостями исполнения кода - задача практически нереальная.

2) Проверять все данные на входе, при этом можно не беспокоиться о коде приложения - все данные, которые он будет обрабатывать, будут уже безопасны.

Спасибо за комментарии, однако кое-какие ключевые вопросы остались непонятны.

Во-первых, Опять же к вопросу о временных (хранящихся в оперативной памяти) и постоянных (хранящихся в файле) cookie. Спецификация IE, например, позволяет использовать и тот и другой тип cookie. Непонятно только, какой тип cookie использует ПХП - временные, постоянные, или оба? Это важно. Однако нигде не описано...

Сервер уровня 1U, Celeron 2.8GHz, 1Gb, 160Gb SATA HDD сможет потянуть? Или придется кластеры наворачивать? :)

100 запросов в течение 0,5 - 1 сек.

По вопросу БД - приходится плясать от того что есть, т.е. от мускула, не постгре не оракл не...

12
Всего: 17