Cross site scripting битрикс как исправить

Доброго времени. Сканер безопасности выдает проблему по Cross-Site Scripting:

Файл: /usr/share/phpMyAdmin/vendor/paragonie/random_compat/other/build_phar.php
32: echo 'Could not read the private key file:',$argv[1],"n"

Необходимые условия:
30: if($argc > 1)
31: if(!is_readable($argv[1]))

Сам файл «build_phar»:

<?php
$dist = dirname(__DIR__).'/dist';
if (!is_dir($dist)) {
    mkdir($dist, 0755);
}
if (file_exists($dist.'/random_compat.phar')) {
    unlink($dist.'/random_compat.phar');
}
$phar = new Phar(
    $dist.'/random_compat.phar',
    FilesystemIterator::CURRENT_AS_FILEINFO | FilesystemIterator::KEY_AS_FILENAME,
    'random_compat.phar'
);
rename(
    dirname(__DIR__).'/lib/random.php', 
    dirname(__DIR__).'/lib/index.php'
);
$phar->buildFromDirectory(dirname(__DIR__).'/lib');
rename(
    dirname(__DIR__).'/lib/index.php', 
    dirname(__DIR__).'/lib/random.php'
);

/**
 * If we pass an (optional) path to a private key as a second argument, we will
 * sign the Phar with OpenSSL.
 * 
 * If you leave this out, it will produce an unsigned .phar!
 */
if ($argc > 1) {
    if (!@is_readable($argv[1])) {
        echo 'Could not read the private key file:', $argv[1], "n";
        exit(255);
    }
    $pkeyFile = file_get_contents($argv[1]);
    
    $private = openssl_get_privatekey($pkeyFile);
    if ($private !== false) {
        $pkey = '';
        openssl_pkey_export($private, $pkey);
        $phar->setSignatureAlgorithm(Phar::OPENSSL, $pkey);
        
        /**
         * Save the corresponding public key to the file
         */
        if (!@is_readable($dist.'/random_compat.phar.pubkey')) {
            $details = openssl_pkey_get_details($private);
            file_put_contents(
                $dist.'/random_compat.phar.pubkey',
                $details['key']
            );
        }
    } else {
        echo 'An error occurred reading the private key from OpenSSL.', "n";
        exit(255);
    }
}

Подскажите что не так? Заранее благодраен. Извиняюсь если не там создал тему.

При проверке обнаружена уязвимость Cross-Site Scripting

ID статьи: 154
, создана 28 окт 2016

При анализе уязвимостей было обнаружено проблемное место.

Статический анализ уязвимостей обнаружил 1 проблемных мест Важно!
	 Cross-Site Scripting
	 Файл: /_!/bitrix/tmp/templates/__bx_preview/components/aspro/oneclickbuy/shop/template.php
	 53:  $arSkuProps  =  explode ( ";" , $_REQUEST [ 'OFFER_PROPS' ] )
	 55:  echo   serialize ( $arSkuProps )
	 Необходимые условия:
	 52:  if ( $_REQUEST [ 'OFFER_PROPS' ] )



  


                       
  



	 Разрешено подключение файлов по URL (URL wrappers) Важно!
	 Эта опция php крайне противопоказана

	 allow_url_include = Off Свернуть 

XSS (межсайтовый скриптинг) – одна из разновидностей атак на веб-системы, которая подразумевает внедрение вредоносного кода на определенную страницу сайта и взаимодействие этого кода с удаленным сервером злоумышленников при открытии страницы пользователем.

Термин с английского расшифровывается как Cross-Site Scripting, но при этом получил аббревиатуру XSS, чтобы не было путаницы с CSS (каскадные таблицы стилей).

Как работает межсайтовый скриптинг

Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.

Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.

Методика атаки через XSS

Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).

Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:

<script>alert(«cookie: «+document.cookie)</script>

Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, WordPress. Чаще всего XSS-уязвимости проверяются в браузере Internet Explorer.

Еще один возможный вариант поиска – использование страниц, которые обрабатывают GET-запросы. Допустим, у нас есть ссылка вида: https://site.ru/catalog?p=8

В адресной строке вместо идентификатора (8) добавляем скрипт – «><script>alert(«cookie: «+document.cookie)</script>, в результате чего получаем ссылку такого вида: https://site.ru/catalog?p=&quot;&gt;&lt;script&gt;alert(&quot;cookie: «+document.cookie)</script>.

Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.

Для поиска «дыр» на сайте существует огромное количество готовых скриптов и запросов, и если ни один из них не подходит, значит ресурс надежно защищен от подобных атак.

Общая классификация XSS

Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.

Хранимые XSS (постоянные). Один из самых опасных типов уязвимостей, так как позволяет злоумышленнику получить доступ к серверу и уже с него управлять вредоносным кодом (удалять, модифицировать). Каждый раз при обращении к сайту выполняется заранее загруженный код, работающий в автоматическом режиме. В основном таким уязвимостям подвержены форумы, порталы, блоги, где присутствует возможность комментирования в HTML без ограничений. Вредоносные скрипты с легкостью могут быть встроены как в текст, так и в картинки, рисунки.

Отраженные XSS (непостоянные). В этом случае вредоносная строчка выступает в роли запроса жертвы к зараженному веб-сайту. Работает этот принцип по следующей схеме:

