Как избежать случайного распространения конфиденциальной информации в моем MSI?

Как избежать случайного распространения конфиденциальной информации в моем WiX / MSI?

  • Я случайно раздал пароль, имя компьютера или учетные данные для входа в свой файл MSI. Как мне лучше всего справиться с этой проблемой?
  • После развертывания мое приложение ошибочно подключается к моим системам QA / UAT, а не к производственным системам - из-за неисправной конструкции отладки в коде пользовательских настроек моей установки. Как я могу обнаружить и избежать этого?
  • Как мне избежать распространения такой информации в целом?

Это вопрос в стиле Q/A с самым простым подходом, чтобы избежать случайного распространения конфиденциальной информации через ваш MSI

Источник

1 ответ

Решение

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

В дополнение к приведенной ниже информации о конфиденциальной информации, помните также, что некоторые файлы, которые вы хотите включить в свои настройки, могут не распространяться легально. Типичными примерами могут служить средства отладки от Microsoft или средства отладки из стороннего инструментария SDK. Пожалуйста, внимательно прочитайте документацию и избегайте использования таких "хакерских инструментов" в ваших пользовательских действиях.

Укороченная версия

ОБНОВЛЕНИЕ: позвольте мне записать, прежде чем я забуду, что вы должны удалить " флаг блокировки загруженных файлов " из всех установочных файлов (и, как правило, флаги только для чтения).

Все, что предлагается ниже, по сути: 1) сканировать ваш окончательный MSI с помощью Orca, 2) просматривать установленные файлы настроек, а также любые сценарии установки шаблонов, поставляемые с вашим MSI. Далее, 3) очень хорошо просмотрите ваши скомпилированные источники пользовательских действий и, возможно, улучшите конфигурацию сборки релиза (#ifdef _DEBUG например, см. ниже). 4) проверьте пользовательские действия вашего скрипта, проверив, что на самом деле находится в вашем MSI (извлеките их). И самое главное: 5) получить помощь от других людей для всего ручного тестирования - получить несколько сообщников:-). Серьезно: настройка так же важна, как и приложение - чтобы ваше решение было успешным, ваша задача - привлечь QA-персонал и других людей, участвующих в тестировании, а также рассказать им, что и как тестировать.

Я бы не пытался автоматизировать такую ​​проверку самостоятельно. На данных нет замены настоящих глазных яблок. Возможно, решение сообщества поможет в долгосрочной перспективе. Это может стать частью пакета проверки? Полуавтоматическая помощь может работать, но полностью автоматическая: забудь об этом. Существует слишком много способов использовать всю имеющуюся у вас веревку, чтобы выстрелить себе в ногу.

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

QA - Bug Quest

Проверка на конфиденциальные данные, включенные случайно, очевидно, связана с общим QA вашего пакета. Это должно быть сделано одновременно с общим тестированием. Специалисты по тестированию настолько заняты тестированием приложений, что вам действительно нужно провести тестирование развертывания и составить план тестирования. Ничего особенного, но все-таки протестирую все режимы установки (install, reinstall, repair, self-repair, upgrade, patching, uninstall, administrative install и вы должны также сделать publishing а также advertisement - если у вас есть настройки, чтобы проверить это) и проверить все функции настраиваемых действий (тщательно). Реально и минимально вы должны протестировать установку, переустановку, удаление и обновление, но, пожалуйста, протестируйте все режимы.

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

И я думаю, мне следует упомянуть слова опытного разработчика: " ... не бейте слишком много людей тестированием, пока каждая найденная ошибка не станет настоящим сюрпризом ". А также - его забавный совет - для предварительных выпусков оставьте в паре известных ошибок и скажите ребятам из QA, что есть такое-то количество ошибок, чтобы найти - просто для мотивации, чтобы сосредоточить внимание:-). PS: мне нравится называть этого опытного разработчика " The Elder Grasshopper ", или как он более широко известен как " Veggie Boy ". Конфуций говорит: " Никогда не доверяй человеку, которого можно подкупить (органической) морковью! "

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

