Comments 65
Ну вставка картинки еще не выполнение произвольного javascript сценария, так что класс атаки другой :)
Автор лишь показал уязвимое поле (туда можно пихнуть что угодно, вплоть до целевого сплоита). И зря вы думаете, что картинка со стороннего ресурса это абсолютно безопасно — как минимум с ее помощью можно успешно собирать статистику о пользователях сайта.
Экранирование и преобразование символов считаю правилом хорошего тона. И не важно на основе какой CMS ты пишешь
Думаю экранирование и преобразование символов должно быть дейстием по умолчанию для фреймворка. Которое если надо, можно в конкретном месте выключить.
В статье идет речь об обработке с помощью API данных. Поэтому тут разработчик должен быть внимательным
Абсолютно согласен с AntonioLeavez, нам, как разработчикам на CMS 1С-Битрикс, важно получать актуальную информацию по возможным проблемам разработанных и\или разрабатываемых проектов на 1С-Битрикс с точки зрения безопасности, т.к. данная тема всё больше становиться актуальной и несет за собой дополнительные риски для разработчиков при взаимодействии с Заказчиком\Клиентом.
Например в других фреймворках, не буду называть каких, дабы не было холиваров, что бы вывести в html переменную без экранирования символов надо добавить дополнительные команды. А как неэкранированные переменные передать в orm вообще не представляю. Разве что через raw запрос. Но тут уж надо думать головой. За то я знаю, что если я действую стандартными методами, они априори безопасны. Откуда бы не пришли данные.
Экранировать на входе — ну тут правда вопрос. Согласен что сами данные на входе опасности не несут, ее несет обрабатывающий код.
Экранировать на входе — ну тут правда вопрос. Согласен что сами данные на входе опасности не несут, ее несет обрабатывающий код.
$name = strip_tags($_POST['name']);
$name = htmlentities($_POST['name'], ENT_QUOTES, «UTF-8»);
$name = htmlspecialchars($_POST['name'], ENT_QUOTES);
Что это за кусок бреда?
Потом люди читают такие статьи и пишут свои битриксы, где дырка на дырке.
$name = htmlentities($_POST['name'], ENT_QUOTES, «UTF-8»);
$name = htmlspecialchars($_POST['name'], ENT_QUOTES);
Что это за кусок бреда?
Потом люди читают такие статьи и пишут свои битриксы, где дырка на дырке.
Как, на Ваш взгляд, правильно?
Правильно понимать, что вообще происходит и действовать в соответствии с этим.
А люди не понимают, но они где-то краем уха слышали про какие-то плохие символы, которые надо фильтровать. И они фильтруют всеми подряд функциями какие найдут, вырезают зачем-то теги и РЕЖУТ КАВЫЧКИ ВО ВХОДНЫХ ДАННЫХ СРЕДСТВАМИ СЕРВЕРА!!! Капец.
Нет плохих данных, никакие данные сами по себе навредить не могут.
Только код, который обрабатывает эти данные.
Так и фильтровать/экранировать нужно только в момент обработки и только так, как эти обработка предполагает.
А люди не понимают, но они где-то краем уха слышали про какие-то плохие символы, которые надо фильтровать. И они фильтруют всеми подряд функциями какие найдут, вырезают зачем-то теги и РЕЖУТ КАВЫЧКИ ВО ВХОДНЫХ ДАННЫХ СРЕДСТВАМИ СЕРВЕРА!!! Капец.
Нет плохих данных, никакие данные сами по себе навредить не могут.
Только код, который обрабатывает эти данные.
Так и фильтровать/экранировать нужно только в момент обработки и только так, как эти обработка предполагает.
Человек прав. Подобный подход «бездумной» комбинации фильтрующих функций сам по себе может создать баг, и лишь говорит о не компетенции советующего в данном вопросе. К сожалению, не все кулхацкеры умеют что-то тольковое советовать в разработке и обеспечении безопасности.
Если контекст вывода — html, то фильтровать надо при обработке функцией htmlspecialchars с нужной комбинацией флагов, в зависимости, опять-таки, от контекста использования конкретно этих данных в конкретном месте приложения.
Если контекст вывода — html, то фильтровать надо при обработке функцией htmlspecialchars с нужной комбинацией флагов, в зависимости, опять-таки, от контекста использования конкретно этих данных в конкретном месте приложения.
В статье приведены функции php, а не их комбинация.
Фильтрация не предполагает бездумных решений, Вы абсолютно правы.
Фильтрация не предполагает бездумных решений, Вы абсолютно правы.
Тогда уж, наверное, стоит воспользоваться встроенным механизмом фильтрации
При записи в бд каких либо данных от пользователя фильтроваться должно от инъекции.
При выдаче результата из базы должны экранироваться теги.
Это конечно я «грубо», иногда зависит от ситуации, но для первого правила должно быть именно так.
При выдаче результата из базы должны экранироваться теги.
Это конечно я «грубо», иногда зависит от ситуации, но для первого правила должно быть именно так.
Кстати, в php есть замечательная функция filter_var которая может как в валидацию данных так и в их очистку с нужными флагами.
Вопрос автору: на каком решении Вы тестировали данную уязвимость? Попробовал в Битрикс-лаборатории, у поля «NAME» у пользователя ограничение в 50 символов — Ваш HTML в принципе режется при добавлении (как Вы тестировали?). Но даже если его сократить, то все равно изображение упорно отказывается отображаться ))
Конечно, существуют ограничения, которые не позволят реализовать и эксплуатировать атаку.
Суть проблемы в том, что для огромного количества сайтов, созданных на платформе 1С-Битрикс — эта уязвимость актуальна.
Кроме этого, в апреле, я передал всю информацию в Битрикс.
Естественно, на их ресурсах, этой проблемы нет.
Суть проблемы в том, что для огромного количества сайтов, созданных на платформе 1С-Битрикс — эта уязвимость актуальна.
Кроме этого, в апреле, я передал всю информацию в Битрикс.
Естественно, на их ресурсах, этой проблемы нет.
Просто интересно, а что могут сделать в Битриксе?
Их стандартные компоненты этой уязвимостью не страдают. В админке кстати тоже.
Уязвимы только сайты, которые работают напрямую с API (моделью), минуя стандартные компоненты (контроллеры) и вьюхи (шаблоны). И при этом не фильтруют данные.
Т.е. криворукие быдлокодеры накосорезили, но виноват, разумеется, Битрикс.
Самое смешное, что Битрикс ничего в этом случае сделать не может. Ещё раз, API — это модель, её задача хранить данные как есть, и в ней, вообще говоря, ошибок нет. Добавлять в неё фильтрацию, htmlspecialchars и т.п. — нельзя, это сломает вообще кучу всего.
Их стандартные компоненты этой уязвимостью не страдают. В админке кстати тоже.
Уязвимы только сайты, которые работают напрямую с API (моделью), минуя стандартные компоненты (контроллеры) и вьюхи (шаблоны). И при этом не фильтруют данные.
Т.е. криворукие быдлокодеры накосорезили, но виноват, разумеется, Битрикс.
Самое смешное, что Битрикс ничего в этом случае сделать не может. Ещё раз, API — это модель, её задача хранить данные как есть, и в ней, вообще говоря, ошибок нет. Добавлять в неё фильтрацию, htmlspecialchars и т.п. — нельзя, это сломает вообще кучу всего.
Подавляющее число интеграторов Битрикс используют стандартные компоненты, в данном случае компонент регистрации. Вот что навскидку нашел в коде компонента:http://prnt.sc/c5x1x6 — уж не то ли это преобразование спецсимволов в HTML-сущности, о которых Вы пишете в статье? ;)
Сдается мне, кто-то захотел срубить кармы на врожденной неприязни у хабраюзеров к Битриксу ))
Сдается мне, кто-то захотел срубить кармы на врожденной неприязни у хабраюзеров к Битриксу ))
Карма — это хорошо, а предупредить разработчика о потенциально возможной проблеме — еще лучше.
В Битрикс эту проблему еще в апреле отправил, и меры были приняты, многое исправлено.
При всем этом, актуальность этой угрозы безопасности сохраняется и сегодня.
В Битрикс эту проблему еще в апреле отправил, и меры были приняты, многое исправлено.
При всем этом, актуальность этой угрозы безопасности сохраняется и сегодня.
Подавляющее число т.н. «веб-студий» могут делать сайты на стандартных компонентах. Интеграторы в полном понимании этого слова практически никогда не встречаются с задачами, где можно обойтись штатными компонентами, и вынуждены использовать API. Для того API и предоставляется платформой — чтобы его использовать.
Т.е. «интеграторы в полном понимании этого слова» изобретают велосипеды вместо того, чтобы пользоваться готовыми решениями, упрощающими разработку, правильно я Вас понимаю? Теперь понятно, откуда ноги растут у расценок тру-интеграторов )))
Но речь не о том, что понимать под «интегратором», а что под «т.н. веб-студиями» (но попытку подмены тезиса я оценил, Вы молодец )), а в том, что в стандартных компонентах данные уже фильтруются, и уязвимости нет — проблема автором высосана из пальца. Ну а фильтровать данные в собственном решении Вам никто не запрещает
Но речь не о том, что понимать под «интегратором», а что под «т.н. веб-студиями» (но попытку подмены тезиса я оценил, Вы молодец )), а в том, что в стандартных компонентах данные уже фильтруются, и уязвимости нет — проблема автором высосана из пальца. Ну а фильтровать данные в собственном решении Вам никто не запрещает
Где Вы видите подмену?
Все правильно написано.
В статье, я также обращаю внимание на то, что у готового интернет-магазина «из коробки» проблема отсутствует.
Но при разработке серьезных проектов, штатных компонентов недостаточно, используется API.
Проблема возникает именно в этом случае, и встречается крайне часто.
На счет «проблема высосана из пальца» — Ваше мнение.
Все правильно написано.
В статье, я также обращаю внимание на то, что у готового интернет-магазина «из коробки» проблема отсутствует.
Но при разработке серьезных проектов, штатных компонентов недостаточно, используется API.
Проблема возникает именно в этом случае, и встречается крайне часто.
На счет «проблема высосана из пальца» — Ваше мнение.
Таким образом, из Вашей статьи и дальнейшего обсуждения следует:
Что интересно — криворукие разработчики встречаются на любой платформе, так почему именно Битрикс? Возможно потому, что просто очередную статью о фильтрации данных форм никто бы и читать не стал. Впрочем, как Вы верно заметили, это мое мнение, как и все, написанное мной ранее — нет нужды лишний раз это подчеркивать. ;)
- коробочные решения и системные компоненты защищены и уязвимость в них не проявляется
- API Битрикс позволяет разработчикам совершать ошибки при разработке собственных решений и компонентов
- Вывод: в API Битрикс существует уязвимость (уязвимость типа «недалекий разработчик», видимо)
Что интересно — криворукие разработчики встречаются на любой платформе, так почему именно Битрикс? Возможно потому, что просто очередную статью о фильтрации данных форм никто бы и читать не стал. Впрочем, как Вы верно заметили, это мое мнение, как и все, написанное мной ранее — нет нужды лишний раз это подчеркивать. ;)
UFO just landed and posted this here
Все верно:
1. У «коробки» Битрикс этой проблемы нет.
2. API Битрикс действительно позволяет совершать ошибки разработчикам.
3. На счет уязвимости типа «недалекий разработчик», не соглашусь с Вами.
Дело в том, что изначально, в документации к API Битрикс:
http://dev.1c-bitrix.ru/api_help/forum/developer/cforumtopic/getlist.php
Были приведены примеры использования, а именно:
После того, как информацию по проблеме была предоставлена Битрикс, пример был «отредактирован»:
Поэтому, я не согласен с Вами, только в части «криворуких разработчиков», а так, все верно.
1. У «коробки» Битрикс этой проблемы нет.
2. API Битрикс действительно позволяет совершать ошибки разработчикам.
3. На счет уязвимости типа «недалекий разработчик», не соглашусь с Вами.
Дело в том, что изначально, в документации к API Битрикс:
http://dev.1c-bitrix.ru/api_help/forum/developer/cforumtopic/getlist.php
Были приведены примеры использования, а именно:
while ($ar_res = $db_res->Fetch())
{
echo $ar_res["TITLE"]."<br>";
}
После того, как информацию по проблеме была предоставлена Битрикс, пример был «отредактирован»:
while ($ar_res = $db_res->Fetch())
{
echo htmlspecialcharsbx($ar_res["TITLE"])."<br>";
}
Поэтому, я не согласен с Вами, только в части «криворуких разработчиков», а так, все верно.
UFO just landed and posted this here
Предупрежден — значит вооружен. Согласен со stavinsky, экранирование должно быть сделано фреймворком по умолчанию.
Встречал как-то эксплуатацию подобной html инъекции в почте мейл.ру года 4 назад.
В письмо встраивался html + inline css код, который добавлял прозрачный слой с position:absolute на весь экран, обернутый в ссылку на фейк сайт злоумышленника.
Так, как слой перекрывал весь интерфейс почты, по любому клику в любом месте происходил редирект на фейк, который выглядел как страница логина в мейл.ру и невнимательный пользователь думал, что его просто выкинуло из сессии при входе в просмотр письма и клику например на «Входящие». Я к тому, что сценарии эксплуатации подобных вещей имеются, но немало зависит от контекста. В почте это было опасно.
В письмо встраивался html + inline css код, который добавлял прозрачный слой с position:absolute на весь экран, обернутый в ссылку на фейк сайт злоумышленника.
Так, как слой перекрывал весь интерфейс почты, по любому клику в любом месте происходил редирект на фейк, который выглядел как страница логина в мейл.ру и невнимательный пользователь думал, что его просто выкинуло из сессии при входе в просмотр письма и клику например на «Входящие». Я к тому, что сценарии эксплуатации подобных вещей имеются, но немало зависит от контекста. В почте это было опасно.
А в шаблоне ЛК использовать htmlspecialchars религия не позволяет?
Данные в базе должны храниться в том виде, в котором их ввел пользователь. Фильтровать только при выводе.
Данные в базе должны храниться в том виде, в котором их ввел пользователь. Фильтровать только при выводе.
В Битриксе всё ещё хитрее, специально для таких вот «специалистов».
Данные фильтруются в контроллере («компоненте» в терминах битрикса), чтобы мега-разработчик шаблона выводил $arUser[«NAME»] и не задумывался о фильтрации. Но для тех случаев, когда нужны нефильтрованные данные, компонент добавляет специальный ключ $arUser["~NAME"], о котором знают не только лишь все.
Данные фильтруются в контроллере («компоненте» в терминах битрикса), чтобы мега-разработчик шаблона выводил $arUser[«NAME»] и не задумывался о фильтрации. Но для тех случаев, когда нужны нефильтрованные данные, компонент добавляет специальный ключ $arUser["~NAME"], о котором знают не только лишь все.
я в курсе, только это не мешало мне по привычке фильтровать вывод в своих шаблонах/компонентах при работе с базой, это как на горшок ходить.
Абсолютно верно подмечено. Все пытался найти ссылку на документацию. Спасибо vanxant
Если писать на PHP, то Вы правы. Но чем круче фреймворк, тем больше от него ожиданий. Битрикс — не Laravel, а крайне мощная платформа, и, учитывая заявленный «Проактивный фильтр», требования к нему соответствующие.
Если битрикс — фреймверк, то где я могу найти описание как я могу использовать его компоненты в других проектах(не битрикс)? Вот например в symfony это реализовано так http://symfony.com/components
Мопед не мой (с). Часть Битрикса теперь официально именуется Bitrix Framework. Никто не запрещает не использовать админку Битрикса, не использовать никакие штатные компонента Битрикса и использовать Битрикс только в качестве фреймворка.
Часть Битрикса теперь официально именуется Bitrix Framework
Ну именовать они могут как угодно, но это не означает что так и есть.
Никто не запрещает не использовать админку Битрикса, не использовать никакие штатные компонента Битрикса и использовать Битрикс только в качестве фреймворка.
Ну во первых это не тоже самое, с тем что я приводил для примера с symfony components. Во вторых, мне страшно представить, что будет если брать их сборник низкокачественного кода и что-то на нем делать.
Вообще то в битрикс есть авто-тесты кода которые укажут на то что используется не экранированный $_POST и посоветуют использовать функцию htmlspecialcharsbx
Если бы разработчики битрикса использовали нормальную архитектуру, то это бы позволило внедрить TDD который бы еще на этапе разработки исключал 85% — 95% багов и брешей безопасности. А данный костыль в виде «авто-тесты кода» не более чем «подорожник» который просто не способен качественно обработать кучи строк низкокачественного кода самого битрикса.
Функция есть, а авто-тесты не видят проблемы.
И при чем тут собственно Битрикс? Это не вина Битрикса, что разработчики не фильтруют входные данные.
Был как-то забавный случай: сайт на «1С-Битрикс: Корпоративный портал», форма загрузки файлов, все потенциально опасные расширения фильтровались, всё ок. Но. Заметил, что если в имя файла добавить, например, символ процента (%), то данный символ при загрузке заменяется на случайный символ [a-z]. Сделал 30 файлов (с запасом, ага) вида <1-shell.ph%>, загрузил в форму и получил один из файлов <1-shell.php>, т.е. получил шелл. Конечно, проблема еще в том, что было разрешено исполнение файлов из папки </upload/>. Это я к тому, что фильтрации расширений мало.
Заголовок спойлера
Не надейтесь на фильтрацию по расширению. :)#bitrix #security #shell #1c pic.twitter.com/rXAwP6DjP1
— p0z (@a_p0z) 27 апреля 2016 г.
Ничего себе! А когда это было?
Из смешного, в последнее время, только обход фильтра по типу ononclick='JS', когда фильтр Битрикс синтаксически 'on' отрезал, для блокировки той-же XSS. Сейчас, конечно, фильтр проактивки стал достаточно серьезным.
Из смешного, в последнее время, только обход фильтра по типу ononclick='JS', когда фильтр Битрикс синтаксически 'on' отрезал, для блокировки той-же XSS. Сейчас, конечно, фильтр проактивки стал достаточно серьезным.
В ваших конфигах для веб-серверов не учтены частные случаи:
- иногда люди заключают атрибуты тегов не в кавычки, а в апострофы
- когда пользовательский ввод вставляется в генерируемый на серверной стороне js (запрета символа " явно недостаточно, надо добавить ' и { })
UFO just landed and posted this here
DeLuxis, так это зависит от Владельцев или студий сопровождающие сайты\интернет-магазины, которым не безразлична безопасность собственных проектов.
К тому же, вариант устранения уязвимости, так же представлен в статье, нужно только воспользоваться предложенным решением, хотя именно это самое сложное, воспользоваться.....:)))))
1. Это не вина Битрикса, что разработчики не думают головой. Такое можно сделать везде.
2. htmlspecialchars и т.п. — не панацея от xss.
3. Часто нужно хранить сырые данные.
2. htmlspecialchars и т.п. — не панацея от xss.
3. Часто нужно хранить сырые данные.
Никто не говорит про платформу Битрикс, как о источнике угрозы.
Выше, в комментариях я написал, что явилось (как один из вариантов) причиной появления систематики этой угрозы безопасности.
Если говорить о вышеописанной проблеме, то есть больше сомнения в целесообразности хранения этих данных «сырыми».
На счет защиты и панацеи, htmlspecialchars — является одним из способов защиты от XSS.
Выше, в комментариях я написал, что явилось (как один из вариантов) причиной появления систематики этой угрозы безопасности.
Если говорить о вышеописанной проблеме, то есть больше сомнения в целесообразности хранения этих данных «сырыми».
На счет защиты и панацеи, htmlspecialchars — является одним из способов защиты от XSS.
1. Но предалагается, чтобы Битрикс что-то фиксил.
2. Один из способов, но не панацея. xss успешно пролезают через него, если понадеятся только на него.
3. Ну в этом случае сырые данные может не нужны. А в другом нужны.
Допустим name — это логин.
Тогда для фильтрации обработку нужно будет использовать еще в фильтре.
А если мы потом изменим второй параметр в htmlspecialchars($_POST['name'], ENT_QUOTES);
Или захотим вообще вырезать hmtl.
Или нужно пропустить часть html — ссылки, списки, рисунки (в комментрии пользователя к статье).
:)
2. Один из способов, но не панацея. xss успешно пролезают через него, если понадеятся только на него.
3. Ну в этом случае сырые данные может не нужны. А в другом нужны.
Допустим name — это логин.
Тогда для фильтрации обработку нужно будет использовать еще в фильтре.
А если мы потом изменим второй параметр в htmlspecialchars($_POST['name'], ENT_QUOTES);
Или захотим вообще вырезать hmtl.
Или нужно пропустить часть html — ссылки, списки, рисунки (в комментрии пользователя к статье).
:)
Первый попавшийся интернет магазин на битриксе. http://joxi.ru/Vm6xjdghxed6bA. Встроенный сканер не помог.
кидайте в меня ссаными тряпками, но мы ждем имя, так пусть будет имя, все, что не разрешено — запрещено:
preg_match('/^[-_a-zа-я0-9]{3,100}$/ui',$_POST['name'])
Sign up to leave a comment.
Cистематическая уязвимость сайтов, созданных на CMS 1С-Битрикс