1. Злоумышленник заранее создает URL-ссылку, которая будет содержать вредоносный код и отправляет его своей жертве.
2. Она направляет этот URL-запрос на сайт (переходит по ссылке).
3. Сайт автоматически берет данные из вредоносной строки и подставляет в виде модифицированного URL-ответа жертве.
4. В итоге в браузере у жертвы выполняется вредоносный скрипт, который и содержится в ответе, а злоумышленник получает все cookies этого пользователя.

DOM-модели. В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:

1. Злоумышленник создает URL-адрес, который заранее содержит вредоносный код, и отправляет его по электронной почте или любым другим способом пользователю.
2. Человек переходит по этой ссылке, зараженный сайт принимает запрос, исключая вредоносную строку.
3. На странице у пользователя выполняется сценарий, в результате чего загружается вредоносный скрипт и злоумышленник получает cookies.

Виды XSS по способу взаимодействия

Так как основная цель злоумышленника – запустить вредоносный скрипт на компьютере жертвы, существует еще и два основных типа XSS-атак по способу взаимодействия.

Пассивные. От жертвы требуется определенное действие, чтобы вызвать обработчик событий и запустить вредоносный скрипт в установленной форме. Для этого используется социальная инженерия, например отправка электронного письма с призывом перейти по ссылке и нажать на определенную область на сайте. Как только пользователь наведет на нужный объект и кликнет по нему, запустится вредоносный скрипт. Если же жертва бездействует, код не будет активирован.

Активные. Злоумышленнику не нужно заманивать жертву по специальным ссылкам, так как код встраивается в базах данных или в каком-нибудь исполняемом файле на сервере. От пользователя не требуется никакой активности. У форм ввода, как правило, установлен специальный обработчик событий, автоматически активирующийся при попадании на эту страничку. В итоге все пользователи, перешедшие по этой ссылке, станут жертвами злоумышленника.

Как проверить сайт на наличие уязвимостей XSS и защитить его

Для быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать https://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.

Подобные сервисы не дают полной гарантии успеха, поэтому рекомендуем проверять найденные страницы в ручном режиме и обязательно исключить все опасные спецсимволы, заменив их безопасными. Речь идет о скобках < и >, в которых и прописываются все зарезервированные языком html-запросы и теги.

Например, для быстрой фильтрации и автоматической замены спецсимволов < и > вы можете использовать следующий код на сайте:

$filter = array(«<«, «>»);

$_GET[‘q’]=str_replace ($filter, «|», $_GET[‘q’]).

Несколько советов по предотвращению использования XSS на вашем сайте:

1. Если на вашем сайте включен пользовательский ввод, должно выполняться кодирование.
2. Если кодирование невозможно или неуместно в некоторых ситуациях, заменяйте его или дополняйте валидацией.
3. Безопасная обработка данных должна выполняться в коде не только на стороне вашего web-сервера, но и на стороне пользователя (клиента).
4. Если используете популярные CMS, например WordPress, Bitrix, Joomla, регулярно обновляйте версии движка и всех установленных модулей и плагинов. По умолчанию большинство самых распространенных систем для управления сайтов защищены от использования XSS, а вот сторонние плагины из непроверенных источников могут содержать уязвимости.

да читал — сейчас список рекомендаций напротив тестов
1. Используется проактивная защита. Минимальный уровень — «Стандартный» — Выявлены следующие недочеты:
1. Уровень безопасности административной группы не является повышенным — хотя я в настройках поставил уровень повышенный?
2. Административные учетные записи — защищены —
В разделе «Настройки > Пользователи > Группы пользователей > Администраторы (ID группы = 1) на вкладке «Безопасность» в списке «Предопределенные настройки уровня безопасности» должно быть установлено значение «Повышенный» (или выше).

Там же на вкладке «Параметры» в разделе «Пользователи в группе» проверьте, какие учетные записи включены в группу «Администраторы». Для них необходимо включить использование одноразовых паролей.

В разделе «Настройки > Проактивная защита > Одноразовые пароли» должно быть включено использование одноразовых паролей.
В форме редактирования параметров каждой административной учетной записи: «Настройки > Пользователи > Список пользователей» на вкладке «Одноразовые пароли» должно быть настроено и включено их использование.
Также рекомендуется, при необходимости, использовать повышенный уровень безопасности (и возможно одноразовые пароли) для учетных записей других привилегированных групп, таких как администраторы магазина, администраторы каталогов и т.п.

5. Настроены политики безопасности по работе с БД — 1. Пароль к БД не содержит знаков препинания
6. Отключен вывод ошибок и предупреждений посетителям проект -1 1. Включен вывод ошибок пользователям — как Отключить?
8. Проверена безопасность кода (статический анализ уязвимостей)
Файл: /extranet/pk/ajax_cell_change.php

1
2
3
4

Cross-Site Scripting
11: $spec_id = $_GET['spec_id']
48: echo $spec_id . $class . $val
?

Файл: /extranet/pk/ajax_cell_change.php

1
2
3
4

Cross-Site Scripting
12: $class = $_GET['class']
48: echo $spec_id . $class . $val
?

Файл: /extranet/pk/ajax_cell_change.php
Cross-Site Scripting
14:

1
2
3

 $val = $_GET['val']
48: echo $spec_id . $class . $val
?

Файл: /extranet/lector/ajax_del_publication.php
Cross-Site Scripting
90:

1

 echo '</td><td><button type="button" class="pubbtn" href="javascript:void(0)" onclick="DelPublication(' . $arFields['ID'] . ',' . $_POST['user_id'] . ');">Удалить публикацию</button></td>'

