Comments 21
Мораль сей басни такова: фильтруйте всё, что приходит от пользователя.
Золотое правило: не доверяйте данным которые ввели пользователи!
Все через фильтр )))
Все через фильтр )))
выполнять вредоносный Javascript код на сервере
Именно на сервере?
Возможно, мне кажется, но такие вещи пишут в книжках из серии «PHP для чайников»…
Эта уязвимость позволяет выполнять вредоносный Javascript код на сервере
Эм… Что?
Простите, немного неправильно сформулировал, пофиксил.
Вообще по данным некоей организации Web Application Security Consortium по распространнености после XSS уязвимостей идут уязвимости «утечки информации». О которых в списке самых главных не упомянуто.
Текущая актуальная статистика и классификация с примерами.
Русский перевод 2-х летенй давности
Текущая актуальная статистика и классификация с примерами.
Русский перевод 2-х летенй давности
>Красным и выделена уязвимая строчка.
O_o
O_o
А ещё забыли такую широко распространённую дырку как Cross-site request forgery
ага, куки, спамы, троянские кони
шаман гуру, по-нашему это учитель © Зоопарк
забавные вещи получаются)
по п. 1: не доверять не только данным, приходящим от пользователя, но и данным из БД;
по п. 2: в пыхе есть рекомендуемая функция mysql_real_escape_string(), как раз для того, чтобы данные 100% заносились в БД. кроме того (по поводу where id = '$id'), числа, имею мнение, лучше приводить к виду $id = (int) $_GET['id'];
по п. 3: в принципе, очень похоже на п. 2.
по п. 1: не доверять не только данным, приходящим от пользователя, но и данным из БД;
по п. 2: в пыхе есть рекомендуемая функция mysql_real_escape_string(), как раз для того, чтобы данные 100% заносились в БД. кроме того (по поводу where id = '$id'), числа, имею мнение, лучше приводить к виду $id = (int) $_GET['id'];
по п. 3: в принципе, очень похоже на п. 2.
Используй мод_секьюрити для апача, его так же можно настроит и как прокси сервер, если апач не является твоим веб-сервером, вот ссылочка, на мой блог, я описал базовые принципы — jthotblog.blogspot.com/2009/07/blog-post.html
Лучше всего для защиты от sql-инъекций использовать в приложении prepared statements. Экранирование и фильтрация данных вполне может привести (и приведет) к ошибкам, кроме того это дополнительные сложности при вставке.
В современных фреймворках, ORM использовать prepared statements очень легко. Например, пишем так:
и не задумываемся о том, что хранится в $message_id, $user_id…
В современных фреймворках, ORM использовать prepared statements очень легко. Например, пишем так:
$this->createQuery()->select('session_id')
->where('id = ?', $message_id)
->andWhere('deleted = ?', 0)
->andWhere('user_id = ?', $user_id)
и не задумываемся о том, что хранится в $message_id, $user_id…
мдяяя… так и хочется начать старую волынку про хабр уже не торт = )))
Школьник чтоли писал = )
Школьник чтоли писал = )
Раньше такие статьи публиковали в «Хакере». Хабр поднял упавшее знамя :)
Sign up to leave a comment.
Безопасность web-приложений