Защита от SQL-инъекций, XSS и CSRF на сайте 1С-Битрикс

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

Разберём по порядку, что каждая из них делает. SQL-инъекция возникает, когда запрос к базе данных собирается из строки и данных пользователя без проверки. Подставив в поле ввода или адрес кусок SQL, атакующий заставляет базу выполнить чужую команду: прочитать чужие заказы, выгрузить базу клиентов, обойти авторизацию. XSS (межсайтовый скриптинг) появляется, когда данные пользователя выводятся в HTML без экранирования — внедрённый скрипт исполняется в браузере другого посетителя и крадёт его сессию или данные. CSRF (подделка запроса) заставляет уже вошедшего пользователя незаметно выполнить нежелательное действие: сменить пароль, оформить заказ, удалить данные. У всех трёх разные точки входа, но общая причина — слепое доверие к данным пользователя.

Чем мы закрываем эти уязвимости

Каждая уязвимость лечится своим средством, и все они есть в арсенале ядра Битрикс. SQL-инъекции закрываются параметризацией запросов и переводом самописного SQL на API ядра — современный слой данных D7 строит запросы безопасно, экранируя и параметризуя значения автоматически. XSS закрывается экранированием вывода по контексту (HTML, атрибут, JavaScript, URL) и политикой Content Security Policy, которая запрещает браузеру исполнять посторонние скрипты. CSRF закрывается токеном bitrix_sessid: он добавляется в формы и AJAX-запросы, а на сервере проверяется функцией check_bitrix_sessid, поэтому подделанный со стороны запрос отсекается.

Главные направления работы по защите от классических уязвимостей:

• параметризация SQL-запросов и перевод самописного кода на API ядра вместо склейки строк;
• экранирование вывода данных пользователя по контексту для защиты от XSS;
• настройка Content Security Policy против исполнения чужих и инлайновых скриптов;
• защита форм и AJAX токеном bitrix_sessid с серверной проверкой против CSRF;
• серверная валидация ввода и приведение типов по белому списку формата;
• безопасная загрузка файлов: контроль типа, размера и содержимого, хранение вне исполняемой зоны.

Кому нужна защита от SQLi, XSS и CSRF

Услуга нужна любому сайту на Битрикс, где есть самописный код, формы, личные кабинеты или загрузка файлов — то есть практически всем коммерческим проектам. Особенно остро это стоит для интернет-магазинов с фильтрами каталога и поиском, B2B-порталов с кабинетами контрагентов, сайтов услуг с заявками и калькуляторами, а также любых проектов, которые принимают и хранят персональные данные клиентов. Чем больше точек ввода и самописной логики, тем выше шанс, что где-то запрос склеен из строки, вывод не экранирован, а форма работает без токена.

Отдельный сигнал к срочной проверке — если сайт уже сталкивался с подозрительной активностью: спам через формы, странные записи в базе, неизвестные файлы в папках, предупреждение браузера или поисковика о вредоносном коде. Это часто следы эксплуатации именно классических уязвимостей. В таком случае устранение SQLi, XSS и CSRF нужно сочетать с удалением последствий взлома, чтобы не только закрыть дыру, но и убрать то, что через неё уже проникло.

Как устроена работа и почему чиним в коде

Многие пытаются закрыть уязвимости фильтром на входе — антивирусом или WAF. Это полезный дополнительный слой, но он лечит симптом, а не причину: отсекает известные шаблоны атак и обходится нестандартной нагрузкой, тогда как сама уязвимость остаётся в коде. Мы идём другим путём — устраняем корень. Сначала находим опасные места: прямой SQL, неэкранированный вывод, формы без токенов, небезопасные загрузки. Затем ранжируем находки по риску и начинаем с того, что реально эксплуатируется и ведёт к утечке или захвату сайта. После этого закрываем каждую уязвимость штатным средством ядра и перепроверяем правки сценариями атак, убеждаясь, что функциональность не пострадала.

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

Когда речь заходит о SQL-инъекциях, XSS и CSRF, у бизнеса обычно возникает соблазн закрыть проблему быстро и снаружи: поставить антивирус, подключить WAF, включить облачный фильтр. На бумаге это выглядит проще и дешевле, чем разбираться в коде. Но классические уязвимости живут именно в коде, и фильтр на входе их не лечит — он лишь отсекает часть известных атак. Ниже разбираем, чем это отличается, почему мы чиним корень и как строим работу так, чтобы сайт перестал быть лёгкой добычей.

Почему классические уязвимости так опасны