Необходимые условия:
?
Файл: /extranet/lector/ajax_add_publication.php
Cross-Site Scripting
86:

1

echo '</td><td><button type="button" class="pubbtn" href="javascript:void(0)" onclick="DelPublication(' . $arFields['ID'] . ',' . $_POST['user_id'] . ');">Удалить публикацию</button></td>'

Необходимые условия:
?
Файл: /extranet/pk_admin/ajax_cell_change.php
Cross-Site Scripting

1
2
3

10: $spec_id = $_GET['spec_id']
31: echo $spec_id . $class . $val . "celn=" . $celn
?

Файл: /extranet/pk_admin/ajax_cell_change.php
Cross-Site Scripting
11:

1
2
3

$class = $_GET['class']
31: echo $spec_id . $class . $val . "celn=" . $celn
?

Файл: /extranet/pk_admin/ajax_cell_change.php
Cross-Site Scripting
13:

1
2
3

$val = $_GET['val']
31: echo $spec_id . $class . $val . "celn=" . $celn
?

Файл: /extranet/pk_admin/ajax_cell_change.php
Cross-Site Scripting

1
2
3

12: $celn = $_GET['celn']
31: echo $spec_id . $class . $val . "celn=" . $celn
?

Файл: /extranet/dispetcher/ajax_filter_aud.php
Cross-Site Scripting

1
2
3
4
5

15: $id = $_POST['elem_id']
48: echo 'Аудитория: <select id="' . $id . '">'
Необходимые условия:
19: if(CModule::includemodule("iblock"))
?

Файл: /extranet/dispetcher/ajax_contract_compile.php
Выполнение произвольных команд

1
2

7: $filename = "contract_" . $kaf_id_zup . "_" . $user_id . "_tutor"
23: exec('cd ' . $_SERVER['DOCUMENT_ROOT'] . '/bitrix/components/ulstu/pozhelanya.form/tex/; /usr/bin/pdflatex --shell-escape --synctex=1 -output-directory ' . $_SERVER['DOCUMENT_ROOT'] . '/upload/ulstu/student_course_contracts --interaction batchmode ' . $filename . '.tex',$r)

Аналогично:

1
2

28: print "<a href='/upload/ulstu/student_course_contracts/$filename.pdf'>Загрзите бланк договора ГПХ</a> "
?

Файл: /extranet/lector/pozhelanya/ajax_filter_aud.php
Cross-Site Scripting

1
2
3
4
5

15: $id = $_POST['elem_id']
48: echo 'Аудитория: <select id="' . $id . '">'
Необходимые условия:
19: if(CModule::includemodule("iblock"))
?

Файл: /extranet/lector/pozhelanya/ajax_contract_compile.php
Выполнение произвольных команд

1
2

116: $filename = "contract_" . $kaf_id_zup . "_" . $user_id . "_tutor"
143: exec('cd ' . $_SERVER['DOCUMENT_ROOT'] . '/bitrix/components/ulstu/pozhelanya.form/tex/; /usr/bin/pdflatex --shell-escape --synctex=1 -output-directory ' . $_SERVER['DOCUMENT_ROOT'] . '/upload/ulstu/student_course_contracts --interaction batchmode ' . $filename . '.tex',$r)

Аналогично:

1
2

148: print "<a href='/upload/ulstu/student_course_contracts/$filename.pdf'>Загрузите бланк договора ГПХ</a>"
?

Файл: /extranet/heads/shtaty/ajax_get_parent_hours.php
Cross-Site Scripting

1
2

8: $fields = getiblockelement($ib_id)
9: echo $fields['PROPERTIES']['CHASY']['VALUE']

Необходимые условия:

1
2

6: if(CModule::includemodule("iblock"))
?

Файл: /extranet/heads/shtaty/podpis_init_action.php
Cross-Site Scripting

1
2
3
4
5

5: $section_id = $_GET['id_raschet']
47: echo '</select><div id="hidden_fault' . $section_id . '" style="display:none;"><input id="fault' . $section_id . '" type="text" value="fault"></div>'
Необходимые условия:
3: if(CModule::includemodule("iblock"))
44: if($non)

Аналогично:

1
2
3

50: echo '</select><div id="hidden_fault' . $section_id . '" style="display:none;"><input id="fault' . $section_id . '" type="text" value="nofault"></div>'
56: echo '<input id="podsvetka' . $section_id . '" type="text" value=' . $je . '>'
?

Файл: /extranet/heads/shtaty/sotrudnik_init_action.php
Cross-Site Scripting

1
2

5: $kaf_id = $_GET['kaf_id']
7: echo ' <form action="" id="myform"> <table> <tr> <td>Фамилия:</td> <td><input type="text" name="SecName" id="sSecName' . $kaf_id . '" /><br></td></tr> <tr> <td>Имя:</td><td><input type="text" name="Name" id="sName' . $kaf_id . '" /> <br></td></tr> <tr> <td>Отчество:</td> <td> <input type="text" name="FazName" id="sFazName' . $kaf_id . '" /><br></td></tr> <tr> <td>Дата рождения:</td> <td> <input type="text" name="DOB" id="sDOB' . $kaf_id . '" /></td></tr> </table> </form> <div class="sotrsquare1" id=s_1_' . $kaf_id . '></div>'

Необходимые условия:

1
2
3
4
5
6
7
8
9

