Борьба с SQL-инъекциями
CF не более уязвим от такого рода инъекций, чем иной другой язык, поэтому я покажу основы того, как защититься от SQL-инъекций1 при разработке cf-приложений.
Как вообще эти инъекции работают? Хм, ну это просто. Какой-нибудь негодяй может модифицировать GET- или POST-запрос таким образом, что выполнятся либо дополнительные SQL-инструкции, либо вовсе не те, которые должны были. Соответственно, негодник получит доступ к данным, которые предназначены не для его глаз – как правило это приватная информация пользователя или сразу группы оных.
Чтобы проверить ваше приложение еще на уровне разработки, подвержено оно SQL-инъекциям или нет, вы можете воспользоваться чудным и бесплатным к тому же air-инструментом – SQLFury.
А теперь, чтобы понять от чего нам защищаться, давайте поглядим на обычный cf-запрос:
<cfquery name="q" datasource="d"> select * from posts where postsid=#url.id# </cfquery>
Как видно, тут мы пытаемся сделать выборку сообщения, с числовым идентификатором переданным через URL. А что будет, если передать не число, а текст? Правильно – ошибка.
Но, можно модифицировать запрос:
http://localhost/?id=75%union%select%BASE_SCHEMA_VER%as%id,name%as%strmodelname,%name%as%strModelDescription%from%sysobjects
То есть передать такой sql-запрос:
union select BASE_SCHEMA_VER as id,name as strmodelname, name as strModelDescription from sysobjects
И это уже будет не хорошо.
Чтобы хотя бы упредить действия злоумышленника, поменяйте названия таблиц – сделайте их, к примеру, с каким-нибудь префиксом, и чтобы этот самый префикс был отдельной переменной. А еще лучше будет, если вы вовсе замените названия таблиц переменными.
А то может получиться, что вам нечаянно или очень даже чаяно удалять какую-нить таблицу таким вот телодвижением:
http://localhost/?id=57;Drop table posts;
Поэтому рекомендую вам обязательно пользоваться тегом cfqueryparam, который избавит вас от таких штуковин.
Кроме того, делайте элементарные проверки, чтобы вам передавался строго определённый тип данных:
<cfparam name="url.id" type="numeric" default=0>
Кроме того, заведите за правило, выделить опасные слова в отдельную строку, после чего все введённые параметры проверять на отсутствие в них указанных опасных слов. Это избавит вам от 98% таких атак.
Вот вам пример:
<cfset wrongwords="select, insert, update, delete, drop">
А при использовании форм, перво-наперво проверяйте их на реферера, тогда вы будете уверены, что форма и ее данные присланы с вашей страницы, а не из другого места:
<cfif #HTTP_REFERER# IS NOT "<ваш_URL>/writecomment.cfm"> <cflocation url="fuckoff.cfm"> </cfif>
Также, вы можете к сессии и форме прикреплять какое-нить значение, и после проверять соответствие обоих – это также позволит вам избежать проблем.
Ну если будут вопрос – пишите, постараюсь помочь советом.
Спонсор поста: Качественное производство металлоконструкций, строительство ангаров и складов с полной предоплатой.

Февраль 25th, 2009 - 12:20
referer легко подделывается, поэтому проверять его бессмысленно.
Февраль 25th, 2009 - 18:16
Да, подделывается. Но проверку проводить в любом случае полезно.
Май 17th, 2010 - 16:30
Спасибо за совет про SQL убду иметь ввиду