SQLi, XSS и CSRF — это не редкие узкоспециальные дыры, а массовые уязвимости, которые сканеры и боты ищут на любом сайте автоматически. Им не нужен целевой интерес именно к вашему бизнесу: достаточно, чтобы где-то нашёлся склеенный запрос, неэкранированный вывод или форма без токена. Через SQL-инъекцию выгружают базу клиентов и заказов, обходят авторизацию, иногда захватывают сайт целиком. Через XSS крадут сессии посетителей и подменяют содержимое страниц. Через CSRF выполняют действия от лица вошедших пользователей. И всё это — на коде, который годами работал и казался надёжным, просто потому что им никто не интересовался.

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

Чем фильтр на входе отличается от исправления в коде

WAF и антивирус работают по принципу распознавания: они смотрят на входящий трафик и отсекают то, что похоже на атаку по известным шаблонам. Это полезный слой, особенно против массовых ботов, и мы не отговариваем от него. Но у него два принципиальных ограничения. Во-первых, он лечит симптом, а не причину: уязвимость остаётся в коде, и достаточно нестандартной нагрузки, чтобы её обойти. Во-вторых, он не знает контекста вашего приложения — что для одной формы нормально, для другой атака. Поэтому фильтр либо пропускает изобретательные атаки, либо ложно блокирует легитимных пользователей.

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

Как мы находим и закрываем SQL-инъекции

Начинаем с самописного кода: фильтры каталога, поиск, выгрузки, отчёты, личные кабинеты — везде, где запрос к базе может собираться из строки с данными пользователя. Находим такие места и переводим их на параметризацию и API ядра. Современный слой данных D7 строит запросы безопасно: значения экранируются и параметризуются автоматически, и подставить SQL в них уже нельзя. Если прямой запрос по какой-то причине неизбежен, используем штатные методы экранирования соединения с базой. После правок инъекция перестаёт быть возможной не потому, что мы поймали конкретную атаку, а потому что данные больше не попадают в тело команды. Если устранение инъекций нужно делать в рамках более широкой проверки, мы совмещаем его с анализом и поиском уязвимостей, чтобы увидеть всю картину сразу.

Как мы закрываем XSS

XSS лечится в двух плоскостях. Первая — экранирование вывода: проходим по всем местам, где данные пользователя попадают на страницу, и экранируем их правильным для контекста способом. Для HTML один способ, для значения атрибута другой, для вставки в JavaScript третий, для URL четвёртый — смешивать их нельзя, иначе защита дырявая. Особое внимание уделяем админке и кабинетам, где скрипт исполнился бы в сессии с высокими правами. Вторая плоскость — Content Security Policy: настраиваем заголовки так, чтобы браузер не исполнял посторонние и инлайновые скрипты, даже если они каким-то образом попали на страницу. Получается два рубежа, которые дополняют друг друга.

Как мы закрываем CSRF и проверяем ввод

CSRF закрывается токеном bitrix_sessid. Мы добавляем его в формы и AJAX-запросы, которые что-то меняют, и проверяем на сервере функцией check_bitrix_sessid. Сторонний сайт не знает токена и не может подделать запрос. Параллельно проверяем права: действие должен выполнять именно тот пользователь, у которого они есть, иначе CSRF превращается в обход доступа. Поверх токенов добавляем серверную валидацию ввода — проверку по белому списку формата и типа. Токен подтверждает, что запрос настоящий, валидация — что данные корректны, экранирование — что вывод безопасен. Эти три механизма работают в связке и закрывают большинство сценариев атак на формы.

Загрузка файлов и сопутствующие риски

Отдельная и часто недооценённая зона — загрузка файлов. Если форма принимает любые файлы и кладёт их в исполняемую папку, через неё заливают веб-шелл и получают контроль над сервером. Мы ограничиваем разрешённые типы и размер, проверяем реальное содержимое файла, а не только расширение, храним загрузки вне исполняемой зоны и запрещаем выполнение скриптов в этой папке. Заодно проверяем, нет ли уже залитого шелла, и при необходимости подключаем устранение уязвимостей и последствий, если сайт уже пострадал. Рядом с загрузками часто всплывает IDOR — доступ к чужим объектам по подменённому идентификатору; такие места мы тоже закрываем проверкой прав.

Как мы ведём работу по шагам

Чтобы результат был предсказуемым, делим работу на понятные этапы. Первый — поиск опасных мест: сканируем код и находим прямой SQL, неэкранированный вывод, формы без токенов, небезопасные загрузки. Второй — оценка и приоритет: ранжируем находки по риску и начинаем с того, что реально эксплуатируется. Третий — собственно исправление: параметризация, экранирование, токены, валидация, контроль загрузок. Четвёртый — перепроверка: прогоняем сценарии атак на исправленные места и убеждаемся, что функциональность цела. Пятый — отчёт и рекомендации, чтобы новые уязвимости не появлялись в новом коде. Каждую правку мы готовим и проверяем на копии, а на боевой сайт выкатываем без простоя.

