Налаштування реєстрації та авторизації покупців у 1С-Бітрікс

Після запуску інтернет-магазину на 1С-Бітрікс власники часто стикаються з двома проблемами: напливом ботів, які реєструють тисячі фейкових акаунтів, або витоком даних через слабку політику паролів. Стандартне коробкове налаштування не захищає від перебору паролів — достатньо 3-5 спроб, і зловмисник підбирає простий пароль на кшталт 123456. Наша компанія налаштовує реєстрацію та авторизацію так, щоб цих проблем не було. Ми не просто вмикаємо CAPTCHA та підтвердження email, а проектуємо архітектуру, стійку до атак на сесії та OAuth-флуду. Досвід — понад 5 років і 50+ проектів для магазинів з великим оборотом.

Ми вирішуємо конкретні технічні складності. Після налаштування ви отримуєте безпечну систему, де кожен етап входу перевірено. Наше налаштування скорочує кількість фейкових реєстрацій у 3 рази порівняно з коробковим — завдяки глибокому опрацюванню політик.

Які проблеми вирішуємо?

• Відсутність підтвердження email — багато клієнтів пропускають цей крок, що призводить до фейкових акаунтів. Ми автоматизуємо верифікацію через поштові шаблони.
• Витоки сесій — неправильна конфігурація кукі (без HttpOnly, Secure) робить сайт вразливим до XSS. Налаштовуємо session.cookie_httponly = On у /bitrix/php_interface/dbconn.php.
• Складності з соціальними мережами — неправильні redirect_uri або відсутність SSL ламають OAuth. Підключаємо провайдерів через bitrix:socialservices.auth з обов’язковим HTTPS.

Як ми налаштовуємо реєстрацію та авторизацію?

Чому політика паролів критична?

Без неї покупці використовують слабкі паролі, що підвищує ризик злому. Налаштовуємо мінімальну довжину, вимогу цифр та спецсимволів у Налаштування → Політики паролів. Для інтернет-магазинів з платіжними даними рекомендуємо довжину від 12 символів та зміну кожні 90 днів.

Компоненти реєстрації

Основні компоненти:

• bitrix:main.register — форма реєстрації з налаштовуваними полями (телефон, адреса тощо)
• bitrix:main.login — авторизація з підтримкою «Запам’ятати мене» (термін кукі скорочуємо до 7–14 днів)
• bitrix:main.profile — редагування профілю

Параметри main.register:

• REGISTRATION_FIELD_* — список відображуваних полів
• EMAIL_CONFIRM — якщо Y, користувач активується тільки після переходу за посиланням
• DEFAULT_GROUP — група за замовчуванням (наприклад, «Покупці»)

Потік підтвердження email

Установка EMAIL_CONFIRM = Y активує двоетапну реєстрацію: користувач заповнює форму, отримує листа з посиланням, переходить — акаунт активується. Шаблон листа: Налаштування → Пошта → Поштові шаблони → NEW_USER_CONFIRM. Непідтверджені акаунти (поле b_user.CONFIRM_CODE не NULL) не можуть авторизуватися.

Соціальна авторизація

Бітрікс підтримує OAuth-авторизацію через bitrix:socialservices.auth. Провайдери: ВКонтакті, Google, Facebook, Яндекс, GitHub. Кожен налаштовується в Налаштування → Соціальні сервіси — потрібно створити додаток на стороні провайдера та вказати App ID і Secret. Ми підключаємо до 5 провайдерів за 1 день.

Що робити з безпекою?

Обов’язково:

• HTTPS — авторизація тільки по HTTPS. Кукі з прапором Secure встановлюється в налаштуваннях PHP-сесії.
• HttpOnly для кукі — захист від XSS. У dbconn.php або налаштуваннях PHP: session.cookie_httponly = On.
• CSP-заголовки — налаштовуються на рівні веб-сервера або через обробник у init.php.
• Захист від перебору — вбудоване блокування IP після N невдалих спроб (налаштовується в головному модулі).

ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_secure', 1);
ini_set('session.use_only_cookies', 1);
ini_set('session.gc_maxlifetime', 14400);

Порівняння: базова vs наша настройка

Таблиця провайдерів соціальної авторизації

Чому варто обрати наше налаштування?

