#html #node.js #flutter #google-cloud-firestore #google-cloud-functions
#HTML #node.js #флаттер #google-облако-firestore #google-cloud-функции
Вопрос:
В моем приложении flutter довольно много входных данных, в которые пользователи могут добавлять текст. Данные отправляются в облачную функцию и, если они действительны, вставляются в документ firestore. Недавно я столкнулся с очисткой данных и начал задаваться вопросом, должен ли я делать это в своих облачных функциях.
Я прочитал, что функция escape() js узла может это сделать, однако, похоже, она нарушает определенные веб-ссылки, которые могут быть вставлены пользователями.
Кажется бессмысленным экранировать данные только для firestore, чтобы затем удалить их обратно в приложении flutter, чтобы они действительно могли переходить по ссылкам.
Важно ли удалять все данные (например, комментарии и т. Д.), И если да, то какой подход следует применять к проблемным ссылкам URL.
(Иногда я могу просматривать введенные пользователем данные на странице html. Если это также может вызвать проблемы с XSS, пожалуйста, не могли бы вы рассказать мне, как это исправить, кроме экранирования перед отображением)
Спасибо, ребята
Ответ №1:
Недавно я столкнулся с очисткой данных и начал задаваться вопросом, должен ли я делать это в своих облачных функциях.
Единственная безопасная позиция, которую можно занять при написании внутреннего кода, например, с облачными функциями, — никогда не доверять данным, поступающим от клиента. Любые входные данные должны быть проверены или проверены, чтобы избежать опасных действий с вредоносными данными.
Кажется бессмысленным экранировать данные только для firestore, чтобы затем удалить их обратно в приложении flutter, чтобы они действительно могли переходить по ссылкам.
Экранирование является необходимой частью следующих протоколов. Протокол HTTP определяет, какие символы могут и не могут присутствовать в URL-адресе и теле запроса. Что-либо за пределами этого, и данные могут быть отклонены или просто полностью завершиться сбоем.
Важно ли удалять все данные (например, комментарии и т. Д.), И если да, то какой подход следует применять к проблемным ссылкам URL.
Это не просто важно, это необходимо.
Если входные данные вызывают «беспокойство», просто отклоните их, поскольку они могут быть вредоносными.
Комментарии:
1. Это имеет смысл, дуг, я обязательно добавлю проверки ко всем моим входным данным. Есть ли у вас какие-либо идеи, как я должен проверять токены FCM? Кажется, в них есть только дефисы? Будет ли регулярное выражение для букв, цифр и дефисов в любом случае прерываться?
2. Если у вас есть новый вопрос о токенах FCM, пожалуйста, задайте его отдельно в новом вопросе.