3: if(CModule::includemodule("iblock"))
?
Файл: /extranet/heads/shtaty/sotrudnik_search_ones.php
Cross-Site Scripting
16: $kaf_id = $_GET['kaf_id']
77: echo '<a href="javascript: submit_select_sotrudnik_Form('' . $kaf_id . '')">Выбрать</a>  </form>'
Необходимые условия:
4: if(CModule::includemodule("iblock"))
43: if((is_array($result->return->fls)) || ($result->return->fls->SecName))

Аналогично:

1

80: echo '<form action="#n" name="theFormadd">  <label for="gender">Сотрудник не найден! </label><br>  <a href="javascript: submit_add_sotrudnik_Form('' . $kaf_id . '')">Добавить нового?</A>     <br>

Для добавления нового сотрудника заполните все поля формы! </form>’
?
Файл: /extranet/heads/shtaty/init_action.php
Cross-Site Scripting
8:

1

 echo '<a  title="Создать новый расчет штатов" class="sidebar-button" href="javascript:void(0)"  onclick="ShowForm_add_popup('' . $_GET['kaf_id'] . '', ' . $_GET['kaf_name'] . ' , ' . $_GET['creator_id_univ'] . ');">        <span class="sidebar-button-top"><span class="corner left"></span><span class="corner right"></span></span>         <span class="sidebar-button-content"><span class="sidebar-button-content-inner"> <i class="sidebar-button-create"></i><b>Новое распределение</b></span></span><span class="sidebar-button-bottom"><span class="center"></span><span class="corner right"></span></span></a> <div class="square2" id="' . $_GET['kaf_id'] . '">'

Необходимые условия:
3: if(CModule::includemodule(«iblock»))
?
Файл: /extranet/heads/shtaty/podpis_action.php
Cross-Site Scripting

1
2
3
4

10: $KAF_ID_ZUP = $_GET['kaf_id']
284: echo "Кафедра, для которой создаётся папка: " . $KAF_ID_ZUP
Необходимые условия:
3: if(CModule::includemodule("iblock"))  что исправить?

9. Проверка сканером безопасности 1

Отсутствуют критические замечания в разделе «Настройки > Проактивная защита > Сканер безопасности». Информация о результатах сканирования не является устаревшей.
Как тестировать

Платформа имеет встроенный набор автотестов для проверки на предмет наличия распространенных уязвимостей. Часть тестов проводится с внешних серверов 1С-Битрикс. Для безопасной работы веб-проекта все критические угрозы должны быть устранены.

В разделе «Настройки > Проактивная защита > Сканер безопасности» не должно быть обнаружено критических угроз.
Как решить? — напишите напротив каждого пункта?

Хотели написать статью об инструментах безопасности «1С-Битрикс», но постепенно «зарылись» в проблемах с этой самой безопасностью. И как оказалось, тема эта весьма актуальная. Несмотря на общепризнанный высокий уровень защищенности «Битрикс» и сегодня находятся «прорехи», которые могут причинить серьезные неприятности.

Поэтому предлагаем подробнее остановиться именно на постановке проблемы. Тем более, что именно наличие уязвимостей, как нельзя лучше говорит о необходимости высокой защиты вашего eCommerce-ресурса. А к анализу методов достижения высокого уровня безопасности разработчиками «1С-Битрикс» вернемся позже.

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

XSS-атака

Под данным Bitrix Hub кросс-скриптинг (межсайтовый скриптинг, XSS-атаки) возглавляет топ уязвимостей проектов на «1С-Битрикс: Управление сайтом». Проблема актуальна, когда в коде интернет-проекта присутствуют скрипты, предоставляющие злоумышленнику возможность использовать вызовы переменных и выполнять вредоносные операции. Главная причина такого положения вещей – отсутствие или недостаточно надежная фильтрация параметров, передаваемых скриптам. Проще говоря, проблема появляется, когда данные, принимаемые от пользователя, выводятся в браузер без необходимой фильтрации.

Специалист по информационной безопасности компании «1С-Битрикс» М. Низамутдинов разъясняет: XSS-атака может быть использована для изменения вида HTML-страниц уязвимого ресурса в контексте браузера целевого пользователя, похищения COOKIE данных браузера целевого пользователя, с последующим внедрением в его сессию, под его учетной записью.

Стоит также отметить, что эта уязвимость не является специфической проблемой для «1С-Битрикс», а возникает ввиду некачественного пользовательского кода. И чем больше фрилансеров, студий и штатных программистов работают с сайтом, тем выше вероятность стать обладателем подобной «дыры».

Источник

В качестве средства защиты от подобных посягательств представитель компании-разработчика рекомендует: «Использовать htmlspecialchars. Параметры тегов с динамическими значениями ограничивать двойными кавычками. Принудительно добавлять протокол (http), где это необходимо, для значений параметров тегов, таких как href или src».

Зачем используется кросс-скриптинг

Основная цель – кража cookies пользователей с помощью встроенного скрипта для выборки необходимых данных и использованием их для последующих атак и взломов. Атака осуществляется не напрямую на пользователя, а через уязвимости веб-ресурса, на который внедрен вредоносный JavaScript. Кстати, в браузере он виден, как органичная часть сайта.

Несмотря на то, что XSS-атака напрямую не несет угрозу серверу, если к злоумышленнику попадут cookies администратора, он сможет получить доступ к административной части сайта.