Почему правки совместимы с обновлениями

Мы закрываем уязвимости средствами самого ядра Битрикс и не правим его файлы напрямую. Параметризация через API, штатное экранирование, bitrix_sessid — всё это родные механизмы платформы. Свою логику выносим в собственные модули и обработчики, поэтому обновления Битрикса проходят без конфликтов, а защита остаётся на месте. Это принципиальный момент: правки, которые ломаются при первом же обновлении, не имеют смысла, потому что уязвимости возвращаются. Наш подход рассчитан на то, чтобы код оставался защищённым годами, а не до ближайшего апдейта.

Возражения, которые мы слышим чаще всего

«У нас стоит WAF, разве этого мало». WAF — хорошая страховка, но он не убирает уязвимость из кода и обходится нестандартной нагрузкой. Закрыв корень в коде, вы получаете структурную защиту, а WAF становится дополнительным, а не единственным рубежом. «Сайт давно работает, никто не взламывал». Отсутствие известного взлома не значит, что его не было: утечки часто незаметны. Боты сканируют сайты непрерывно, и наличие уязвимости — это вопрос времени. «Боимся, что правки сломают функциональность». Параметризация и экранирование не меняют поведение для пользователя — меняется только внутренняя обработка данных. Мы перепроверяем каждый сценарий перед публикацией, поэтому видимая работа сайта остаётся прежней.

Где чаще всего прячутся уязвимости на сайтах Битрикс

За годы работы складывается понятная карта мест, где классические уязвимости встречаются снова и снова. На первом месте — самописные фильтры и поиск по каталогу: разработчик собирает запрос из параметров адреса, чтобы быстро сделать гибкую выборку, и тем самым открывает дорогу инъекции. Второе типичное место — личные кабинеты и формы профиля, где данные одного пользователя выводятся другим без экранирования, что создаёт хранимый XSS. Третье — обработчики AJAX, которые меняют данные, но не проверяют токен и права, превращаясь в готовую точку для подделки запроса. Четвёртое — формы загрузки документов, аватаров и прайсов, принимающие файлы без проверки содержимого.

Отдельно стоит упомянуть интеграции и импорт данных. Когда сайт принимает выгрузки из внешних систем, прайсы поставщиков, заказы из мобильного приложения или данные из 1С, эти источники нередко считают доверенными и не проверяют так же строго, как ввод посетителя. Но скомпрометированный внешний канал — это та же точка входа для инъекции и XSS. Поэтому мы проверяем не только публичные формы, но и все места, где в систему попадают данные извне, включая API и фоновые обработчики импорта.

Как мы проверяем, что уязвимость действительно закрыта

Исправить код мало — нужно убедиться, что атака больше не проходит, а функциональность не пострадала. Поэтому после каждой правки мы воспроизводим сценарий атаки на исправленном месте: пытаемся подставить SQL в параметризованный запрос, внедрить скрипт в экранированный вывод, отправить форму без токена, загрузить файл с исполняемым содержимым. Если защита держится, фиксируем результат в отчёте. Параллельно прогоняем обычные пользовательские сценарии — оформление заказа, авторизацию, отправку заявки, — чтобы убедиться, что для посетителя ничего не изменилось. Такая двойная проверка отличает реальное устранение уязвимости от формальной правки «на глаз».

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

Что вы получаете по итогу

По завершении работы вы получаете закрытые в коде SQL-инъекции, XSS и CSRF, отчёт со списком найденного и исправленного простым языком и рекомендации, чтобы слабые места не появлялись в новом коде. На исправленные места даём гарантию: найденная уязвимость не вернётся. По желанию готовим для вашей команды стандарт безопасной разработки — короткий набор правил по запросам, выводу, формам и загрузкам, который не даёт повторно допускать те же ошибки. Если уязвимостей много или есть проблемы с конфигурацией и доступом, предлагаем дополнить устранение классики проактивной защитой Битрикс, чтобы закрыть и код, и настройки в комплексе.

С чего начать

Начните с бесплатной экспресс-проверки. Мы посмотрим на формы, запросы и точки ввода вашего сайта, прикинем риск SQLi, XSS и CSRF и покажем реальный объём работы. По её итогам вы получите честную картину: где находятся опасные места, что закрывать в первую очередь и за какой срок. Никакого запугивания и навязывания — только конкретные находки и понятный план. Расскажите о вашем сайте, и мы превратим его из лёгкой добычи для массовых атак в защищённый проект, которому классические уязвимости больше не страшны.