Для актуального на сегодня исследования безопасности, была выбрана демо версия интернет-магазина, работающего на CMS 1С-Битрикс.
Исследование проводилось в виртуальной лаборатории 1С-Битрикс, предназначенной для онлайн тестирования функционала платформы.
Внимание! Данные материалы представлены исключительно в ознакомительных целях. Взлом и нарушение информационной целостности сторонних продуктов является уголовно наказуемым деянием.
Адрес лаборатории «1С-Битрикс: Управление сайтом»: http://bitrixlabs.ru. Не внося никаких изменений в процесс инсталляции, был «развернут» демо интернет-магазин, работающий под управлением 1С-Битрикс: Управление сайтом 16.5.4 по адресу:
http://1071lab.bitrixlabs.ru/
Первым делом, было принято решение обновить решения до последней версии. После установки обновления (1С-Битрикс Решение «Современный интернет-магазин» версии 16.5.3), было начато исследование безопасности предложенного сайта.
Безопасность публичной части сайта «коробки» не вызывала нареканий и ранее, поэтому основное внимание было уделено административному разделу исследуемого сайта.
Множественные XSS
Наибольшее количество уязвимостей кода, позволяющих эксплуатацию непостоянных XSS атак были обнаружены в разделе «Дополнительные поля» административного раздела сайта:
Рабочий стол > Настройки > Пользователи > Список пользователей > Дополнительные поля > Настройки поляАдрес:
http://1071lab.bitrixlabs.ru/bitrix/admin/userfield_edit.php
В этом разделе, система предлагает создавать пользовательские поля для следующих типов данных: «Видео», «Привязка к элементам highload-блоков», «Строка», «Целое число», «Число», «Дата со временем», «Дата», «Да/Нет», «Файл», «Список», «Привязка к разделам инф. блоков», «Привязка к элементам инф. блоков», «Шаблон», «Опрос», «Содержимое ссылки».
Уязвимыми для XSS атак обнаружены поля формы для создания типов данных «Видео» и «Список».
Форма:
<form method="POST" action="/bitrix/admin/userfield_edit.php?lang=ru" enctype="multipart/form-data" name="post_form">Уязвимые поля для типа данных «Видео»
Поле input, вариант проверки возможности эксплуатации XSS:
"><script>alert(document.cookie)</script>| N | Название поля | name |
| 1 | Размер буфера в секундах | SETTINGS[BUFFER_LENGTH] |
| 2 | Уровень громкости в процентах от максимального: | SETTINGS[VOLUME] |
| 3 | Размеры (Ш х В, px) | SETTINGS[WIDTH] |
| 4 | Размеры (Ш х В, px) | SETTINGS[HEIGHT] |
| 5 | Цвет фона панели управления: | SETTINGS[BGCOLOR] |
| 6 | Цвет элементов управления | SETTINGS[COLOR] |
| 7 | Цвет эл. управления при наведении указателя мыши: | SETTINGS[OVER_COLOR] |
| 8 | Цвет экрана: | SETTINGS[SCREEN_COLOR] |
| 9 | id="bx_player_skin_input" (скрытое поле) | SETTINGS[SKIN] |
Поле textarea, вариант проверки возможности эксплуатации XSS:
</textarea><script>alert(document.cookie)</script>| 10 | Дополнительные переменные | SETTINGS[FLASHVARS] |
| 11 | Дополнительные переменные Silverlight: | SETTINGS[SILVERVARS] |
Уязвимое поле для типа данных «Список»
Поле input, вариант проверки возможности эксплуатации XSS:
"><script>alert(document.cookie)</script>| 12 | Подпись при отсутствии значения: | SETTINGS[CAPTION_NO_VALUE] |
На действия администраторов сайта (входящих в группу «Администраторы [1]») фильтр проактивной защиты Битрикс не распространяется, поэтому эксплуатация XSS атаки возможна без каких-либо ограничений.
Предполагая вопрос по поводу получения данных «защищенной» http-only cookie PHPSESSID: данные этой cookie не требуется для успешной эксплуатации атаки. Приведенный ниже пример успешной эксплуатации связки XSS + CSRF на «1С-Битрикс: Управление сайтом» подтверждает факт того, что использование http-only cookie нельзя рассматривать как полноценную защиту от XSS атак.
Эксплуатация CSRF атаки.
В процессе проведенного исследования, мы обратили внимание на возможность получения CSRF токенов, в разделе настроек пользователей (в т.ч. администраторов) системы:
Административный раздел сайта:
Рабочий стол > Настройки > Пользователи > Список пользователейАдрес сайта: (на момент тестирования) http://1071lab.bitrixlabs.ru/bitrix/admin/user_edit.php?lang=ru&ID=1. К примеру, в случае смены пароля, или каких иных учетных данных администратора, данные отправляются на обработчик следующим образом:
POST /bitrix/admin/user_edit.php?ID=1&lang=ru HTTP/1.1
Host: 1071lab.bitrixlabs.ru
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://1071lab.bitrixlabs.ru/bitrix/admin/user_edit.php?lang=ru&ID=1
Cookie: PHPSESSID=fdtc1nha7vd6fsgq9spuih3na0; BITRIX_SM_SOUND_LOGIN_PLAYED=Y; BITRIX_SM_GUEST_ID=1; BITRIX_SM_LAST_VISIT=13.01.2017+08%3A14%3A53; BITRIX_SM_SALE_UID=a44218257184b130c660695f7132ea02; BITRIX_CONVERSION_CONTEXT_s1=%7B%22ID%22%3Anull%2C%22EXPIRE%22%3A1484351940%2C%22UNIQUE%22%3A%5B%22sale_payment_add_day%22%5D%7D
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------81949277201
Content-Length: 9588
-----------------------------81949277201
Content-Disposition: form-data; name="autosave_id"
20247bf0249c12c0e2f15effa95c29d52
-----------------------------81949277201
Content-Disposition: form-data; name="TITLE"
-----------------------------81949277201
Content-Disposition: form-data; name="NAME"
Bitrix
-----------------------------81949277201
Content-Disposition: form-data; name="LAST_NAME"
Team
-----------------------------81949277201
Content-Disposition: form-data; name="SECOND_NAME"
-----------------------------81949277201
Content-Disposition: form-data; name="EMAIL"
admin@insafety.org
-----------------------------81949277201
Content-Disposition: form-data; name="LOGIN"
admin
-----------------------------81949277201
Content-Disposition: form-data; name="NEW_PASSWORD"
admin12345
-----------------------------81949277201
Content-Disposition: form-data; name="NEW_PASSWORD_CONFIRM"
admin12345
-----------------------------81949277201
Content-Disposition: form-data; name="XML_ID"
--- Множество различных данных ---
-----------------------------81949277201
Content-Disposition: form-data; name="sessid"
aa4c42ead8583afbd067d0409d1b25b0Единственными валидируемыми данными (полагаю, что это и есть CSRF токены) для этого запроса являются:
«autosave_id» и «sessid», которые элементарно получить с помощью JS:
В качестве примера, можно привести «тестирование» на XSS, вышеописанных полей.
"><script>alert(phpVars['bitrix_sessid'])</script>
"><script>alert(document.getElementsByName('autosave_id')[0].value)</script>Для того, чтобы взломать сайт на CMS 1С-Битрикс, эксплуатируя XSS+CSRF, достаточно сделать вектором атаки запрос, который, к примеру, изменит учетные данные доступа администратора сайта, или добавит нового, созданного атакующим.
Для подтверждения вышеописанного способа атаки на сайт, мы создали «боевой» JS скрипт, эксплуатирующий недостатки в разработке системы, и протестировали его работоспособность атаки на практике, в виртуальной лаборатории 1С-Битрикс.
Скрипт успешно «отработал», поставленную перед ним задачу. Итогом работы стала смена имя пользователя, пароля и почты администратора сайта. Авторизация в административной части «нового» администратора прошла успешно.
Вектором атаки является обычный POST XMLHttpRequest к /bitrix/admin/user_edit.php.
По понятным причинам, POC по эксплуатации вышеописанной техники атак на сайты, работающих под управлением «1С-Битрикс: Управление сайтом» в статье предоставлен не будет.
Вся информация по вышеописанной проблеме безопасности (включая вектор атаки) была передана в компанию Битрикс 19 сентября 2016 года. На 16 января 2017 года, уязвимости административного раздела CMS 1С-Битрикс версии 16.5.4 не устранены.
Дополнение:
На сегодняшний день, виртуальная лаборатория 1С-Битрикс предлагает к тестированию решения на CMS 1С-Битрикс 16.5.4. Ядро платформы в виртуальной лаборатории 1С-Битрикс, путем нехитрых манипуляций, можно обновить до версии 16.5.8.
В редакции 1С-Битрикс: Управление сайтом 16.5.8 вышеописанные XSS устранены, но проблемы безопасности, особенно в плане эксплуатации CSRF атаки, остались прежними.
Уязвимости устранены, выпущены обновления.
Детали обновлений в конце поста.
К примеру, эксплуатация вышеописанной угрозы возможна через уязвимые поля раздела: «Создать курс валют» > «Настройки курса» по адресу:
http://1071lab.bitrixlabs.ru/bitrix/admin/currency_rate_edit.php?lang=ru&filter=Y&set_filter=Y
Уязвимыми к XSS являются следующие поля формы:
<form method="POST" action="" name="rate_edit">| N | Название поля | name |
| 1 | Номинал | RATE_CNT |
| 2 | Курс | RATE |
Реализация самой атаки в реакции 1С-Битрикс: Управление сайтом 16.5.8:
Видео по теме:
Видео лучше смотреть в «полный» экран.
Вопросы по конструкции XSS атаки
Способов эксплуатаций XSS атак множество. Техники их проведения и конструкции подробно описаны во множестве статей, которые легко найти в Сети.
Что касаемо предложенной атаки, то для ее успешной эксплуатации придется решить один вопрос с токеном sessid, защищающего форму. Этот вопрос решаем.
В качестве примера, для версий платформы, предлагаемых в виртуальной лаборатории 1С-Битрикс, это значение можно получить запросом: http://1028lab.bitrixlabs.ru/bitrix/components/bitrix/pull.request/ajax.php (1028lab.bitrixlabs.ru – новый адрес предоставленного к тестированию ресурса)
Ответ будет выглядеть следующим образом:
{'BITRIX_SESSID':'47f51fa0d098862e588033cdc8d39388','ERROR':'SESSION_ERROR'}
Существуют и иные способы получения этого токена. Все зависит от конкретного ресурса, сервера, его настроек и т.п.
Предвосхищая вопросы по CORS 'Access-Control-Allow-Origin' или Сross-Origin Framing – в этой статье, как и в комментариях, эти вопросы обсуждаться не будут, как и дальнейшее обсуждение конструкции полноценной атаки.
Основной целью этой статьи является обеспечение безопасности сайтам на платформе 1C-Битрикс, а не создание полноценной инструкции по их взлому.
К сожалению, вышеописанные уязвимости платформы, успешно эксплуатируются хакерами.
Начиная с осени прошлого года, в нашу компанию inSafety, стали поступать обращения клиентов с проблемой взломов их сайтов.
Разбирая инциденты, мы обнаружили вышеописанные проблемы безопасности платформы 1С-Битрикс.
Защита от вышеописанной XSS + CSRF атаки
Компания Битрикс не приветствует модификацию системных файлов платформы, поэтому единственным вариантом защиты, может стать ограничение доступа по IP к файлам, расположенным в директориях /bitrix/admin/.
Понимая, что такой «радикальный» способ защиты может быть применим далеко не ко всем сайтам, вторым вариантом можно рассмотреть ограничение доступа к /bitrix/admin/. путем установки дополнительной парольной пары по типу Basic Authentication
Заключение
Обнаруженная проблема – является максимальной угрозой для сайтов, созданных на платформе «1С-Битрикс: Управление сайтом».
Эксплуатация XSS атаки, в случае ее грамотного исполнения, гарантирует взлом практически любого сайта, работающего под управлением CMS 1С-Битрикс последних версий.
Эксплуатация XSS атаки в связке с CSRF позволяет:
— изменять любые учетные данные доступа пользователей сайта
— создавать новых пользователей сайта, с различными привилегиями
— изменять привилегии существующих пользователей сайта
В отдельных случаях, особенно для ресурсов с недостаточным уровнем защиты на уровне
сервера, возможна эксплуатация CSRF в чистом виде, без ХSS. Кроме того, вышеописанная атака делает обычную XSS (к примеру, в строке поиска, что часто встречается у сайтов на 1С-Битрикс) максимальной угрозой безопасности сайта.
Резюме
1. Не оставляйте открытым доступ к авторизации административного раздела сайта.
2. Обновляйте ядро платформы 1С-Битрикс, специалисты компании устраняют уязвимости по мере их обнаружения.
3. Хотя бы раз в год проводите аудит безопасности ваших интернет проектов, для предотвращения взлома и атак.
Разбираться с последствиями взлома всегда сложнее и затратнее, чем предупредить его.
Внимание!
Компания 1С-Битрикс оперативно выпустила обновления, в которых устранена вышеописанная угроза безопасности.
Настоятельно рекомендуем установить следующие модули:
- Главный модуль, v16.5.6, 2016–09–20
- Управление структурой, v16.5.5, 2016–09–20
- Валюты, v16.5.1, 2017–01–16
На 17.01.2017 года угроза безопасности, представленная в этой статье устранена.
Важно понимать, что эксперименты с безопасностью чужих сайтов, не говоря о эксплуатации атаки в криминальных целях, может повлечь уголовную ответственность. Вся информация по угрозе безопасности сайтов, в этом посте, предоставлена с целью повышения общего уровня ИБ конечных продуктов на платформе 1C-Битрикс.
Комментарии (39)
lionskape
16.01.2017 12:02-2Хороший пост, спасибо.
Хороший повод своевременно обновлять ядро.
zevvssibirix
16.01.2017 12:20+4>> Вся информация по вышеописанной проблеме безопасности (включая вектор атаки) была передана в компанию Битрикс 19 сентября 2016 года. На 16 января 2016 года, уязвимости административного раздела CMS 1С-Битрикс версии 16.5.4 не устранены.
и чем это поможет?
inSafety
16.01.2017 12:25+1Часть проблем с XSS они убрали, в 16.5.8 их нет. А поможет, надеюсь, эта статья.
kpower
16.01.2017 19:41Традиционный подход. Автор дает несколько месяцев (а в этом случае аж год) на устранение. А потом рассказывает, поясняя, что он не засрашка и свежее не сливает. Ну, и да, отдельный показатель скорости реакции. Баги бывают у всех, а вот реагируют по-разному, может влиять на выбор технологии (как один из моментов, почему нет?).
aGGre55or
17.01.2017 11:07Битрикс всегда набит XSS под завязку. Когда-то втыкаешься впервые это вызывает удивление. Это связано с подходом к разработке новых версий о котором можно услышать на их партнёрских семинарах. Какие-то исправления начинаются только после засветки, таких вот статей. Никто ничего делать не будет пока это не вредит репутации. Тогда будет выделен бюджет на латание и наняты сессионные программисты. Доказано моей статьёй «Плюшевый Битрикс», ещё раньше. Не думаю что что-то с 2008-09 года изменилось или изменится в будущем. Сие не означает что Битрикс = вселенское зло. Большинство векторов атаки сработают только на особо ушастых админах. Конечно, на просторах Рунета такие всегда найдутся. :)
kpower
17.01.2017 11:40Абсолютно согласен, ни в коем случае не зло — не призывал к этому. Пока косяк требует каких-то действий для факапа (условно: открытия подготовленной ссылки, пусть и сокращенной), а также от админа (который все равно подготовленней случайного пользователя в общем случае) — лично я даже не собираюсь переживать. Хотя тенденцию править только после массового известия — можно бы и исправить. Может, подобные статьи и помогут.
funcbook
17.01.2017 17:12+1Такое ощущение, что цель статьи намеренно повысить кол-во взломов платформы, для дискредитации её перед другими. Мне известно много случаев массового взлома joomla, wp, но битрикс в этом плане, не скажу, что не взламывали, но по крайней мере сильно не светился, да вообще лично мне на самом деле не известен ни один случай взлома битрикса.
А на счёт времени написания статьи, я сам по-молодости опубликовал статью через час после написания в ТП вконтакте, после обнаружения уязвимости. За что получил кучу минусов)kpower
17.01.2017 19:21Не знаю, у меня совсем не сложилось. Обычная статья из серии «нашел-сказал-дал время-не поправили-держите». Много их. Сомневаюсь, что они как-то сильно уж влияют на бренд. Тем более, что мы говорим о достаточно простых атаках «в лоб» — они скорее всего обычным бесплатным автоматическим сканером найдутся. Т.е. не сказать, что тут древнее зло пробуждается.
А про «взламываемость». Это очень сложно сравнить. Даже если собирать статистику, это же разбираться в опасности каждого случая (коэффициенты какие-то придумывать). Опять же, вопрос, пожалуй, каждого разработчика — как он для себя это интерпретирует. Вы, например, сравниваете бесплатные решения с платным. Значит, вам не принципиально. Кто-то же, возможно, захочет предъявить повышенные требования. Опять же от задачи зависит. Не помрет бложек и на старом wp)))
По времени. Автор пишет про 4 месяца. Он посчитал, что этого достаточно. Ну, лично я бы ждал полгода-год. Но это прям вкусовщина, в конце концов и он не пару дней. Так что тоже неоднозначно.
Я бы больше негодовал, что после часика-другого «поиграться» сканером, пишется статья (нет, серьезно, либо я что-то не понимаю — я чисто для себя баловался этими вещами, чтобы понимать, как защищаться, т.е. не эксперт по ИБ, как ребята, и даже у меня это займет примерно столько вместе с написанием скриптов...). Но это как мне кажется, общая проблема по палате сейчас стала.
inSafety
16.01.2017 13:11Конкретно 16.0 не смотрел, но полагаю, что проблемы те же. У 15й, по крайней мере все это было.
http3
16.01.2017 18:37Но как получить BITRIX_SESSID? :)
Оно ж сделано не через
var session = {BITRIX_SESSID: 'bla-bla'};
Спрашиваю в целях защиты.inSafety
16.01.2017 18:47+1Прошу Вас не поднимать вопросы такого характера. Суть поста — безопасность сайтов на Битрикс. Конструкция атаки здесь обсуждаться не будет.
Рекомендации по защите в конце поста.http3
16.01.2017 18:54Так у меня и не Битрикс вообще. :)
Я просто тоже думал токен получать через JS. :)
Чтобы думал кешировать страничку на диск или в мемкеш и отдавать всем одинаковую, а там уже подгружать что кому нужно. :)
Cейчас токен вшит в форму.
При использовании старого браузера можно и такой токен прочитать. :)
Мораль:
не использовать старые браузеры
не переходить по сомнительным ссылкам
:)inSafety
16.01.2017 19:30В форму — это правильно. :)
http3
21.01.2017 13:04Но, если по Вашему злоумышленник может получить json, то что ему помешает получить токен из формы? :)
inSafety
21.01.2017 13:07Я нигде не писал, что злоумышленник может «просто так» получить json.
В большинстве случаев это сделать не получится (CORS).
Конструкция атаки иная. Прошу не развивать тему получения токена в ветке поста.http3
21.01.2017 18:40Я не развиваю.
Я просто не вижу разницы между получением токена из json-файла и из формы…
kmx
16.01.2017 19:58правильно ли я понимаю что закрыв админку через htpasswd я защищу сайты? п.2 и п.3 естественно выполнены)
aGGre55or
21.01.2017 00:23Скорее Вы защитите сайты если не будете использовать лишних сущностей, как то httpd и не будете бездумно ставить bitrix-env несущий с собой вагон и маленькую тележку ПО, к тому же торчащего наружу десятком портов. В nginx тоже есть Basic-авторизация, если что.
inSafety
16.01.2017 20:33Да. Уровень защиты Ваше сайта станет на порядок выше.
Обратите внимание на потенциально возможные XSS в публичной части (проверьте их отсутсвие).
Главная угроза, описанная в этой статье — это CSRF, а не XSS в админке.
komandakycto
17.01.2017 08:41+1В прошлом занимался Битриксом, поэтому открываю посты про него. Каждый раз радуюсь, что больше я его не вижу)
german3w
17.01.2017 13:14Полагаю,
вовремя обновлять ядро
этой, с позволения сказать, «системы» — не поможет, при таком отношении компании к движку!
inSafety
17.01.2017 13:17Поможет, уязвимости в новых версиях устраняются.
Другое дело, если у ресурса повышенные требования к ИБ, к этот вопрос нужно решать «отдельным» пунктом.
Идеальных «систем» в плане ИБ, наверное, вообще не существует.german3w
17.01.2017 22:40Согласен, что идеальных нет. Но, когда крупная компания не решает такие проблемы оперативно, только из-за того, что об этом ещё никто не «шумит» — говорит о её отношении к делу.
AlexSerbul
17.01.2017 17:01-2Добрый вечер.
В отечественной индустрии IT-разработки и IT-безопасности достаточно давно сложились негласные нормы этики. «Независимые IT-специалисты» ведут прямой диалог с компаниями-вендорами. И наоборот.
При обнаружении каких-либо ошибок в системе, считается хорошим тоном:
- Уведомить компанию-вендора об уязвимости
- Дождаться ее исправления, предоставив для этого хотя бы минимально необходимый срок
- После исправления уязвимости и выпуска обновления— рассказать об этом публично
Сотрудники 1С-Битрикс всегда открыты к двухстороннему диалогу. Подавляющее большинство топ-менеджеров, ведущих разработчиков и специалистов по информационной безопасности компании легко найти в социальных сетях.
К сожалению, автор статьи не счел нужным поступить согласно многолетним традициям, сложившимся в российском IT-сообществе.
В глобальной IT-индустрии, к сожалению, не существует систем без уязвимостей. Поэтому мы рекомендуем клиентам задействовать все многочисленные инструменты дополнительной защиты продукта: от проактивной защиты и веб-антивируса до двухфакторной аутентификации. Подробнее об этом можно прочитать тут.
Дополнительно мы рекомендуем:
- Проводить регулярное сканирование веб-сайта с помощью встроенного «Облачного» сканера безопасности
- Не позволять сотрудникам отделов заходить в любые системы под одним паролем «123456» и регулярно менять коды доступа
- Разделять роли на сайте с помощью групп безопасности, не раздавать пароль админа или суперадмина всем подряд
- Постоянно следить за новостями, например тут, и обновлять не только продукты Битрикс, но и системное ПО: компоненты linux, apache, php
Компания 1С-Битрикс всегда незамедлительно устраняет обнаруженные ошибки в своих проектах. Так произошло и на этот раз. Мы оперативно выпустили обновление, в котором все уязвимости уже закрыты.
Просим всех партнеров и клиентов установить очередное обновление продукта и обновить следующие модули:
- Главный модуль, v16.5.6, 2016–09–20
- Управление структурой, v16.5.5, 2016–09–20
- Валюты, v16.5.1, 2017–01–16
Это устранит все возможные уязвимости, описанные в посте.
Мое личное мнение?—?ситуация с постом сильно напоминает известный перформанс «Фиксация на Красной Площади». Но коллеги попросили меня об этом не писать. Поэтому?—?не пишу ;-)
inSafety
17.01.2017 18:46+3Здравствуйте!
Уважаемый Александр, возможно Вы не до конца осведомлены тем объемом проблем безопасности, которые компания inSafety за свою историю передала (и будет передавать в дальнейшем) в компанию 1С-Битрикс.
Мы всегда придерживаемся правил хорошего тона при публикации тех или иных уязвимостей.
Я понимаю так, что Ваше недовольство вызвала публикация 2х XSS в разделе «Настройки курса».
Все остальные проблемы безопасности, описанные в статье, были переданы в 1С Битрикс 19 сентября 2016 года.
Возможно, действительно следовало бы подождать некоторое время с публикацией поста, предварительно передав эти 2 XSS вам, но это ничего не меняет по сути.
Основной проблемой безопасности, описанной в посте является СSRF, а не XSS, которые и так, достаточно часто встречаются на сайтах, а про CSRF в компании Битрикс были осведомлены.
Поэтому Ваши претензии считаю не до конца обоснованными.
Я лично очень рад факту оперативного устранения вышеописанных проблем.
То, что компания 1С-Битрикс — команда профессионалов, сомнения не вызывало.
В любом случае, выходит так, что этот пост был опубликован не зря, ведь сейчас все проблемы устранены.
Абсолютно согласен (и это написано в статье) с тем, что своевременное обновление продукта, как и системного ПО является обязательной мерой, особенно в плане обеспечения безопасности сайтов.
P.S. Напишите про перфоманс в личку, интересно к чему Вы про него вспомнили.
xmoonlight
20.01.2017 02:40Статья интересная, но советую также взглянуть сюда тем, кто хочет защищать системы не только на 1C-Bitrix, но и любые другие.
inSafety
20.01.2017 15:09Это достаточно известный вариант защиты, но явно не подходящий к админпанели платформы.
Столь жесткая фильтрация, никогда не позволит нормально функционировать админке, + может принести кучу неудобств в в эксплуатации сайта (как вариант, человеку с email, содержащему union на сайте будет делать нечего, в случае необходимости ввода почты).xmoonlight
20.01.2017 20:37как вариант, человеку с email, содержащему union на сайте будет делать нечего, в случае необходимости ввода почты
Если почта присутствует в QUERY_STRING (то, что после знака "?"), то это УЖЕ как-то подозрительно (и не важно где, в каком случае и на каком сервисе).
gigli
20.01.2017 16:44Проблемы с безопасностью в битриксе игнорятся, например, после очередного обновления группа с ограниченным доступом в upload потеряла возможность загружать картинки из медиабиблиотеки в инфоблоки. Для решения проблемы загрузки было предложено дать группе доступ ко ВСЕМУ upload:
Других решений нет.
Почему вы не хотите давать доступ пользователям к папке upload?
Это не будет угрозой безопасности сайта.
при том, что локальная загрузка картинки с компьютера была возможна и без такого доступа.
Понятно, что когда у тебя пара-тройка контент менеджеров это не проблема, а когда у тебя десятки групп и под сотню юзеров, и под одним логином могут сидеть несколько человек единственным способом сдерживать анархию является разграничение прав группам к каталогам, и если утечет логин в не хорошие руки, то проблему можно будет быстро локализовать.
О проблеме было сообщено в начале февраля 2014-го, несколько дней спустя, после долгих препирательств, отправилось в отдел разработок, а опубликовано исправление было только в ноябре 2016 года!
Handy761
Правильно ли я понимаю, что для эксплуатации уязвимости нужно сначала войти под админом?
Loki3000
Нет, надо послать специально подготовленную ссылку админу.
maxpsyhos
Который уже в этом же браузере вошёл под админом :)
MrGobus
Не стоит копать так глубоко, а то можно заподозрит автора в вирусном продвижении версии 16.5.8 =) Оцените лучше стиль подачи, прям детектив, мне понравилось =)
MKMatriX
причем ссылка может быть сокращенна с помощью многочисленных сервисов.
вовзращает sessid)Кстати