Уязвимость ищется, как правило, в формах связи на сайте. Чтобы понять, что она есть, достаточно передать в форму запрос вида:

<script>alert(«cookie: «+document.cookie)</script>

Стоит напомнить, что при базовой установке «1С-Битрикс» и готовых решений, вы не столкнетесь с подобной проблемой. Она может появиться лишь ввиду доработок и внедрения дополнительного функционала при условии, что код написан не по канонам «Битрикс» и без соблюдения правил безопасности.

Альтернативно ту же строчку скрипта можно добавить в качестве GET-параметра на страницах, генерирующие таковые. Например, в каталоге, на страницах пагинации или в фильтрах интернет-магазинов.

http(s)://{ваш_домен}/catalog?p=2 (вместо цифры 2).

Если на странице уязвимость есть, скрипт выполнится.

Важнейшим правилом для защиты сайта от таких уязвимостей является фильтрация получаемых и передаваемых данных по способу установки экранов для символов и преобразования специальных символов в HTML-сущности. Для php это осуществляется с применением функций htmlspecialchars(), htmlentities(), strip_tags(), например:

$name = strip_tags($_POST[‘name’]);

$name = htmlentities($_POST[‘name’], ENT_QUOTES, «UTF-8»);

$name = htmlspecialchars($_POST[‘name’], ENT_QUOTES).

При работе с «Битриксом» этот список можно еще дополнить методом CDatabase::ForSql. Пример:

$name = CDatabase::ForSql($_POST[‘name’]).

Важно явно указывать кодировку страниц сайта:

Header(«Content-Type: text/html; charset=utf-8»);

Альтернативно можно запретить передавать в формах кавычки и скобки, занеся их в черный список. Но при этом могут появиться проблемы, так как будут блокироваться реальные запросы, содержащие «запрещенные» символы.

В общем, несмотря на многочисленные публикации в вебе, мы не можем назвать эту уязвимость присущей именно CMS «Битрикс» и указываем ее лишь по причине распространенности.

Кроме XSS-атак, к уязвимостям сайтов не специфическим для «1С-Битрикс» относят:

• SQL-инъекции;
• внедрение в имя файла;
• выполнение системных команд;
• подбор реквизитов доступа;
• логические ошибки в коде;
• межсайтовая подделка запроса CSRF;
• фишинг;
• социальная инженерия.

Подробнее можно посмотреть в документации, мы же не будем на них останавливаться, а рассмотрим более специализированные для «Битрикс» прорехи в безопасности.

Перенаправления – click.php, rk.php и redirect.php

Уязвимость открытых перенаправлений на «1С-Битрикс» известна довольно давно. На форуме разработчиков она активно обсуждается с 2014 года.

А в 2015 году от нее пострадали банки в Казахстане.

Суть проблемы заключалась в следующем:

От хостинг-провайдера приходит сообщение о том, что существенно растет нагрузка на MySQL. 

Скриншот с форума разработчиков «Битрикс».

Причиной этому служило множество запросов (один пользователь отметил 30000 за 4 дня) с конструкцией вида:

/bitrix/rk.php?=goto=http…

При этом, после goto указывались, как правило, низкокачественные и мошеннические сайты.

Альтернативно проблема обнаруживается в системах аналитики, где видны внутренние и внешние ссылки именно по наличию таких URLов.

Это конструкция open redirect.

Open Redirect (открытое перенаправление) – это редирект, позволяющий использовать произвольный URL для конечной цели перенаправления.

Собственно, проблема открытого редиректа характерна не только для «1С-Битрикс». Конкретно же на «Битриксе» уязвимость связана с тремя системными файлами:

• click.php;
• rk.php;
• redirect.php.

Примеры ссылок:

{домен_жертва}/bitrix/click.php
?anything=here&goto={домен_цель}/

{домен_жертва}/bitrix/rk.php
?id=17&site_id=s1
&event1=banner&event2=click
&goto= {домен_цель}/

{домен_жертва}/bitrix/redirect.php
?event1=click_to_call
&event2=&event3=
&goto={домен_цель}/

Кому и зачем это нужно?

Первый вариант – получение трастовых ссылок. В 2014 году умельцы так поднимали индекс цитирования (ТИЦ) продвигаемых ресурсов.

В посте в открытом доступе почти 50 ссылок такой конструкции на трастовые домены, в том числе госорганов и банков. А в конце поста автор предлагает запросить у него бесплатно базу на 400+ доменов с выявленной уязвимостью. Кстати, оптимизатор не скрывает, что пользуется уязвимостью:

Даны подробные инструкции, как индексировать ссылки, рассылать их по твиттер-аккаунтам.

Но еще интереснее, что автор предлагает в разы увеличить запросы на сайты-жертвы:

Добавим к этому автопрогоны по разным аддурилкам и базам, вот и получаем ту злополучную нагрузку на базу, о которой писал хостер.

Думаете, что 2014 год был давно? Тогда вот более свежий пример из 2017 года:

И вишенкой на торте: даже при беглой проверке мы нашли ссылки, которые продолжают работать и доблестно редиректить на сайты злоумышленников.

В 2018-2019 году темы по этой проблеме на форуме «1С-Битрикс» только набирали оборотов и свидетельствовали о ее массовости.

Второй вариант – фишинг. В почтовой рассылке, в сообщениях соцсетей и мессенджерах в такие ссылки маскируются мошеннические страницы, собирающие пользовательские (персональные, платежные) данные.

