Правила обмена (конвертации) используются в обменах данными повсеместно. Однако за удобство и простоту согласования разных конфигураций приходится платить потенциальной угрозой безопасности: возможностью выполнить в принимающей базе произвольный код на языке 1С.
Есть такая брешь :)
Пока мы её на себе не ощутили, но чувствую, что можем - есть умелые ребята в магазинах :)
Пока что единственное, что придумал, - подписывать закрытым ключом ту часть правил, которая сохраняется в файл выгрузки, и при получении пакета сравнивать подпись.
и для взлома достаточно будет доступа к фтп, а реквизиты доступа, как правило лежат в справочнике Настройки обмена данными. При этом обмен настроен под одним фтп пользователем с настройкой выгрузки в разные каталоги (у кого-то не так? :-) ) Сливаем базу одного филиала, и получаем доступ ко всем :)
(5) давно такое в инете проскакивало (ссылок не дам, т.к. не записывал). Есть такое и в курсе по конвертации от Гилева и Насипова. Как вы думаете почему в новых конфигах (на управляемых формах) правила и обработчики событий в правилах хранятся внутри конфига? это все идет развитие безопасности обменов. Тема хоть и не новая, но напоминание лишним не будет, это как лишний раз сделать бэкап - не помешает.
(6) в догонку. не весь код при обменах выполняется в привилегированном режиме. Если допилить логику при записи объектов, то можно отлавливать и обмены.
Если НЕ ЭтоГруппа И НЕ ОбменДанными.Загрузка Тогда...
в новых конфигах (на управляемых формах) правила и обработчики событий в правилах хранятся внутри конфига
В новых - это в каких? В бухии 3.0.38 всё ровно так как в статье написано - правила в регистре, обработчики в правилах. В конфу ничего не прошито жестко.
(9) Сильно подозреваю, что это для модели сервиса, т.к. сегодня перед тем как опубликовать глянул в последний релиз бухии на предмет не поменялось ли чего - код чтения правил из файла был в наличии, про обработчики не смотрел, правда. Завтра постараюсь подробнее глянуть на предмет того что это и для чего.
(9) Однако, я ошибся - не для работы в модели сервиса. Вот что написано в самом модуле одной из этих обработок:
////////////////////////////////////////////////////////////////////////////////
//
// Данный модуль содержит экспортные процедуры обработчиков событий конвертации
// и предназначен для отладки правил обмена.
// После отладки рекомендуется внести соответствующие исправления обработчиков
// в базе «Конвертация данных 2.0» и заново сформировать файл правил.
//
////////////////////////////////////////////////////////////////////////////////
(3) Yashazz создавал топик несколько лет назад, где спрашивал как выполнить код на клиенте. я предложил вариант с выгрузкой.(нашел вроде http://forum.infostart.ru/forum26/topic38078/message431224/#message431224 ) а потом спустя некоторое время он даже публикацию вроде делал. хотя могу тут ошибаться.
а тупо паковать файлы обмена с паролем - не вариант?
Один из. Но это всё же относится к защите транспортного канала. Т.е. при наличии до глубины души обиженного размером премии продавца и его друга-кулхацкера, всё необходимое, чтобы устроить в центральной базе локальный армагеддец, может формироваться в самой 1С-ке и отдаваться на вход шифрующего скрипта уже с бомбой внутри.
(16) ну как бы тут уже необходимо наличие "кулхацкера", который сведущ в структуре базы предприятия. А это уже инсайдинг, от которого техническими средствами защититься крайне проблемно. Ежели так, то у того же кулхацкера есть и значительно проще пути по сливу информации..
Совсем необязательно. Структура базы, как правило, в достаточной степени описывается правилами выгрузки в эту базу, остальное выясняется несколькими последовательными атаками. По-сути, это инсайд, да. Но не на центр инфраструктуры, а "скраю", так сказать. Там много сценариев возможно, на самом деле.
(20) AlX0id,
Для этого не обязателен прямо кулъ-хацкер :)
У нас среди продавцов в магазинах вдруг оказались бывшие одинэсники :):) Потому все откровенно явные дыры пришлось быстренько заткнуть после первых же случаев.
(23) baton_pk, ИМХО, если товарисч, побывав одинэсником, предпочитает зарабатывать продавцом в магазине, то вреда от него, как программиста, на много порядков больше, чем от него же, как вредителя. Тут как в том анекдоте про фашиста и партизана: "Вас ист дас? "Гомельспичпром"? Тафай-тафай, потшигай."
(12) DrAku1a, сама команда была и в 7.7, только в коде универсальной XML загрузки её никто не писал, а все нужные процедуры дописывали в код обработки. Это было безопаснее, но лень победила, не плодить же обработки под каждые правила обмена:)
Может и была, честно - не помню. Однако, функция "Вычислить" есть и в 8.х, и решает она несколько другие задачи. Выполнить последовательно несколько операторов, разделенных ";" в ней не получится. Так что, думаю, в 7.7 всё же код выносился в обработку не для безопасности, а в силу ограничений платформы.
(14)Ага, смежная проблема с теми же корнями. Кстати, та тема 2013 года ещё, и уже там в комментах пишут, что баян. Дыра известна и понятна. Только воз не особо двигается, как говорится.
(18) воз не особо двигается, потому что эта возможность хоть и реальна, но всё равно из разряда шансов получить по голове метеоритом. Люди, которые способны это провернуть и "обиженные размером премии продавцы" это очень-очень разные люди, так что даже в том маловероятном случае, что кто-то попытается, кончится это скорее всего сообщением, типа: "Какая-то фигня при загрузке файла обмена".
(27) В УТ 11.1 проверяли? Правила обмена в них берутся из регистра, а не из файла, об этом есть упоминание в статье. А в остальном - да, такой вариант тоже может иметь место. Суть в общем-то статьи в том, что при построении защиты недостаточно прорабатывается обмен данными с незащищенными узлами: защищается центральный сервер, защищаются каналы связи, но не сами передаваемые данные. И с переходом на БСП ситуация не особо улучшилась. Согласитесь, ваша статья всё же несколько о другом. Хотя корни проблемы общие, согласен.
+ продавец не обязательно должен быть одинесником.
суть проста- обиженный продавец хочет продать базу конкурентам. а то и просто навредить.
продавец работает на точке.
что он делает - копирует вечерний файл выгрузки на флешку. ищет программиста, который делает из файла бомбу - либо как в сабже отправляются данные базы на мейл, либо очищаются какие-то важные данные, либо создается прямой доступ к базе. в файле можно даже прописать создание пользователя с полными правами, пакетный запуск базы под этим пользователем в конфигураторе с выгрузкой(предварительно установив блокировку соединий и ждем в цикле пока все не выйдут) и отправкой файла выгрузки куда-нить на файлообменник или на почту.
+ пакостных вариантов - куча.
самый мерзкий - бомба замедленного действия. небольшие изменения, что на протяжении пары недель будут незаметны, а когда спохватятся - окажется, что все бекапы "заражены" этими изменениями, а достоверные данные - только на бумаге.
например, в закупках/продажах рандомно изменять цены на пару копеек, подменять емейлы и номера телефонов контрагентов и пр. пр
Этой дыркой еще в 2009 году пользовался
<ПослеЗагрузкиПравилОбмена>
...
УстановитьПривилегированныйРежим(Истина);
ДвоичныеДанные = BASE64Значение("....");
ДвоичныеДанные.Записать("Троян.exe");
ВыполнитьКомандуСистемы("Троян.exe");
... и понеслась...
(31) Ну, под линуксом такой беспредел не проканает, конечно. А так, да. Как пользоваться дырой понятно; как её закрыть, в общем-то тоже. Непонятно, по крайней мере мне, почему на эту проблему поголовно забивается болт.
Не хочется расстраивать автора, но если говорить о типовом обмене на базе БСП 2.2 последних версий, то он сделан таким образом, что правила конвертации объектов источника в приемнике берутся не из файла обмена (хоть они там и есть), а из правил, зашитых в конфигурации. Можно включить режим обмена, когда, когда будут выполняться обработчики из правил, но речь не об этом сейчас. Все о чем вы написали справедливо для случаев использования настроенных правил (БСП2.2), либо обменов по более старым технологиям, либо самописных обменов. В типовых конфигурациях этой проблемы быть не должно. Теоретически... Хотя, если у организации появляется свой программист 1с, то ничего типового для такой организации больше не остается.
(34) Если когда-нибудь это будет так - я не расстроюсь, а только порадуюсь :) Может быть, в последних версиях БСП что-то и поменялось, но что-то верится мне с трудом. По крайней мере, для актуальной на данный момент версии бухгалтерии проблема всё ещё в наличии.
(35) Чтобы обсуждение не повисло в неопределенности, добавлю информацию.
В последних БСП эта проблема решилась тем, что в центральной базе хранятся правила обмена в обе стороны. И когда из периферии приходят данные, то обработчики берутся из центральной базы.
Обнаружилось это опытным путем при отладке обмена. Изменения в правилах выгрузки игнорировались принимающей базой до тех пор, пока не поменял их на стороне приемника.
А я пока в поисках как в старой УТ 10.3 подменить файл обмена перед началом его загрузки.
Научился подменять файл выгрузки правкой правил обмена. А с загрузкой пока ищу способ.
(36)Конкретно в последних версиях БСП не смотрел, но по состоянию на апрель 2015 ситуация была следующая: правила обмена в обе стороны хранятся в регистре ПравилаДляОбменаДанными, однако, если прибить записи этого регистра, то правила берутся из файла. Убить эти записи можно, например, приняв файл обмена определенного вида.
Как сейчас дела обстоят дела в этом вопросе не знаю, не мониторил. Но сильно сомневаюсь, что что-либо изменилось.
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0")