Почему проверки на стороне клиента недостаточно?

любой, кто знает базовый JavaScript, может обойти клиентскую сторону.

клиентская сторона используется только для улучшения взаимодействия с пользователем (не нужно перезагружать страницу для проверки)

При написании серверного приложения существует простое правило: Никогда не доверяйте пользовательским данным.

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

Проверка на стороне клиента предназначена для защиты клиента от ввода неверных данных. Проверка на стороне сервера предназначена для защиты сервера от обработки неверных данных. В процессе это также вводит некоторую безопасность в процесс отправки.

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

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

Веб-сервер «слушает» и получает HTTP-запрос , содержащий данные от браузера, а затем обрабатывает его.

Злоумышленник может отправлять злонамеренные HTTP-запросы разными способами. Браузер даже не требуется.

Проверка на стороне клиента, выполняемая с помощью JavaScript в браузере, является важным улучшением пользовательского интерфейса для удобства использования. Но он не предотвращает отправку злонамеренных данных пользователем, который знает, как обойти стандартное поведение браузера при создании HTTP-запроса, который будет отправлен на сервер. Это можно сделать легко с помощью некоторых плагинов браузера, используя cURL и т. Д.

На случай, если злоумышленники разместят свою анкету.

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

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

Потому что агент пользователя (например, браузер) может быть поддельным. Очень легко создать пользовательское приложение для создания HTTP-запроса с произвольными заголовками и содержимым. Оно может даже сказать, что это настоящий браузер - у вас не будет возможности отличить его.

Все, что вы можете сделать, это посмотреть на содержимое запроса, и если вы не проверите его, вы не узнаете, что он действителен".

Не будучи специфичным для Javascript и веб-клиентов и рассматривая вопрос более широко, сервер должен отвечать за поддержание своих собственных данных (в сочетании с базой данных).

В среде клиент-сервер сервер должен быть готов к тому, что с ним может общаться множество различных реализаций клиентов. Рассмотрим систему ввода торговых данных. Клиентами могут быть графические интерфейсы (например, системы ввода сделок) и (скажем) клиенты загрузки данных (загрузка нескольких сделок из файлов .csv).

Проверка клиента может быть выполнена множеством различных способов, и не все они корректны. Следовательно, сервер не обязательно должен доверять данным клиента и сам выполнять проверку целостности и валидацию.

Вы можете отключить/редактировать JavaScript.

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

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

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

В целом, КАЖДОЙ части приложения лучше всего выполнять собственную проверку/проверку.

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

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