Защита от пользовательского ввода текстовой информации

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

(Альтернативным подходом к выполнению htmlspecialchars() при отображении будет запуск strip_tags() на вводе пользователя перед его сохранением в переменной сеанса. Но очистка ввода на display как предложено выше, это более здравый способ мышления, ИМХО.)