У меня есть проект с открытым исходным кодом, который загружает файлы в DropBox среди нескольких файловых хостов. Прямо сейчас я делаю скриншот для DropBox. Чтобы использовать их API, я должен жестко закодировать СЕКРЕТНЫЙ КЛЮЧ, предоставленный мне для аутентификации OAuth. Но я боюсь, что ключ не будет секретным, если он будет виден всем.
Кто-то злоумышленник может использовать мой ключ для загрузки вируса в учетную запись пользователя (который уже разрешил доступ к моему приложению), который будет распространяться на его компьютер (если у него включена синхронизация на рабочем столе) и на компьютер других (если у них были общие папки) и так далее. : O
Я нашел этот вопрос без ответа, который имеет ту же проблему, что и мой.
Но я хотел бы знать, как в целом скрыть конфиденциальные данные в проекте с открытым исходным кодом.
У меня есть одна идея.
- Есть заполнитель в исходном коде, например "<SECRET KEY HERE>", и заполните его только при сборке двоичного кода для выпуска? (Тьфу!)
Любая приличная идея?
источник
Ответы:
Основная идея заключается в том, что вы НЕ регистрируете конфиденциальные значения в коде или в скомпилированном двоичном файле. Особенно, если проект с открытым исходным кодом, вы действительно не должны. Есть несколько стратегий конфигурации, которые вы можете использовать для этого:
Заполнители в коде (жестко закодированные значения)
Заполнители в коде - как было предложено - что наиболее разумно и проще всего сделать в динамических языках программирования, так как код легко изменить (без необходимости компиляции). Я видел много проектов с открытым исходным кодом, таких как MediaWiki с этим
LocalSettings.php.Недостаток этой стратегии является то , что ключ зашит. Таким образом, если программа распространяется в виде двоичного файла, то жестко закодированный ключ не делает ее особенно удобной для сопровождения.
Конфигурационные текстовые файлы
Вы также можете сделать это путем реализации текстовых файлов конфигурации , то есть программа / приложение ищет файл конфигурации и считывает значения из него. Вы можете зарегистрировать пример конфигурации с заполнителями, но фактическая конфигурация будет локальной на вашем компьютере.
В вашем случае вы можете создать
key.confтекстовый файл с фактическим ключом, позволить программе использовать этот файл и позволить ему игнорировать управление версиями. Для удобства вы можете проверитьkey.conf.exampleтекстовый файл с помощью фиктивной клавиши и проверить это. Убедитесь, что ваша программа / приложение делает полезное сообщение об ошибке для пользователя, чтобы добавить фактический ключ в правильный файл.Некоторые языки программирования имеют API, которые предоставляют это автоматически, например:
App.Configфайлами, доступными через ConfigurationManager .NET APIpackage.jsonили помещают значения конфигурации в json-файлы, а с помощью API файловых модулей файлы легко анализировать и использовать, поскольку они в основном являются объектными литералами JavaScript .Если ваше приложение является приложением базы данных, рассмотрите возможность помещения ключа или других переменных конфигурации в базу данных. Он такой же, как текстовый файл конфигурации выше, но вместо этого вы помещаете все переменные конфигурации, такие как ключ, в таблицу базы данных.
Через просмотр настроек или приложение бэк-офиса
Если программа является окном или веб-приложением с представлениями, вы также можете разрешить приложению создавать файл конфигурации с помощью вида предпочтений. Таким образом, вам не нужно проверять пример файла конфигурации, как предложено выше.
MediaWiki решает эту проблему аналогичным образом, автоматически генерируя
LocalSettings.phpфайл в процессе первоначальной установки.По общему признанию, это не вариант для программ, которые работают исключительно как фоновые процессы, сервисы или демоны. Однако именно поэтому вы создаете отдельные проекты с графическим интерфейсом для них, чтобы создать точку входа для настроек администрирования и настроек, в веб-приложениях, обычно называемых приложением Back Office .
источник
Самый простой способ - просто не публиковать конфиденциальные данные. Некоторые варианты:
Я использовал второй вариант для разработки с открытым исходным кодом, потому что это означает, что вам не нужно беспокоиться о заполнении деталей непосредственно перед сборкой или о том, что нужно помнить одно изменение, чтобы не фиксировать.
источник
Если у кого-то есть исходный код (или байт-код, который может быть подвергнут обратному проектированию), он сможет получить секретный ключ, запустив код в отладчике и установив точку останова в точке отправки ключа.
Вы можете сделать это немного сложнее, предоставив предварительно скомпилированную C-библиотеку, которая говорит с выпадающим списком, с ключом, закодированным в этом, но есть еще много способов утечки ключей (например, я думаю о строках).
Единственный безопасный способ, который я могу придумать, - это предоставить веб-сервис, который отправляет сообщения в раскрывающийся список. Таким образом, секретный ключ остается на вашем сервере под вашим контролем. Расходы на хостинг и пропускную способность означают, что это решение далеко не идеально для бесплатного приложения, но дополнительным преимуществом является то, что ваш сервер может правильно аутентифицировать клиентов перед передачей их файлов, отправляемых в Dropbox.
источник