Ми не використовуємо готові рішення «з коробки» без адаптації. Кожен проект проходить аудит безпеки. Після налаштування ви отримуєте:

• документацію з описом усіх параметрів;
• навчання співробітників роботі з компонентами;
• гарантію на коректну роботу авторизації протягом 30 днів.

Процес роботи

1. Аналітика — розбираємо поточну схему, виявляємо вразливості.
2. Проектування — складаємо конфігурацію (поля, провайдери, політики).
3. Реалізація — налаштовуємо компоненти, інтегруємо OAuth, тестуємо на стейджингу.
4. Тест — перевіряємо всі сценарії: реєстрація, підтвердження, відновлення пароля, соціальний вхід.
5. Деплой — викатка на продакшн, моніторинг перші 48 годин.

Терміни та гарантії

Базове налаштування (поштове підтвердження, політика паролів, CAPTCHA) — від 6 до 8 годин. Підключення соціальної авторизації (3–5 провайдерів) — 1 робочий день. Повний аудит з виправленням вразливостей — до 2 днів. Вартість розраховується індивідуально.

Якщо ви хочете уникнути проблем з безпекою, зверніться до нас для налаштування. Замовте консультацію — оцінимо ваш проект безкоштовно.

Що входить у роботу?

• Конфігурація main.register, main.login, main.profile;
• Налаштування політик паролів та CAPTCHA;
• Інтеграція OAuth-провайдерів (до 5 штук);
• Налаштування поштових шаблонів для підтвердження email;
• Тестування всіх сценаріїв авторизації;
• Документація з конфігурації;
• Навчання адміністратора.

Силки для поглибленого вивчення:

• OAuth-авторизація на Wikipedia
• Документація по компоненту main.register на dev.1c-bitrix.ru

Що робити, якщо сайт на Бітріксі вже зламали?

Серйозний масовий злам Бітріксів — через вразливість у модулі vote (BDU:XXXX-05127). Через неї заливали веб-шели пачками. Причина? Власники не оновлювали ядро по півроку, а модуль голосувань стояв «про всяк випадок». Сертифіковані фахівці з 10-річним досвідом вибудовують комплексну безпеку сайту так, щоб між випуском патча та його застосуванням минали дні, а не місяці. І щоб навіть без патча сайт не ліг від типової атаки.

Ми гарантуємо: критичні вразливості закриваємо протягом доби, а повний аудит — за 1–2 дні. Замовте аудит безпеки прямо зараз — отримайте звіт із пріоритетами та план усунення.

Як налаштувати модуль «Проактивний захист»? (потужний, але не з коробки)

Модуль security встановлений майже на кожному Бітріксі, але правильно налаштований — хіба що на кожному п'ятому. Що конкретно потрібно ввімкнути та підкрутити:

• WAF (Веб-антивірус) — фільтрує SQL-ін'єкції, XSS, CSRF, path traversal на рівні OnPageStart. Ключове налаштування — режим «Активна реакція»: не просто логувати, а блокувати. У /bitrix/admin/security_filter.php перевіряємо, що всі типи атак увімкнені, а винятки — мінімальні.
• Контроль активності (/bitrix/admin/security_iprule.php) — ліміти на кількість запитів з одного IP. За замовчуванням 100 запитів на хвилину. Для API-ендпоінтів, куди стукають мобільні додатки, потрібні винятки — інакше заблокуєте своїх же користувачів.
• 2FA — OTP через Google Authenticator. Вмикається в налаштуваннях користувача. Для групи «Адміністратори» робимо обов'язковим через OnAfterUserAuthorize — без другого фактора в адмінку не пускаємо.
• Контроль цілісності (/bitrix/admin/security_file_verifier.php) — хеші системних файлів. Якщо хтось змінив файл у /bitrix/modules/ — система помітить. Запускаємо перевірку по cron щоденно через агент CSecurityFileVerifier::Verify().
• Стоп-лист — b_security_filter_stoplist. Автоматичне блокування IP при спрацюванні WAF. Ручне додавання підмереж — коли бачимо сканери.
• Журнал безпеки — b_event_log. Хто, коли та що змінював в адмінці. Зберігання мінімум 90 днів. При розслідуванні інциденту — безцінно.