Третий вариант – спам для понижения авторитета сайта. Наличие огромного количества ссылок на низкокачественные ресурсы – негативный сигнал для поисковой системы о качестве сайта-донора.

Как это возможно?

Все дело в системных файлах «1С-Битрикс», используемых CMS для сбора статистики кликов и перенаправлений по рекламным баннерам и ссылкам. Возможность использовать сайт в качестве прокладки для сомнительных редиректов заложена «из коробки».

Что делать?

Как ни печально, проблема сохраняет актуальность. Несколько тем на форуме разработчиков, к сожалению, пока не привели к ее системному решению со стороны создателей CMS.

На запросы пользователей поддержка предлагает установить максимальный уровень безопасности в Проактивной защите, настроить редиректы с проверкой HTTP-заголовков. 

Однако, как показывает практика, ни штатная «Защита редиректов от фишинга», ни многие другие средства не приносят необходимого результата. На повторное обращение техподдержка предложила удалить системные файлы.

Несмотря на абсурдность решения, оно, кстати, работает. Но при этом администратор ресурса теряет возможность отслеживать статистику кликов по баннерам и редиректов. 

Файлы click.php и rk.php использует модуль «Битрикса» Реклама, баннеры (advertising). Если вы этот модуль не используете – без колебаний удаляйте его, соответственно и файлы эти удалятся.

Альтернативное решение предложили пользователи форума разработчиков. В файл .htaccess добавляются строки:

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

Более специализированный вариант кода:

Однако и он не учитывает наличие файла click.php.

restore.php

Проблема была выявлена при тестировании проекта на проникновение. Ее подробно описали на Хабре. Мы же кратко изложим суть.

На публичном IP была установлена виртуальная машина «Битрикс», что стало понятно по набору открытых портов.

При переходе по адресу ip_addr:80 в браузере открывалась страница первичной настройки CMS «1С-Битрикс» со ссылкой «Восстановить копию». Клик по ней запускает переход к модулю restore.php и в окне появляется предложение загрузить резервную копию:

Ситуация объясняется скорее всего человеческим фактором: вероятно, что администратор не завершил процедуру настройки вебсайта и Виртуальной машины VMBitrix. Но несмотря на то, что проблема связана с отсутствием контроля или ошибкой специалиста, она может стать причиной взлома.

restore.php осуществляет проверку и загрузку файлов, разворачивание резервных копий проекта. А это значит, что злоумышленник может загрузить посредством модуля не бекап, а файл phpinfo.php. Проведенный анализ показал, что проверка файлов «Битрикс» не сработала и скрипт с локального компьютера загрузился в корень веб-приложения.

Чтобы повторить в лабораторных условиях, была локально развернута «1С-Битрикс: Виртуальная машина» версии 7.2.

Попытка загрузить скрипт через опцию «Скачать резервную копию с дальнего сайта» не увенчалась успехом. Сработала проверка. В restore.php есть код с соответствующим условием:

Однако, обойти первое условие оказалось возможным. Для тестов взяли скрипт cmd.php. В cli системы передали символы-идентификаторов с содержимым файла cmd.php в новый файл под именем cmd_boom.php:

echo -e «x1fx8bn$(cat cmd.php)» > cmd_boom.php

В hex-таблице он стал выглядеть так:

Файл был выгружен в репозиторий, и ссылка на него «скормлена» restore.php. Появился прогресс-бар загрузки и со временем – сообщение об ошибке:

Но!

Был ли удален файл?

Нет! Он остается в корне и запускается.

В форме с ошибкой нажали кнопку «Пропустить», затем – «Попробовать снова». В результате вывелась страница с кнопкой «Удалить локальную резервную копию и служебные скрипты». После клика на нее все файлы удалились.

Домашняя директория очищается от скриптов restore.php, bitrixsetup.php и файла cmd_boom.php. Сделать с сайтом ничего нельзя: резервная копия сайта не восстановлена, к установке нового не перейти.

В теории скрипт cmd.php можно скрыть в поддиректорию или же переименовать в index.php.

Обращение в техподдержку «Битрикс» не дало результатов. Точнее, ответ был таков, что поиск уязвимостей в restore.php не имеет смысла, так как скрипт предусмотрен для загрузки php-файлов на сайт.

С одной стороны понятно, нужно заканчивать установку и настройку. С другой – проблема не одиночна, а носит массовый характер. Быстрая поверхностная проверка выявила 600+ сайтов с опубликованными ВМ:

А если копнуть глубже? Надеемся, что этот факт заставит разработчиков задуматься над вопросом повышения безопасности на выявленном участке. А пока остается лишь быть предельно внимательным и не публиковать ВМ до того, как проект будет развернут на сервере, а также внимательно следить за всеми общедоступными страницами и ресурсами.

Бесконтрольная регистрация пользователей

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

«В течение последней недели наблюдаются массовые регистрации ботов на сайтах под управлением СУ Битрикс. Судя по записям в журнале событий регистрация происходит по адресу /auth/?register=yes Так вот, на этих сайтах раздел /auth/ либо отсутствует, либо там нет формы регистрации. Кто-нибудь сталкивался с подобной проблемой?»

Интересно, что с ситуацией сталкивались даже на сайтах, где регистрация вообще не предусмотрена, например, на лендингах и визитках. Появлялись пользователи и на проектах, где регистрация реализована через компонент main.register либо на самописном коде на API-Битрикс, где есть и reCaptcha, и правила валидации, и набор обязательных полей.

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

