6.4 KiB
Известные проблемы и рекомендации (apelsincom)
Грабли и слабые места по результатам разбора кода (только чтение, без сканирования и эксплуатации). Часть — гипотезы, требующие проверки в админке; отмечено. Модель угроз — Информационная безопасность (apelsincom).
Приоритет: критично — сразу; важно — скоро; средне — планово.
Критично
1. Полный бэкап в webroot. public_html/shoes.zip (~1.27 ГБ). Если открывается по https://<домен>/shoes.zip — это утечка исходников и, возможно, дампа БД со всеми секретами и токенами API.
→ Убрать из webroot, проверить, что ссылка отдаёт 403/404, впредь бэкапы в публичных папках не держать (Кэширование и обслуживание (apelsincom)).
2. Открытый API без проверенной защиты. Модуль richcode.api даёт доступ к товарам, заказам, пользователям. Если не включены HTTPS-only, белый список IP и токен-авторизация — это открытая дверь.
→ Проверить и включить меры в настройках модуля. См. REST API (richcode.api) и Информационная безопасность (apelsincom).
3. FTP по открытому порту, доступы переданы текстом. Порт 21, пароль передавался в переписке. → Сменить пароль FTP, перейти на FTPS/SFTP, секреты не слать в открытых каналах.
Важно
4. Хардкод номера инфоблока (IBLOCK_ID = 2). Прописан в catalog/index.php, header.php, шаблонах компонентов, и используется в API. Пересоздание каталога под другим ID потребует правок во многих местах.
→ При любой миграции каталога искать "IBLOCK_ID" => "2" и iblock_catalog/2 по всему /local/ и в настройках richcode.api.
5. Файлы импорта/фидов в публичном upload/. upload/xml/pric.xml, import_test_50.xml, upload/bitrix_import.csv — могут раскрывать закупочные данные.
→ Проверить доступность по прямой ссылке; рабочие фиды держать вне webroot или закрыть; тестовые удалить.
6. Демо-данные на витрине. Контакты в подвале заглушечные (info@catalog.ru, +7 (999) 123-45-67).
→ Заменить перед продом (Шаблон custom).
Средне
7. Мусор в шаблонах. В catalog.smart.filter/custom лежит template copy 1.php — нерабочий дубль, легко перепутать с template.php.
→ Удалить после проверки, что он нигде не подключается.
8. Дубли шаблонов bootstrap_v4 рядом с custom. Исходные шаблоны eShop лежат рядом с рабочими. Риск править не тот файл.
→ Помнить, какой шаблон реально указан в вызове компонента (Компоненты и шаблоны компонентов).
9. Логи и служебные файлы в доступе. error_log*, bitrix/site_checker_*.log, updater*.log.
→ Ограничить доступ/чистить; снижает объём разведданных.
10. Внешний виджет higgleby.tech. Сейчас отключён (закомментирован). При включении — передача данных третьей стороне. → Включать осознанно, отразить в политике ПДн.
11. Расхождения в документации API richcode.api. Подсказки модуля вводят в заблуждение: поле токена названо UF_RESTFUL_API_TOKEN, хотя код использует UF_API_TOKEN; предлагается передавать токен заголовком Authorization-Token, хотя рабочий код читает его из URL. Разработчик на интеграции легко потеряет время.
→ Ориентироваться на код и на REST API — методы и примеры (richcode.api), а не на подсказки в админке.
12. Неочевидные правила тела запросов API. Легко потерять время на интеграции:
- каталог (инфоблок 2) обслуживает
sale/product, аiblock/elementкаталог отклоняет («Инфоблок с указанным ID не найден»); - у
add/update/section.addтело обёрнуто в ключfields, а уorder/create— нет; - свойства передаются с префиксом
PROPERTY_<КОД>, поля раздела —UF_<КОД>. → Проверенные схемы — в REST API — методы и примеры (richcode.api)#Точные схемы (проверено по моделям).
Что хорошо
- Свежая версия платформы (25.100.500, 2025) — меньше известных уязвимостей.
- Принудительный HTTPS и запрет листинга директорий в
.htaccess. - Кастомизация вынесена в
/local/, ядро не правится. - У модуля API есть встроенные меры (HTTPS-only, IP-фильтры, CORS, токены) — их нужно лишь правильно включить.
См. также
- Информационная безопасность (apelsincom)
- REST API (richcode.api)
- Быстрый старт для нового разработчика (apelsincom)