Comments 20
Картинки битые.
Интересное решение. Но поможет не всегда и не всем.
Как по-мне, лучше фильтровать данные по мере их поступления. И фильтровать по правилам, которые нужны именно Вам.
имхо подобные PHPIDS системы - это костыли. Система сама должна обеспечивать свою безопасность. А такие штуки прикручивать можно было неколько лет назад, когда ещё не настолько хорошо были освещены различные методы атак на веб-приложения. К тому же централизованная фильтрация очень неудобна.
Вы не внимательно прочитали статью.
1) В начале описано, что это никакая не фильтрация
2) Зачем изобретать собственный велосипед, если можно взять чужую библиотеку и модифицировать для себя (не надо только далее писать, что порой легче написать свое, чем пользоваться чужим)
1) В начале описано, что это никакая не фильтрация
2) Зачем изобретать собственный велосипед, если можно взять чужую библиотеку и модифицировать для себя (не надо только далее писать, что порой легче написать свое, чем пользоваться чужим)
вы злоупотребляете выражением "изобретать велосипед"
если разработчик системы не в состоянии ВАЛИДИРОВАТЬ данные, которые приходят в его приложение, то никакие заглушки не помогут
правило очень простое — знаем какие данные ждем, принимаем и проверяем
удачи
если разработчик системы не в состоянии ВАЛИДИРОВАТЬ данные, которые приходят в его приложение, то никакие заглушки не помогут
правило очень простое — знаем какие данные ждем, принимаем и проверяем
удачи
мой опыт работы показывает, что все предусмотреть не возможно
:-)
:-)
в статье описана "защита" от инъекций
защита от инъекций — валидирование данных
вы всегда знаете какие данные к вам ДОЛЖНЫ прийти
что значит невозможно предусмотреть?
как-то не вяжется это с опытом работы :)
защита от инъекций — валидирование данных
вы всегда знаете какие данные к вам ДОЛЖНЫ прийти
что значит невозможно предусмотреть?
как-то не вяжется это с опытом работы :)
Язвительное замечание. "Все предусмотреть не возможно" - относится к глобальному, а не к данной статье. При долговременной работе приложения безусловно вы переберете практически все варианты использования. Помню курсе на третьем было у нас какое-то приложение, которое по всем описанным на UML сценариям (или не на UML) пыталось построить множество сценариев использования.
По поводу Вашего ответа, до определенного момента времени (выхода расширения filter) многие не понимали какой именно должна быть фильтрация, как и в какой последовательности применять strip_tags,htmlentities,set_type...а чем моя статья не помощь для них, а залезть внутрь посмотреть хотя бы правила. Один известный мне проект, достаточно долго работал, там было огромно количество пользователей, казалось бы все оттестировано, и в один прекрасный день он столкнулся с xss.
По поводу Вашего ответа, до определенного момента времени (выхода расширения filter) многие не понимали какой именно должна быть фильтрация, как и в какой последовательности применять strip_tags,htmlentities,set_type...а чем моя статья не помощь для них, а залезть внутрь посмотреть хотя бы правила. Один известный мне проект, достаточно долго работал, там было огромно количество пользователей, казалось бы все оттестировано, и в один прекрасный день он столкнулся с xss.
поднял вам карму за вредость
А эта штука не может ложно сработать?
Вопрос о производительности сего. Не будет ли по производительней mod_security или snort+snortsam перед веб сервером?
Да, я как-то тоже не сторонник такого рода систем, да и насчет "все предусмотреть невозможно" - тоже имхо неправильная позиция, можно предусмотреть, если специально этим озадачиться, иже введя например доп.абстракцию, одна лишняя функция/метод, в которую отдельно передаются запрос и параметры оного (с последующей обработкой оных) - уже избавляет от проблем с sql-инъекциями, также можно централизовать обработку данных, пришедших с форм, из адресной строки и т.п., да и вообще проверка наличия того "что нельзя" всегда будет уступать проверке на соответствие тому "что можно".
Вышла новая версия PHPIDS 0.5
http://php-ids.org/2008/06/07/phpids-05-has-landed/
Раз развивается проект значит кому то нужно, имхо если бы все производители использовали эту идс, то было бы меньше багов.
http://php-ids.org/2008/06/07/phpids-05-has-landed/
Раз развивается проект значит кому то нужно, имхо если бы все производители использовали эту идс, то было бы меньше багов.
Подключил в один из своих проектов, благодаря статье.
Было большой ошибкой с моей стороны ставить die();
Целый час вдвоём пытались понять почему падает отправка формы.
Довольно быстро поняли, что это из-за отправляемой кавычки.
Но то поле могло содержать кавычку и ничего страшного бы не произошло.
Рыли в сторону падения sql-запроса.
Когда через час я догадался глянуть почту...
В-общем, не ставьте die(). =)
Было большой ошибкой с моей стороны ставить die();
Целый час вдвоём пытались понять почему падает отправка формы.
Довольно быстро поняли, что это из-за отправляемой кавычки.
Но то поле могло содержать кавычку и ничего страшного бы не произошло.
Рыли в сторону падения sql-запроса.
Когда через час я догадался глянуть почту...
В-общем, не ставьте die(). =)
Ок, насколько тяжелее становится запросы? какова вероятность вылета какой нибудь ошибки, если клиент добавит какой нибудь подозрительный линк не ведая про то что он подозрительный, сколько хостеров готовы поменять php.ini?
Sign up to leave a comment.
Intrusion Detection For PHP Applications With PHPIDS