возможно опасная обработка ввода текста

Question

Я ознакомился с SQL-инъекцией, XSS и другими проблемами безопасности и пытаюсь выяснить, что использовать для защиты сайта компании.

Мы собираемся развернуть простую форму «Обратная связь с пользователем» с текстовой областью, чтобы пользователи могли рассказать нам, как улучшить сайт, чтобы улучшить их пользовательский опыт.

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

Команда не беспокоится о проблемах безопасности здесь, но я. Они думают: «Мы создаем имя файла, оно равно 0% на основе любого пользовательского ввода, и, поскольку мы пишем это имя« UserX comments »и путь к базе данных без прямого влияния пользователя - риска нет».

Меня не беспокоит активность базы данных - поскольку они правы, пользователь не играет роли в том, ЧТО мы записываем в их записи базы данных, поскольку мы просто создаем собственное имя файла и сохраняем его в своей записи в БД.

Меня беспокоит текстовый файл!

Поэтому я обращаюсь к нашей небольшой команде с просьбой переписать код, чтобы использовать безопасность для чтения, а затем записать комментарии пользователя в текстовой области в текстовый файл.

Я обеспокоен тем, что - поскольку мы планируем действительно ПРОЧИТАТЬ отзывы наших пользователей и открыть эти текстовые файлы, чтобы прочитать их позже - в текстовой области могут быть плохие вещи, которые (если мы не очистим их) могут как-то навредить нам.

Я настаиваю на том, что мы используем strip_tags (), но мне нужно проинформироваться о том, как мы очищаем ввод textarea - я думаю, что strip_tags () - это то, что нужно, но я на 100% нов для дезинфекции ввода пользователя. Я посмотрел на htmlspecialchars (), но он просто конвертирует некоторые символы, такие как '&' в & и пр.

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

Answer 1

Если вас не беспокоит внедрение SQL-кода, и, похоже, это не так (либо потому, что вы знаете, что SQL-файл очищен, либо потому, что вы сохраняете в текстовый файл), тогда другая проблема - возможная атака XSS..

Это легко игнорировать, они не влияют на вас напрямую.Атака XSS - это атака, которая позволяет внедрить клиентские сценарии в веб-страницу.Ваша база данных работает нормально, файлы вашего сервера не изменены, файлы сеанса также не изменены.

Эта уязвимость полностью на стороне клиента.Как я уже сказал, это не влияет на ваш сервер.Но затем кто-то (т.е. я) заходит на ваш сайт, и внезапно перенаправляется на сайт Warez при просмотре полностью SFW, доверенного сайта.Вы теряете доверие со стороны своих пользователей.Поисковые системы, просматривающие ваш сайт, также помечают вас как потенциально вредных.Вы теряете трафик.Вы теряете доходы.Опять же, с вашим сервером все в порядке.

Вы определенно должны очистить пользовательский ввод , который выводится обратно пользователю из-за этого.Да, strip_tags - это решение, а htmlspecialchars или htmlentities.

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

В заключение, вы абсолютно правы в том, что настаиваете наэта практика.Это не влияет на вас (то есть на сервер вашей компании) напрямую, но в какой-то момент это повлияет на вас, если вы хотите, чтобы ваше присутствие в Интернете было надежным.

Я знаю, что это может быть более длинный ответ, чемдругие, которые должны предложить просто strip_tags.Они абсолютно правы, поэтому я проголосовал за них.Просто пытаюсь дать вам некоторые "корпоративные" аргументы там.:)

Answer 2

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

Answer 3

Это зависит от того, как вы создаете файл и что вы делаете с текстом после его прочтения.

Если вы используете собственные функции PHP для записи файла, у вас не должно возникнуть проблем с удаленным выполнением кода .

Если все, что вы делаете после прочтения, это отображение пользователю через HTML, то htmlentities () , который эффективно делает HTML-теги внутри текста бессильными, но при этом корректно отображается для пользователя.

Если вы используете его как часть какого-либо запроса к базе данных, вам следует использовать эту процедуру очистки базы данных, прежде чем объединять ее с вашим SQL. (т. е. mysql_real_escape_string () для MySQL или pg_escape_string () для PostgreSQL).

Вы также можете взглянуть на некоторую информацию на странице OWASP .

Редактировать : Я забыл упомянуть, вы также должны использовать ENT_QUOTES с htmlentities для предотвращения инъекций одинарных кавычек.

Answer 4

просто используйте mysql_real_escape_string (), чтобы избавиться от кавычек. htmlentities (), если вы беспокоитесь о файлах js. Это должно быть примерно так же хорошо, как и там.

Answer 5

У меня есть решение, которое соответствует основной идеологии вашей команды разработчиков:
Не используйте никакие авторизации пользователей на вашем сайте, включая администраторов.Таким образом, XSS не причинит вам вреда.

Answer 6

Обеззараживающий ввод защищает только от SQL-инъекций, удаляя определенные символы. Эти символы, однако, не могут действовать злонамеренно из текстового файла. Я знаю немного о вредоносном ПО и, поверьте мне, вы здесь не рискуете.

Edit:

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