Сам по себе Scheduler не содержит встроенных средств защиты приложений от угроз, таких как SQL-инъекции, XSS или CSRF-атаки. Обеспечение безопасности приложения — это, прежде всего, ответственность разработчиков, которые его создают. Бэкенд должен тщательно валидировать, экранировать или очищать все входящие данные и корректно применять правила доступа пользователей.
Имейте в виду, что клиентская валидация легко обходится или поддается манипуляциям, поэтому не должна использоваться в качестве основного средства защиты. Ее основная задача — предоставить пользователю мгновенную обратную связь о некорректном вводе без ожидания ответа от сервера. Окончательная проверка всегда должна выполняться на стороне сервера.
Ниже приведены распространённые типы атак и способы их предотвращения. Как правило, соблюдение лучших практик для CRUD-операций на вашем бэкенде будет достаточным.
XSS-атаки могут возникать из-за небезопасных реализаций CRUD на сервере, функций шаблонов Scheduler и пользовательского ввода через интерфейс:
Что касается функций шаблонов и lightbox, они становятся уязвимыми только в случае отсутствия очистки данных на сервере. Защита бэкенда, как правило, достаточна для предотвращения XSS-атак, поскольку только клиентские меры неэффективны без надежного сервера.
Шаблоны предназначены для добавления пользовательской разметки — например, форматированного текста, иконок или кнопок — в элементы Scheduler. Однако это также создает риск внедрения кода. Вы можете переопределить любой шаблон в соответствии с требованиями безопасности вашего приложения.
Поскольку Scheduler полностью работает на клиенте, предотвращение SQL-инъекций — задача бэкенда.
Два важных момента:
Поэтому ваш бэкенд должен реализовывать меры по предотвращению SQL-инъекций. Если вы используете dhtmlxConnector и настраиваете таблицы согласно документации, все входные данные будут экранироваться автоматически. В противном случае убедитесь, что ваша реализация CRUD соответствует лучшим практикам безопасности выбранной платформы (см. здесь).
При использовании dhtmlxConnector на сервере вы можете включить защиту от CSRF через его конфигурацию. Подробнее читайте в статье о предотвращении CSRF и XSRF-атак.
Если вы не используете dhtmlxConnector, CSRF-защиту необходимо реализовать самостоятельно. Подробнее о добавлении пользовательских токенов или заголовков в запросы Scheduler к вашему бэкенду см. эту статью.
Библиотека содержит опцию конфигурации, которая помогает привести ваше приложение dhtmlxScheduler в соответствие со стандартом Content Security Policy (CSP). Это усиливает защиту от различных атак с внедрением кода и повышает общую безопасность приложения.
Подробнее о применении CSP в приложении dhtmlxScheduler.
Наверх