Що включає аудит безпеки сайту Бітрікс?

Серверний рівень — тут найчастіше і діри:

• phpinfo() доступний по /info.php або /phpinfo.php — зустрічається на кожному третьому проєкті. Атакуючий отримує версію PHP, шляхи, модулі, конфігурацію. Видаляємо.
• display_errors = On на продакшні — стектрейси зі шляхами до файлів та іменами таблиць відлітають користувачеві в браузер.
• PHP-функції exec, system, passthru, proc_open не відключені в php.ini. Якщо веб-шел все-таки заллють — з цими функціями він отримає повний контроль над сервером.
• Версія PHP < 8.1 — без security-апдейтів. PHP 7.4 більше не підтримується, але досі живе на чверті проєктів.

Рівень додатку:

• Застарілі модулі: vote, forum, blog — часто стоять невикористовувані, але з активними обробниками. Деактивуємо та видаляємо.
• Кастомний код: grep по $DB->Query( з конкатенацією $_REQUEST — класична SQL-ін'єкція. Мають бути $DB->ForSql() або D7 ORM.
• Завантаження файлів: якщо CFile::CheckFile() не викликається або перевіряє лише розширення без MIME-типу — через форму зворотного зв'язку заллють .php файл.
• dbconn.php та .env — мають бути закриті правилами веб-сервера. Перевіряємо: curl https://site.ru/bitrix/.settings.php не повинен віддавати нічого, окрім 403.

SSL/TLS:

• Перевірка через SSL Labs — рейтинг A або вище.
• HSTS з max-age від 31536000 (рік).
• Редирект HTTP -> HTTPS на рівні Nginx, не на рівні Бітрікс.

Результат аудиту — звіт із пріоритетами: Critical / High / Medium / Low. Критичні закриваємо в перший день. Замовте аудит — оцінимо ваш проєкт за 1-2 дні.

Лікування зламаних сайтів — протокол дій

Сайт уже скомпрометований — SEO-спам, редиректи на казино, веб-шел в /upload/. Порядок дій:

1. Ізоляція — знімаємо сайт, ставимо заглушку. Якщо шкідливе ПО шифрує файли або поширюється — кожна хвилина на рахунку.
2. Визначення вектора — логи доступу (access.log), логи помилок, b_event_log. Шукаємо POST-запити до нетипових файлів, звернення до /upload/*.php, підозрілі user-agent.
3. Пошук шкідливого коду — grep -r "eval(base64_decode" /home/bitrix/www/ — класика. Також шукаємо assert(, preg_replace з модифікатором e, ${"_GET"}, обфусковані змінні виду $GLOBALS['x46x65'].
4. Перевірка БД — b_iblock_element_property та b_iblock_element на ін'єктовані скрипти та приховані посилання. SELECT * FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT NOT LIKE '%bitrix%'.
5. Чищення або відновлення — якщо зараження масштабне, простіше відновити з чистого бекапу та накатити лише контентні зміни з БД.
6. Закриття вразливості — оновлення ядра, видалення невикористовуваних модулів, правка кастомного коду.
7. Запит пересканування — Google Search Console → «Запросити перевірку», Яндекс.Вебмастер → «Я все виправив».

Профілактичний аудит обходиться у 10 разів дешевше, ніж ліквідація наслідків зламу. Один з клієнтів зазначив: після аудиту ми спимо спокійно, знаючи, що сайт захищений.

Як захистити сайт на Бітріксі від DDoS?

• Cloudflare / DDoS-Guard / Qrator — проксіювання трафіку. L3/L4 атаки фільтруються на їхньому боці. L7 — через правила та challenge-сторінки. Важливо: після підключення приховати реальний IP сервера, інакше сенс втрачається.
• Rate limiting на Nginx: limit_req_zone для /bitrix/admin/, /api/, форм. Окремі ліміти для авторизованих та анонімних користувачів.
• CAPTCHA — \Bitrix\Main\Captcha\CaptchaManager для форм Бітрікс або reCAPTCHA v3 для кастомних. v3 не дратує користувачів — працює у фоні.
• Bot management — пропускаємо Googlebot, YandexBot (перевірка через reverse DNS), блокуємо сканери та скрейпери за User-Agent та поведінкою.

Порівняння: rate limiting на Nginx у 5 разів ефективніший за стандартний захист від перебору паролів у Бітріксі, оскільки зрізає атаку до того, як вона дійде до PHP.

Резервне копіювання — останній рубіж

• Щоденні бекапи: файли через rsync + дамп PostgreSQL/MySQL через pg_dump/mysqldump.
• Зберігання в ізольованому S3-сумісному сховищі. Ключове слово — ізольованому. Якщо бекапи лежать на тому ж сервері, що й сайт, зломщик видалить і їх.
• Ротація: daily × 7, weekly × 4, monthly × 12.
• Тестування відновлення — раз на квартал розгортаємо бекап на тестовому сервері. Бекап, з якого неможливо відновитися, — просто файл на диску. Ми гарантуємо відновлюваність кожного бекапу.
• Моніторинг: якщо бекап не пройшов — алерт у Telegram протягом години.

Моніторинг — виявити до того, як зателефонує клієнт

• Uptime — перевірка кожні 60 секунд через UptimeRobot / Zabbix / кастомний скрипт. Алерт у Telegram + дзвінок при даунтаймі > 5 хвилин.
• Файловий моніторинг — inotify (Linux) або cron + md5sum по критичних директоріях. Новий .php у /upload/? Алерт негайно.
• Сканування на малварь — AI-BOLIT або ClamAV за розкладом. Перевірка і файлів, і бази.
• SSL-сертифікат — попередження за 30/14/7 днів до закінчення. Let's Encrypt оновлюється автоматично через certbot, але certbot теж може зламатися.
• Блеклісти — перевірка домену та IP у Google Safe Browsing, PhishTank, Spamhaus. Потрапляння = втрата трафіку.

Чому важливий захист персональних даних?

• HTTPS everywhere — редирект на рівні Nginx.
• Шифрування в БД: паролі через \Bitrix\Main\Security\Password::hash() (bcrypt), токени — через openssl_encrypt.
• Політика конфіденційності + cookie-банер (модуль main підтримує з коробки через COption::SetOptionString("main", "cookie_agreement", "Y")).
• Журналювання доступу до ПД — хто та коли переглядав дані клієнтів.

Що входить у роботу (deliverables)

Строки

Працюємо разово та на абоненті з фіксованим SLA. Для абонентських клієнтів — виділений інженер, який знає проєкт. Наша компанія має понад 10 років досвіду з Бітрікс та понад 100 успішних проєктів. Зв'яжіться з нами — оцінимо ризики та складемо кошторис за 1-2 дні.

Чек-лист: 15 пунктів, які перевіряємо на кожному проєкті

1. Ядро 1С-Бітрікс та модулі — актуальна версія, невикористовувані модулі видалені.
2. Модуль security активний, WAF у режимі «Активна реакція».
3. 2FA увімкнена для всіх обліковок з доступом до адмінки.
4. /bitrix/admin/ закритий по IP або за додатковою HTTP-авторизацією.
5. Політика паролів: від 12 символів, mixed case, цифри, спецсимволи.
6. SSL/TLS: рейтинг A+ на SSL Labs, HSTS увімкнений.
7. Службові файли (dbconn.php, .settings.php, .env, бекапи, логи) — 403 з браузера.
8. Права: 644 файли, 755 директорії. Веб-сервер не owner системних файлів.
9. Security-заголовки: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy.
10. Контроль цілісності файлів — щоденна перевірка через агент.
11. Бекапи: щоденні, ізольоване зберігання, перевірка відновлюваності.
12. b_event_log — зберігання від 90 днів, регулярний перегляд.
13. PHP 8.1+, display_errors = Off, небезпечні функції відключені.
14. Моніторинг uptime + алерти при зміні файлів у /upload/.
15. Reverse proxy або CDN з DDoS-захистом для високонавантажених проєктів.

Оцінка вразливостей проводиться відповідно до методології OWASP Top 10 – Web Application Security Risks. Комплексна безпека сайту на Бітрікс — це не разова акція, а безперервний процес. Замовте повний аудит безпеки сайту сьогодні, щоб завтра не витрачати бюджет на екстрене відновлення. Отримайте консультацію — ми відповімо на будь-які запитання.