Проверка ввода и кодирование вывода

Уязвимости, связанные с внедрением, — SQL, команд, LDAP, XPath и другие — возникают, когда недоверенные входные данные интерпретируются как код. Проверка входных данных гарантирует, что данные соответствуют ожидаемым типам, длине и форматам до их обработки, хранения или возврата.

Проверка по списку разрешённых значений (белому списку) определяет, что IS допустимо: только буквенно-цифровые символы, только целые числа в диапазоне 1–100, только корректные форматы адресов электронной почты. Проверка по списку запрещённых значений (чёрному списку) пытается блокировать известные вредоносные входные данные и всегда остаётся неполной. Предпочитайте списки разрешённых значений.

Проверка на стороне клиента улучшает взаимодействие с пользователем, но не обеспечивает никакой безопасности — злоумышленники легко обходят её с помощью инструментов разработчика браузера или curl. Всегда выполняйте проверку на стороне сервера. Клиентская проверка — это удобство, серверная — средство защиты.

Числа: проверяйте тип и диапазон. Строки: проверяйте длину и набор символов. Даты: выполняйте строгий разбор, проверяйте диапазон. Файлы: проверяйте расширение AND магические байты/тип MIME — никогда не доверяйте только расширению. URL: разбирайте и проверяйте схему, узел и компоненты пути.

Самый важный результат проверки входных данных для баз данных — никогда не подставлять пользовательский ввод путём конкатенации в SQL. Используйте параметризованные запросы (подготовленные выражения), передавая пользовательский ввод как параметр, а не вставляя его в строку запроса.

Одна и та же строка требует разного кодирования в зависимости от контекста. Тело HTML: кодирование HTML (< > &). Атрибут HTML: кодирование атрибутов HTML. JavaScript: экранирование JS. Параметр URL: кодирование URL (процентное кодирование). Использование неправильного кодирования оставляет уязвимости, которыми пользуются злоумышленники.

Никогда не вставляйте пользовательские данные непосредственно в HTML. Используйте движок шаблонов или библиотеку, автоматически экранирующую HTML. В React выражение {value} безопасно; dangerouslySetInnerHTML отключает экранирование. В Django шаблоны автоматически экранируют данные, если явно не используется фильтр safe.

При вставке данных в JavaScript, например в переменную, инициализированную пользовательскими данными, кодирования HTML недостаточно. Используйте кодирование JSON: JSON.stringify(value). Это предотвращает выход данных за пределы контекста строкового литерала JS.

Данные, предоставленные пользователем и вставляемые в URL, необходимо кодировать в процентах с помощью encodeURIComponent() (JS) или urllib.parse.quote() (Python). Некодированные данные могут изменять структуру URL, что приводит к открытым перенаправлениям или обходу пути.

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

DOM XSS возникает, когда JavaScript считывает данные из источников, контролируемых атакующим (location.hash, document.URL, cookie), и записывает их в опасные приёмники (innerHTML, document.write, eval). Проверьте все потоки данных от API браузера к приёмникам DOM с помощью инструментов статического анализа.

Почему проверка входных данных на стороне сервера необходима даже при реализации проверки на стороне клиента?

Проверка входных данных (списки разрешённых значений, проверка типов, ограничения длины) в сочетании с контекстно-зависимым кодированием вывода (HTML, JS, URL, параметризация SQL) — основная защита от атак с внедрением и XSS. И то и другое необходимо применять на стороне сервера без исключений.