Проверка файлов MSI

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

  1. Сначала быстрый повторный просмотр исходных файлов (WiX, Installshield, Advanced Installer или любого другого инструмента, который вы используете) для жестко закодированных грехов dev-box.
  2. Затем значительное внимание уделяется проверке готового релиза-кандидата MSI -файла. Настоящий Маккой. Все таблицы, а также извлечение некоторого встроенного контента для проверки (скрипты, библиотеки пользовательских действий и т. Д.).
  3. Фактические установки во всех режимах установки, как описано выше. Может быть обнаружен конфиденциальный контент, но может появиться и множество других проблем - например, появление неожиданных окон сообщений - иногда с конфиденциальной информацией об отладке (фокус теста настраиваемых действий).

Как проверить? Некоторые скриптовые проверки могут быть полезны, но из опыта мне это не нравится. Я предпочитаю вторую пару глаз, а не честную проверку сценариев, если я честен. Просто мои два цента от реальной работы релиза.

  1. Установить Orca
    • Orca настолько же проста, как и MSI - другие инструменты часто показывают фиктивные, проприетарные таблицы. Orca - это прямой просмотр содержимого файла.
    • Найдите "Orca" здесь, чтобы быстро найти установщик, если у вас установлена ​​Visual Studio, или скажите, чтобы кто-то с установленной Visual Studio отправил вам установщик MSI.
    • Вы также можете попробовать " Super Orca " - но Orca рекомендуется.
  2. Теперь просто откройте свой MSI -кандидат на релиз с Orca и просмотрите таблицы.
    • И просто сказать очевидное:
      • Примените любые изменения в реальном источнике, не исправляйте готовый MSI.
      • Если вы спросите меня, никаких исправлений на месте вообще - вам нужно исправление в источнике и полное восстановление файла MSI, по моему мнению. Затем вы маркируете свой исходный код (если вы получили должный, старомодный контроль версий с восхитительными ревизиями и ярлыками).
    • Наиболее уязвимыми таблицами, вероятно, являются: Registry, Property, IniFile - но может быть что-то в нескольких других местах.
    • Если вы действительно используете графический интерфейс MSI: tables relating to GUI также уязвимы.
      • Многие люди просто используют стандартный графический интерфейс без изменений. Это должно устранить большинство рисков.
      • Если у вас есть пользовательский графический интерфейс, то в объявлении графического интерфейса MSI достаточно много таблиц. Я бы посмотрел на них всех.
      • Возможно особое внимание уделяется: ListBox, ComboBox, UIText, Dialog
      • Очевидно, с дополнительным акцентом на ваши собственные, настраиваемые диалоги - если таковые имеются.
    • Сторонние инструменты содержат уязвимые пользовательские таблицы для таких вещей, как обновления файлов XML. Глазное яблоко это тоже.
      • Все, что выглядит как XMLFile, SQLUpdates и т. Д...
      • Таких пользовательских таблиц разных производителей становится все больше. Теперь они относятся ко всем видам вещей, а не только к файлам конфигурации (правила брандмауэра, сценарии SQL и т. Д.)
    • Проверьте все включенные скрипты.
      • Проверьте в системе контроля версий, но также...
      • CustomAction стол или Binary таблица - последняя, ​​требующая от вас потоковой передачи любых сценариев или проверки их в исходных местоположениях).
  3. Проверьте любые файлы настроек, которые устанавливает приложение (через таблицу файлов MSI).
    • Файлы INI с жестко заданными настройками могут быть установлены через таблицу файлов, поэтому их значения не отображаются в Orca (в отличие от таблицы INIFile, которая показывает все поля INI для записи).
      • Разница здесь заключается, по сути, в том, обрабатывается ли файл как файл или как набор пар групп-значений, например, для записи в INI. Последний подход является "правильным".
      • Обратите внимание, что некоторые файлы INI, возможно, потребуется установить в виде файлов, если они имеют нестандартное форматирование (дополнительные поля и различная странность в отличие от обычного форматирования пары ключ-значение), или даже более распространенное: файлы INI могут иметь огромные разделы комментариев с помощью информацию (часто для инструментов разработчика), которую вы хотите сохранить - а вы не можете через таблицу файлов INI. Затем можно установить его в виде файла.
    • Другие файлы настроек, такие как файлы XML, могут быть установлены таким же образом. Очень часто на самом деле.
      • Как указано выше, сторонние инструменты часто поддерживают запись обновлений из настраиваемой таблицы, доступной для просмотра в Orca.
      • Таких разных таблиц может быть много (Зашифрованные поля? Что там?)
    • Файлы, включенные в этот список, обычно поддерживаются разработчиками, но все еще является обязанностью релиза проверять. Выполните административную установку (дополнительные ссылки в связанном ответе) вашего MSI и проверьте извлеченные файлы настроек в созданном сетевом образе. msiexec.exe /a "Your.msi", или же setup.exe /a (Installshield), или setup.exe /extract (Расширенный установщик). Некоторая информация по setup.exe.
  4. Проверьте поддержку сценариев пакетной установки, сценариев Powershell или других сценариев, поставляемых вместе с настройкой, с намерением выполнить фактическую установку программного обеспечения.
    • Иногда вы видите готовые сценарии, поставляемые с некоторыми настройками, чтобы помочь автоматизировать развертывание, часто сюда может проникнуть некоторая форма жестко закодированной информации (пути UNC, даже IP-адреса или другие виды тестовых данных ").
    • Эти сценарии, иногда поставляемые в виде отдельной загрузки, могут быть запоздалой мыслью, которая, по моему опыту, игнорируется для обеспечения качества.
    • Активно используйте эти сценарии во время тестирования и тестирования, если таковые имеются, или еще лучше: вместо этого документируйте крупномасштабное развертывание в одностраничном PDF-файле (гораздо более общий и менее подверженный ошибкам).
  5. Предупреждение: скомпилированные пользовательские действия могут содержать конфиденциальные данные, даже если в Orca ничего не видно - очевидно. Легко забыть иногда в самый разгар. Это очень важно (новое любимое слово) - вернемся к исходному коду.
    • Скомпилированные пользовательские действия не являются "видимыми" напрямую, поэтому любые жестко запрограммированные чувствительные элементы "менее подвержены".
    • Однако ошибочный жестко заданный IP-адрес может привести к тому, что все ваши пользователи попытаются подключиться к вашему тестовому серверу или к любому другому серверу, который вы захотите для себя... Я подозреваю, что это произойдет не во время установки, а во время первого запуска приложения.
    • Опять же: получите помощь - вторая пара глаз избавит вас от неприятностей, но на этот раз пусть они также прочтут реальный исходный код. Скажите им сосредоточиться на неожиданных, жестко закодированных значениях и странных определениях - на чем-то, что выглядит "экспериментальным".
      • Такая " белая коробка " или "прозрачный" QA, вероятно, здесь хорошо. Привлечь другого разработчика? Я бы сфокусировался на простом коде для "странных вещей", а не на тестировании реальной функциональности (то есть для тестирования черного ящика).
      • Очевидно, что код должен работать с MSI PUBLIC PROPERTIES только для значений, введенных пользователем или установленных в командной строке. Все, что закодировано жестко, на самом деле не должно быть там. Однако в реальности большинство разработчиков устанавливают что-то жестко запрограммированное в отладочных сборках.
      • Специалистам по контролю качества следует рассказать, как проверить одно и то же " черное окно " с настраиваемым действием, а также первый запуск приложения, чтобы проверить, что правильные значения записаны, куда бы они ни направлялись.
      • Можете ли вы предоставить несколько удобных журналов на уровне приложений для тех QA-ребят, которые, как они знают, существуют и знают, как их использовать (и что от них ожидают проверки?). Затем вам нужно всего несколько минут, прежде чем они обнаружат, что ваше приложение выпуска попадает на ваш внутренний тестовый сервер, а не на рабочий сервер.
    • Для скомпилированных C++ пользовательских действий я бы предложил использовать хорошую практику отладки придирки, если вы настаиваете на жестком программировании. использование #ifdef _DEBUG обернуть debugging message boxes и любой hard coded test variables, Смотрите фрагмент C++ ниже. Это означает, что в выпусках сборок вообще нет экспериментальных значений (препроцессор удалит все отладочные конструкции).
    • Возможно также добавить NOMB к вашему выпуску сборки тоже? См. Также пример ниже - должны быть предотвращены блоки сообщения о сборке посторонних выпусков - определение по существу "запрещает" их (другие, возможные определения: Как приручить заголовки Windows (полезные определения)?).
      • Я только кратко проверил это. У меня была довольно большая доля забытых окон сообщений C++, появляющихся в сборке релиза, хотя - я должен признать - никаких бедствий к счастью (стук по дереву и так далее, и тому подобное...).
      • Имейте в виду, что такое окно сообщения может загадочным образом остановить установку, запущенную удаленно в беззвучном режиме, без каких-либо предупреждений или без явной причины (обычно без сообщения журнала).
      • Такое сообщение обычно может быть вызвано неким условием ошибки или исключением, которое обычно не вызывается для большинства установок, поэтому оно внезапно появляется на некоторых ПК. Вы ничего не можете сделать, чтобы восстановить при удаленном развертывании. Настройка не откатывается правильно, она просто застряла. Если пользователь не вошел в систему локально, его также нельзя удалить на компьютере. Не строго о конфиденциальной информации напрямую, но связанной (точно, что отображается на коробке?), И что-то, чтобы посмотреть при тестировании пользовательских действий.
      • Естественный вопрос заключается в том, существует ли способ автоматически блокировать тайм-ауты для окон сообщений? Я кратко проверил курение этого предложенного метода MessageBoxTimeout (из user32.dll) и, похоже, даже поддерживает вышесказанное NOMB особенность, а также время ожидания. Другими словами, вы можете установить окно сообщения как запрещенное в сборках выпуска, так и время ожидания в сборках отладки. Тщательно не проверено.
    • C++ - не моя вещь, используйте лучшие практики для сборок релизов, как определено вашей компанией. Может быть, искать определения и строковые переменные. Или все настройки могут быть в файле настроек, включенном только в отладочные сборки (но, в любом случае, такие странные вещи могут заползти туда-сюда).
    • В отношении управляемого кода я задаю себе вопрос: насколько декомпилируемым является этот управляемый двоичный файл? У меня мало опыта здесь. Я никогда не тратил время на декомпиляцию управляемых двоичных файлов.
      • В любом случае в коде не должно быть ничего чувствительного - если только у вас нет скрытого закрытого ключа, лицензионного ключа или чего-то такого же странного, что я бы точно не сделал, оставьте это на усмотрение приложения.
      • Для таких функций, как настройка пробного периода для вашего приложения, я полагаю, вы могли бы лучше "скрыть реализацию". Возможно, что-то вроде запутывания, что я не в курсе. Может быть, это одна из самых больших проблем в мире.NET? Эксперты по теме: просим нас просветить.
      • Я бы сосредоточился на тех же проблемах, что и выше: отладочные конструкции, которые ошибочно включены в двоичные файлы режима выпуска, и ошибочные ссылки и пути, заданные для тестирования серверов и тестирования ресурсов.
  6. Включение отладочных сборок в ваш официальный релиз случайно
    • Еще одна проблема, которая в некоторых случаях может легко возникнуть: вы включаете в MSI отладочные версии своих DLL(библиотек) с настраиваемыми действиями.
    • Очевидно, что это может произойти с любым файлом в вашей настройке, не только с вашей DLL-библиотекой пользовательских действий, но DLL-библиотекой пользовательских действий особенно "скрыто" в вашем пакете после сборки (встроенный в двоичную таблицу MSI - проверьте это).
    • Возможно, не забудьте добавить d к имени файла для вашего скомпилированного пользовательского действия dll - или любого другого файла в этом отношении? Даже если это вызывает у вас дополнительную работу?
    • Я не уверен, насколько "чувствителен" отладочный dll на самом деле (должный специалист по C++ должен уточнить), но я уверен, что не хочу непреднамеренно распространять такие файлы в моих установках. Я иногда (редко) делаю MSI -файлы для отладочной сборки для команд QA, содержащие только отладочные двоичные файлы и символы для целей тестирования, и, по моему мнению, эти настройки должны истечь через месяц или два и никогда не будут просты в установке и никогда не будут использоваться вне вашей команды QA, Можно добавить пароли для установки, но MSI является открытым форматом и все еще может быть извлечен. Нет драмы, просто что-то, что нужно иметь в виду и управлять, я думаю.
  7. Теперь это немного подталкивает к теме "конфиденциальных данных", но как насчет тщательного сканирования вредоносного ПО всего, что вы намереваетесь подписать цифровым способом и опубликовать публично? Подписанное вредоносное ПО - это не то, что вы хотите испытать.
    • Проверьте вашу цифровую подпись в файле релиза (если есть). Тест с UAC и т.д...
    • Возможно, используйте http://www.virustotal.com/ или эквивалентную услугу / решение для сканирования вредоносных программ для сканирования вашего окончательного файла MSI на наличие вредоносных программ (или ложных срабатываний).
    • Используйте procxp64.exe (прямая загрузка Sysinternals Process Explorer) для сканирования всех запущенных процессов после тестовой установки. Смотрите некоторые предлагаемые шаги использования для инструмента здесь.
    • Использование этих инструментов может помочь вам устранить ложные срабатывания и для вашего решения. Ужасная проблема, которая, похоже, усугубляется, когда программное обеспечение безопасности усиливает безопасность, а вредоносные программы становятся все более распространенными.
      • Ложные срабатывания могут привести к бесконечному самовосстановлению (см. Проблему 7 в этой ссылке) для вашего развернутого пакета, поскольку файлы повторно помещаются в карантин, а затем возвращаются установщиком Windows посредством самовосстановления.
      • Ложная положительная ирония: для настоящих вредоносных программ вы говорите своим пользователям о восстановлении своих компьютеров. В случае ложного срабатывания вы должны решить проблему с поставщиками программного обеспечения для обеспечения безопасности. Теперь, как это сделать для десятков инструментов безопасности и пакетов?

Отладка только сообщения в пользовательском действии C++:

Я использую окна сообщений, чтобы присоединить отладчик к коду настраиваемого действия C++. Как избежать появления этих тварей в сборке релиза? Вот одно предложение:

#ifdef _DEBUG //Display Debug information only for debug builds
     MessageBox(NULL, "Text", "Caption", MB_OK|MB_SYSTEMMODAL);
#endif

Продвинутые ребята из C++ сразу увидят, что они должны сделать для этого лучший макрос - оборачивая все это - я не специалист по C++, поэтому я пока оставлю это в стороне (SafeMessageBox? DeploymentMessageBox?).

В stdafx.h, может быть, дополнительно включить NOMB (должен предотвратить MessageBox от компиляции, если не обернуто #ifdef _DEBUG - делая MessageBoxes доступно только в отладочных версиях):

#ifndef _DEBUG // Forbid MessageBox in Release builds
    #define NOMB
#endif

(Справедливая ставка, это может стать одним из ваших самых ненавистных определений за всю историю:-). Кто пахнет закомментированным разделом? Я бы не использовал #undef добавить специальное окно сообщения о выпуске - оно разрушает всю функцию защиты - вероятно, вызывая именно то, чего вы надеетесь избежать: случайное окно сообщения. Возможно, просто закомментируйте #define в stdafx.h если вам нужно, и включите определение снова - автоматически через процесс сборки - для реальной, публичной сборки выпуска, вызывающей ошибку компиляции для любых случайных окон сообщений)

И, как упоминалось выше, вы можете попробовать новый метод MessageBoxTimeout (из user32.dll По-видимому, доступно начиная с XP), чтобы показывать окна сообщений, которые не "застревают", но имеют тайм-аут после определенного количества секунд

Некоторый контекст: #ifdef DEBUG против #if DEBUG. Люди, которые на самом деле знают C++ должным образом, могут свободно разъяснять или уточнять по мере необходимости. Выше приведен очень старый проект C++.

Это в основном это - едва ли ракетостроение - просто "мелочи, которые кусаются". Некоторое дальнейшее обсуждение по теме ниже, но ничто не заменит это сканирование вручную ИМХО. Мое честное предложение, возьмите некоторых людей (менеджеры просто в порядке:-) - потяните их как сообщников!), установите Orca для них и просто попросите их щелкнуть по таблицам и просмотреть все файлы настроек - и попросить разработчика помочь с скомпилированным кодом настраиваемого действия. Простое рассмотрение необработанных таблиц Orca может быть даже эффективным для выявления других ошибок или недостатков.

Конфиденциальная информация

Существует множество возможностей для включения конфиденциальной информации в ваши источники MSI случайно во время разработки: login credentials, passwords, database connection strings, user names, share name, IP-address, machine names, ftp passwords, web host login credentials или же other sensitive data,

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

Если это действительно необходимо для установки, такой "конфиденциальной" информацией должны быть параметры (свойства), которые устанавливаются конечным пользователем во время установки, либо через интерактивный графический интерфейс установки, либо устанавливаются через ОБЩЕСТВЕННЫЕ СВОЙСТВА, либо преобразуются в командной строке, когда установка устанавливается Здесь есть некоторая информация об использовании преобразований и ОБЩЕСТВЕННЫХ СВОЙСТВАХ: Как лучше использовать файлы MSI для тихого корпоративного развертывания файлов MSI (связанный ответ также дает довольно специальное описание проблем и преимуществ MSI в более общем смысле).

Источник
Другие вопросы по тегам