#javascript #node.js #validation #frontend #backend
#javascript #node.js #проверка #интерфейс #серверная часть
Вопрос:
У меня вопрос о проверке форм в JS. Я знаю, что большая часть входных данных приложения должна проверяться на стороне сервера, но если вы также сделаете это на стороне клиента, вы избежите ненужных запросов к серверу.
С другой стороны, логика проверки ваших данных будет раскрыта в вашем клиентском коде (на мой взгляд, будет больше шансов обойти безопасность приложения), а также будет повторение кода (на сервере и клиенте) и двойная проверка, все ли правильно, что являетсяне лучшая производительность.
Существует ли какой-либо стандарт?До сих пор я делал все это в бэкэнде, но мне это немного любопытно.
Я был бы очень признателен за предложение (список плюсов и минусов, если необходимо) опытного программиста.
Спасибо.
Комментарии:
1. Я не думаю, что это основано на мнениях, я прошу стандарты и список плюсов и минусов, просто чтобы сделать это как можно лучше.
Ответ №1:
Киберпреступники могут атаковать ваши серверные приложения с помощью вредоносно созданных запросов. Для этого им не нужно использовать ваш код на стороне клиента, вместо этого они могут взломать свои собственные сценарии на стороне клиента. Поэтому ваш серверный код ДОЛЖЕН выполнять всю проверку, необходимую для защиты вашего приложения от атак. Он НЕ МОЖЕТ полагаться на проверку на стороне клиента для обеспечения безопасности и целостности.
Ваше клиентское приложение также может проверять свои входные данные. Например, он может предупреждать пользователя, если он вводит свое имя в поле даты или допускает другие подобные ошибки. Вы делаете это из уважения к своему пользователю, чтобы упростить использование вашего приложения.
Комментарии:
1. Итак, подводя итог, на стороне клиента мы можем выполнить некоторые части проверки, которые также выполняются на стороне сервера (поскольку js может быть отключен пользователем), просто чтобы быстрее предоставлять обратную связь клиенту?
2. Совершенно верно. Прочитайте OWASP, чтобы узнать больше о проверке сервера и киберпреступлениях.
Ответ №2:
Я не настолько опытен, но мое мнение таково, что я бы проводил проверку на стороне клиента в основном, только если это влияет на пользовательский интерфейс / UX. Это может быть что-то, касающееся разрешений, поэтому пользовательский интерфейс может отключить некоторые вещи, например. Другим аспектом является тип данных, он может быть ограничен на стороне клиента, но это не проверка.
Комментарии:
1. Да, до сих пор я делал что-то подобное. Я не проверяю типы данных, я делаю это и на стороне сервера, но если, например, есть действие, которое предназначено только для разрешенных премиум-пользователей, я делаю это в клиенте, просто чтобы предупредить пользователя как можно быстрее.
Ответ №3:
Здесь вы можете найти список наиболее распространенных уязвимостей информационных систем. Если вы не выполняете проверку на стороне FE, существует риск XSS-атак. С другой стороны, если вы не выполняете проверку на стороне BE, существует риск внедрения, раскрытия конфиденциальных данных и т. Д.
Итак, подводя итог моей мысли, я думаю, что лучше всего было бы проверять с обеих сторон.
PS это всего лишь мое личное мнение, и я младший разработчик.
Комментарии:
1. Почему интерфейсные проверки позволяют избежать атак XSS? Я имею в виду, если клиентским кодом можно манипулировать, не безопаснее ли проверять данные с помощью регулярных выражений на стороне сервера, а затем отправлять администратору электронное письмо, например, с IP-адресом хакера? (Не уверен)
2. Если злоумышленник может каким-либо образом изменить структуру DOM, это атака XSS. В <script> can be stored let’s say in the js variable, and then in some point, you need to show what’s inside the variable, and that’s when the script would be executed. Если вас беспокоит только DB, возможно, можно проверять только на стороне сервера.
3. Проверка на стороне клиента — это, по сути, сахар удобства использования. Злоумышленник может легко изменить или обойти любую введенную вами проверку. Проверка серверной части служит целям безопасности — не позволяет выполнять запрос, который является недействительным. Итак, как правило, вам нужны оба варианта, но внутренние проверки критически важны для безопасности и должны быть тщательно протестированы и надежны.