• system.auth.registration
• system.auth.authorize
• system.auth.forgotpasswd
• system.auth.changepasswd

На страницах они появляются со значением true константы NEED_AUTH:

define(«NEED_AUTH», true)

Но есть нюанс. Даже если константа не установлена компоненты благополучно отрабатывают, если подается «правильный» POST-запрос. Получается, что на любую страницу сайта, на котором даже не предусмотрена регистрация, можно подать запрос и получить успешно зарегистрированного пользователя.

Разработчик и автор блога CodeBlog Панов Алексей провел исследование, составив универсальный запрос для регистрации из Postman:

Как указывалось, запрос успешно сработал и на ресурсах без регистрации (лендинги), и на интернет-магазинах, «обойдя капчу в форме регистрации».

Очевидно, что при желании не составит труда автоматизировать процесс.

Хорошая новость в том, что способ защититься от атаки есть.

1. При использовании самописной регистрации нужно в настройках главного модуля на вкладке Авторизация убрать галочку напротив пункта «Позволять ли пользователям регистрироваться самостоятельно» и установить напротив «Использовать CAPTCHA при регистрации». Хотя бы на время наплыва ботов. Способ не работает, если предусмотрена регистрация по СМС.

2. Совершать необходимые проверки полей нового пользователя в обработчике события OnBeforeUserAdd. Так можно не дублировать валидацию в коде, где возможна регистрация.

3. Настроить указанные компоненты system.auth.* надлежащим образом.

В техподдержке «Битрикс» проблема известна, но они лишь «разводят руками», просто предлагая устанавливать капчу. Остается надеяться, что со временем уязвимость будет устранена. А пока рассчитываем только на собственные силы.

Где проверить сайт на уязвимости

Мы готовы провести аудит качества кода вашего сайта или интернет-магазина. При этом выявляются не только уязвимости, но и прорехи в производительности, вероятные ошибки в работе основных инструментов сайта, проблемы со скоростью загрузки.

И не забывайте: если ваш сайт по какой-то причине был выбран злоумышленниками в качестве цели, вполне возможен комплексный подход ко взлому. Делайте бекапы и следите за качеством кода и подрядчиков, с которыми вы сотрудничаете для его написания.

В качестве резюме (оптимистическое)

«1С-Битрикс» позволяет отбросить множество рисков. CMS на самом деле содержит реально работающие инструменты, которые помогу повысить уровень защиты вашего сайта от нежелательных атак. Поэтому мы рекомендуем создавать серьезные проекты именно на «Битрикс».

При этом по-настоящему важно:

• поддерживать актуальность CMS – вовремя обновлять до последней версии;

• обеспечивать высокое качество разработки или доработок вашего сайта исполнителями.

Ведь сама по себе пустая CMS практически не несет рисков. Проблемы могут начаться при неквалифицированном вмешательстве, когда происходит программирование страниц, функционала, шаблонов.

Тема о проблемах безопасности в вебе всегда будет актуальна. И чем популярнее CMS, тем больше вариантов разнообразных атак на нее. Но не стоит постоянно думать только об этом. Достаточно соблюдать несколько простых правил, чтобы не переживать о своем сайте:

• вовремя обновлять CMS;
• доверять работу с сайтом квалифицированным специалистам;
• держать актуальные резервные копии;
• при обнаружении проблем оперативно обратиться к разработчикам для обнаружения и ликвидации;
• систематически проверять безопасность ресурса (мы рекомендуем делать это раз в 2-3 месяца).

Ну, а где искать профи в Битрикс, Вы теперь точно знаете!

Множественные уязвимости в последних версиях CMS 1С-Битрикс. Видео атаки +58

Множественные 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>

Поле textarea, вариант проверки возможности эксплуатации XSS:

</textarea><script>alert(document.cookie)</script>

Уязвимое поле для типа данных «Список»

Поле input, вариант проверки возможности эксплуатации XSS:

"><script>alert(document.cookie)</script>

