Меню
Что нового?

Давайте бегло пробежим по вопросам безопасности связанными с заполнением форм...

Camillo

Новичок
Давайте бегло пробежим по вопросам безопасности связанными с заполнением форм...

Привет всем еще раз..
Хотелось бы для себя осветить вопросы безопасности связанные с заполнением форм...
Допустим есть скрипт, который передаёт введенные в нее данные в БД MySQL...
Какие проверки перед отправкой делать?

Мои действия:
- empty(); проверяем содержатся в переменной данные или нет
- strlen(); максимально допустимое кол-во символов для поля
- если в форму вводятся специфические данные (а-ля email) проверяем соответствие с шаблоном регулярного выражения

Всё это я почерпнул из простенькой ознакомительной статьи на этом же сайте :) ...
Подскажите пожалуйста какие еще могут быть проверки или предварительные обработки перед отправкой в БД.

Быть может есть статьи, где этот вопрос затронут более глубоко?

Также интересуют вопросы защиты от SQL Injection через формы...

Защита от повторных (намерянных) отправок данных...

и т.д. и т.п.
будет инетересно абсолютно всё!

Спасибо!

P.S.
Только что заметил что это моё 100ое сообщение на этом замечательном форуме! Хотелось бы поблагодарить всех членов клуба и администрацию проекта за то, что вы такие умные, оперативные, отзывчивые и добрые. За всё время присутствия на форуме - ни разу не услышал плохого слова! Просто класс! Так держать! Спасибо!... сорри за мини оффтоп.
 

Steamroller

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

Camillo

Новичок
Автор оригинала: Steamroller
Ну надо для начала определиться, от чего именно защищаемся.
Если от sql-инъекций - то есть плейсхолдеры, которые эту проблему закрывают.
Если от переполнения буферов (это про strlen) - то это задача не прикладного программиста.
Если проверка поступаемых данных на предмет соответствия бизнес-логике - то для каждого поля определить множество допустимых значений, и проверять при считывании полей из запроса.
Нажмите для раскрытия...
Насчет SQL инъекций почитал вот тут ознокомительную статью http://www.unixwiz.net/techtips/sql-injection.html(правда если честно, то не до конца читал... бегло глазами пробежал - понял в чём суть и решил остановиться...). Первое что приходит на ум - это просто запрет использования кавычек. Это вариант, когда ковычки не нужны при заполнении формы. ( я прав?) А вот если всё же требуется использовать ковычки, то как быть? P.S: Что такое "плейсхолдеры"?

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

Еще такой пример - допустим начинают "атаковать" форму множественными запросами с переменными длиной например в 1Мб... это ж канал может просесть под таким потоком данных....


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

Спасибо!
 

Royal Flash

-=MaestrO=-
if (!get_magic_quotes_gpc()) // Если "магические кавычки не включены"
{
$form_str = mysql_real_escape_string($form_str); // Экранируем все, что может навредить
}

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

Делать так, как сделано на этом форуме (например после ввода данных перенаправлять на другую страницу) я бы не рекомендовал, так как если данные повторно вводятся злонамерено, ничто не помешает нажать кнопку назад в броузере 2 раза... а потом refresh и так 100 раз :)
 
svetasmirnova

svetasmirnova

маленький монстрик
Я за следование простому правилу: проверять все входящие данные на соответствие ожиданиям. А при использовании экранировать по правилам того, что используешь. Например, при записи в файл ([m]file_put_contents[/m]) ничего делать не надо, при записи в MySQL читаем фак про слеши и т.п. Также не давать пользователю возможность выполнять запросы в базу, запуск скриптов из командной строки и т.п. Т.е. если по бизнес-логике надо позволить делать DELETE пусть выберет соответствующее значение в селекте, поле и значение для подстановки в where. (Лучше примера на ночь глядя не придумывается =) )
 

Camillo

Новичок
Во! То что доктор прописал! Огромнейшее спасибо!
Было бы совсем замечательно чтобы ссылок накидали на статьи в которых всё это освещено и чтобы примеров.. примеров как можно больше было бы...
Супер! Даже без статей уже очень информативно!

-~{}~ 11.10.05 02:57:

Фанат, кинь камень в огород, а?
Наверняка знаешь что нить интеррресное в этом вопросе...
 
svetasmirnova

svetasmirnova

маленький монстрик
>Было бы совсем замечательно чтобы ссылок накидали на статьи в которых всё это освещено и чтобы примеров..
Вообще-то это была вот эта книжка: http://ora.akant.ru/books/linux/cgi/index.htm плюс статьи не деталях
 
Войдите или зарегистрируйтесь для ответа.
Сверху