Защита от ввода текстового поля пользователя

Question

Нужно ли мне что-либо делать, чтобы защитить себя от ввода пользователем из текстового поля, когда ввод просто хранится в cookie сеанса?

Im продавая продукты, которые могут быть выгравированы с помощью специального текста. Пользователь «предположил», чтобы ввести текст, который они хотели бы выгравировать в текстовое поле, и этот текст сохраняется в cookie сеанса вместе с элементом, который они выбрали &, некоторые другие данные.

Прямо сейчас, я использую nl2br перед сохранением его в файле cookie сеанса, а затем stripslashes, когда я выводил его обратно на страницу.

Нужно ли мне что-либо делать, чтобы защитить себя от вредоносного кода (т. Е. Htmlentities и т. Д.)?

Спасибо за ваш вход (не каламбур!)

Answer 1

Подтвердите ввод, если вы хотите разрешить определенные символы, такие как az 0-9. Если вам не нужны такие символы, как < и >, тогда проверьте.

Как правило, сохраняйте ввод, когда он был введен, и выполняйте любую обработку до ее печати на странице или другом носителе. При обработке я имею в виду пробег через nl2br() и htmlentities().

Обычно лучше хранить данные в нейтральной форме, то есть не обрабатывать для HTML и т. Д., Потому что вы можете захотеть вывести данные в какую-либо другую форму в будущем, например XML, веб-сервисы, и в этом случае это должно быть обрабатываются по-разному.

Храните его в переменной сеанса, а не в файле cookie. Переменная сеанса хранится на сервере и недоступна браузерами или кем-либо еще. Если вы храните его в файле cookie, его можно подделать, и вам придется повторно проверять ввод каждый раз, когда вы хотите получить к нему доступ, потому что он может быть изменен.

Если вы в конечном итоге храните данные в базе данных, вам нужно будет избежать этого для SQL Injection. Метод этого будет варьироваться в зависимости от того, какая библиотека используется для взаимодействия с базой данных, но параметризованные запросы или подготовленные операторы являются предпочтительными.

Answer 2

Первый самый очевидный шанс для атаки будет прямой ввод HTML. Представьте, что кто-то вводит <script src="http://malicious.com/ddos.js" /> в ваше текстовое поле. Выведет ли ваш PHP-код таким образом, чтобы он запускал код .js?

Во-вторых, как данные попадают на гравер? Наиболее распространенным было бы то, что он хранится в базе данных для последующего использования или может быть отправлен по электронной почте в очередь работы для гравера.

Если вы помещаете в базу данных, вам нужно посмотреть в оболочку, такую ​​как PDO, которая может обрабатывать ввод очистки.

Если вы отправляете по электронной почте его себе или кому-то другому, тогда вам нужно позаботиться о том, чтобы не помещать туда опасную информацию. Я верю, что функция mail() php автоматически отключит $message от внесения изменений в заголовки. http://www.php.net/manual/en/function.mail.php

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

Answer 3

Перед тем, как отобразить переменную в поле textarea, вы должны запустить htmlspecialchars().

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

Все остальные места, где вы показываете переменную, например. в интерфейсе электронной почты или администратора, вы также должны запустить на нем htmlspecialchars().

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

(альтернативный подход к выполнению htmlspecialchars(), на дисплее, будет запущен в strip_tags() на входе пользователя, прежде чем она хранится в переменной сеанса. Но санировать вход на дисплее как предложено выше, является более надежным способом мышления, IMHO.)