На действия администраторов сайта (входящих в группу «Администраторы [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 атаки, остались прежними.

Проблемы с XSS также никуда не делись.

Уязвимости устранены, выпущены обновления.
Детали обновлений в конце поста.

К примеру, эксплуатация вышеописанной угрозы возможна через уязвимые поля раздела: «Создать курс валют» > «Настройки курса» по адресу:
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">

Реализация самой атаки в реакции 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-Битрикс.

В этой статье мы коснемся самого распространенного способа хакинга сайта на 1С Битрикс. В нашей работе по поддержке веб-проектов на Битрикс мы видим не только последствия хакерских действий, но и успешно отражаем атаки на проекты клиентов.

Перейдем к технической части.

Как появляются проблемы безопасности?

Традиционно, сайты 1С Битрикс – это не те мебельные сайты по-умолчанию, которые запускаются после установки дистрибутива, а что-то более сложное. Веб-студии продают лицензии Битрикс, чтобы заработать на дополнительных доработках, дизайне, программировании и так далее. В погоне за длинным рублем клиента, о вопросах безопасности и не вспоминают. Когда веб-проект пилят по очереди фрилансеры-разработчики друг за другом, которых привлекает веб-студия, то качество кода, стабильность и безопасностью отходят на второй, третий, четвертый план. Главное – это кэш, а с поддержкой – «пусть хостер заморачивается». Такая постановка вопроса содержит в себе букет будущих проблем, расцветающий сразу после окончания гарантийных обязательств веб-студии или фрилансера. Зачастую попытки найти студию, запустившую сайт у клиента не получается совсем. Красивые слова, показ распечатанных дипломов и сертификатов 1С Битрикс начисто усыпляют бдительность клиента, а проблему он начинает видеть только в момент, когда сайт хакнули и хостинг компания заблокировала его по причине нарушения условия пользования хостингом.

Кодинг часто необходим для доработки функционала или написания своих модулей и скриптов для решения узкого круга задач клиента. Когда веб-студия экономит на разработчиках (кодерах), не говоря уже о тим-лидере, то получается, что получается. Плохого качества код имеет массу язвимостей, а общая монстрообразная структура продукта 1С Битрикс не способствует легкости решения задач безопасности.

Вернувшись назад, к моменту создания сайта или интернет-магазина, проакцентируем, что наиболее важными вопросами к разработчикам всегда являются моменты стабильности и безопасности. Для ответственных проектов в рамках тестирования проводится этап поиска уязвимостей, а также аудит безопасности.

Самая массовая проблема безопасности в Битриксе

Топ уязвимостей Битрикса возглавляет кросс-скриптинг, т.е. XSS-атаки, когда в коде веб-проекта есть скрипты, дающие возможность хакерам успешно использовать вызовы переменных и выполнять вредоносные операции. Это обусловлено отсутствием или недостаточно надежной фильтрацией параметров, передаваемыми скриптам. Обычно это связанно с авторизацией и регистрацией пользователей на сайте или в интернет магазине и операциями ввода-вывода с БД (MySQL).

Существует два типа XSS уязвимостей — пассивная и активная. Они различаются тем, что при пассивной в фишинговых письмах подставляют ссылку, чтобы потом жертва выполнила POST/GET запрос, а вот активная направлена на то, чтобы получить доступ к данным сайта.

При активной XSS атаке хакеру достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.

Что такое кросс-скриптинг и зачем он нужен?

Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.

Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.

Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).

Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:

<script>alert("cookie: "+document.cookie)</script>

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

Еще один возможный вариант уязвимости – использование адресов под страницы, которые обрабатывают любые GET-запросы. Например, у нас есть страница сайта с каталогом, задающая страницу параметром: http://www.onewebsite.ru/catalog?p=8

В адресной строке вместо параметра (в нашем случае это «8») добавляем скрипт:

<script>alert("cookie: "+document.cookie)</script>

в результате чего получаем ссылку уже такого вида:

http://www.onewebsite.ru/catalog?p= "><script>alert("cookie: "+document.cookie)</script>

Таким образом, если страница имеет уязвимость перед XSS атакой, то мы увидим, что наш скрипт выполняется.

Далее уже дело техники подобрать необходимый для выполнения код и выполнить его, особенно интересно становится при выполнении кода для записи или чтения в/из базы данных. Воспользовавшись XSS можно собрать из базы всех ваших пользователей, их приватную информацию, пароли. А администратор – это такой же пользователь, таким образом, следующие шаги, которые делают хакеры, весьма очевидны.

Зачастую к нам обращаются клиенты, которые не только потеряли всю пользовательскую информацию в своих интернет-магазинах на Битрикс, но и стали жертвами мошенников, использую одни и те же пары логин-пароль для авторизации в платежных системах.

Безопасность начинается с первой строки кода и не заканчивается никогда, в противном случае, халатное отношение грозит огромными финансовыми обременениями и потерей бизнеса.

Как найти потенциальную уязвимость в моем Битриксе?

Для поиска уязвимостей на сайтах существует сканеры. Ими можно периодически проверять ваш веб-проект. Это особенно актуально для проектов на Битрикс.

Чтобы выполнить быструю проверку сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск).

В качестве примера можете использовать xss-scanner.com, но не стоит ограничиваться лишь одним инструментом. Их есть значительное множество, некоторые имеют бесплатные и платные расширенные версии.

Важно отметить, что подобные сервисы не дают полной гарантии успеха, поэтому рекомендуем проверять найденные страницы в ручном режиме и обязательно исключить все опасные спецсимволы, заменив их безопасными. Речь идет о скобках < и >, в которых и прописываются все зарезервированные языком html-запросы и теги при обращении к скрипту. Именно этим и пользуются хакеры, поэтому ваша задача исключить их с помощью системы фильтров. Это все проверяется и исправляется в коде программистами.

Защита от уязвимости Битрикса

Наш технический отдел дает некоторые базовые рекомендации по предотвращению взломов 1С Битрикс с использованием XSS-атак:

1. Главное! Если на вашем сайте включена обработка данных из форм, то должно строго выполняться кодирование всех запросов.

2. Иногда кодирование применить проблематично. Что делать? Окей, заменяйте его валидацией ввода, а лучше даже дополняйте (дополнительно к кодированию).

3. Обрабатывать пользовательские данные в коде можно ТОЛЬКО на стороне клиента и никогда не на стороне сервера.

4. Регулярно обновляйте программное обеспечение Битрикс и всех установленных модулей и плагинов. После обновления проводите аудит на уязвимость XSS.

5. Внимательно относитесь к устанавливаемым плагинам и модулям Битрикс, особенно, скачанным со сторонних сайтов. Помните, что серые плагины из непроверенных источников могут содержать уязвимости преднамеренно зашитые в код, либо дыре, оставленной по невнимательности.