Безопасность приложения

Сам по себе Scheduler не содержит встроенных средств защиты приложений от угроз, таких как SQL-инъекции, XSS или CSRF-атаки. Обеспечение безопасности приложения — это, прежде всего, ответственность разработчиков, которые его создают. Бэкенд должен тщательно валидировать, экранировать или очищать все входящие данные и корректно применять правила доступа пользователей.

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

Ниже приведены распространённые типы атак и способы их предотвращения. Как правило, соблюдение лучших практик для CRUD-операций на вашем бэкенде будет достаточным.

XSS-атаки

XSS-атаки могут возникать из-за небезопасных реализаций CRUD на сервере, функций шаблонов Scheduler и пользовательского ввода через интерфейс:

  • API бэкенда, отвечающее за сохранение и загрузку данных Scheduler (которое реализуют разработчики), должно корректно экранировать входные и выходные данные для обеспечения их безопасности. При использовании dhtmlxConnector данные автоматически экранируются и очищаются. Если вы разрабатываете свой бэкенд, необходимо самостоятельно обрабатывать экранирование данных, сохраняемых в базе данных и загружаемых в Scheduler.

Что касается функций шаблонов и lightbox, они становятся уязвимыми только в случае отсутствия очистки данных на сервере. Защита бэкенда, как правило, достаточна для предотвращения XSS-атак, поскольку только клиентские меры неэффективны без надежного сервера.

  • Шаблон выводит содержимое напрямую во внутренний HTML Scheduler без экранирования или предварительной обработки.

Шаблоны предназначены для добавления пользовательской разметки — например, форматированного текста, иконок или кнопок — в элементы Scheduler. Однако это также создает риск внедрения кода. Вы можете переопределить любой шаблон в соответствии с требованиями безопасности вашего приложения.

Related sample:  Template XSS

  • Lightbox не выполняет валидацию пользовательского ввода по умолчанию, что может привести к уязвимости XSS, если этот вопрос не обработан. Подробнее см. в статье валидация на клиенте.

Related sample:  Lightbox XSS

SQL-инъекции

Поскольку Scheduler полностью работает на клиенте, предотвращение SQL-инъекций — задача бэкенда.

Два важных момента:

  • Lightbox не содержит встроенной валидации, поэтому пользователь может ввести любые значения в редактируемые поля, если не реализована собственная проверка.
  • К API бэкенда можно обратиться напрямую через PUT/POST-запросы с вредоносными данными, минуя клиентский интерфейс.

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

CSRF-атаки

При использовании dhtmlxConnector на сервере вы можете включить защиту от CSRF через его конфигурацию. Подробнее читайте в статье о предотвращении CSRF и XSRF-атак.

Если вы не используете dhtmlxConnector, CSRF-защиту необходимо реализовать самостоятельно. Подробнее о добавлении пользовательских токенов или заголовков в запросы Scheduler к вашему бэкенду см. эту статью.

Content Security Policy

Библиотека содержит опцию конфигурации, которая помогает привести ваше приложение dhtmlxScheduler в соответствие со стандартом Content Security Policy (CSP). Это усиливает защиту от различных атак с внедрением кода и повышает общую безопасность приложения.

Подробнее о применении CSP в приложении dhtmlxScheduler.

Наверх