Данную статью, а точнее серию статей, меня побудил написать вопрос пользователя о Panic Button (на 2021 год - проект закрыт.) «Не противоречит ли закрытый код нормам безопасности, которые пропагандируются в вашем курсе?». Открытый и закрытый исходный коды воспринимаются пользователями как белое и черное, добро и зло, опасное и безопасное – и это заблуждение. Предлагаю разобраться, как обстоят дела на самом деле.
Любое приложение состоит из кода, который пишут программисты. Обычно код размещается на специальных сервисах вроде GitHub или GitLab: это может быть облачный сервис или решение, работающее в корпоративной среде компании. Любой код изначально открыт, просто в программах с так называемым закрытым исходным кодом он открыт для ограниченного круга лиц, обычно разработчиков, а в программах с открытым исходным кодом он открыт для неограниченного круга лиц.
Вот небольшой кусочек кода программы Panic Button.
Как видите, сам по себе код – это набор цифр, букв, символов, и он не может быть запущен в операционной системе. Набор кода надо при помощи компилятора превратить в исполняемый файл: в Windows – это exe, в Android – apk, в macOS – dmg. Этот процесс называется компиляцией.
Особенность открытого кода в том, что любой специалист может самостоятельно скомпилировать исполняемый файл на основе исходного кода и, естественно, посмотреть сам код. Если код закрыт, пользователям предоставляется только исполняемый файл.
Это не значит, что такой файл – это кот в мешке: можно проверить сетевые запросы, активность в системе, в конце концов, попробовать декомпилировать код, иными словами, из исполняемого файла восстановить исходный код. Мы об этом поговорим в отдельной части этой серии статей.
Пока все по-прежнему звучит так, будто открытый код – это очень хорошо, а закрытый – очень плохо. Давайте пока примем это на веру и разберем в разрезе каждой угрозы или проблемы, которую может нести приложение.
Какие угрозы может нести в себе приложение?
- ошибки,
- ситуативные баги (непредвиденные реакции),
- уязвимости,
- бэкдоры,
- скрытый функционал.
Ошибки
Итак, программисты пишут код – десятки тысяч строк кода, сотни тысяч строк кода – и выкладывают его, например, на GitHub в закрытый репозиторий, доступ к которому открыт только участвующим в проекте разработчикам. Весь выкладываемый одним программистом код обычно проходит проверку другим программистом, который должен установить, понятен ли написанный код, и, возможно, указать на ошибки, если такие будут обнаружены в процессе изучения.
Некоторые проекты используют дополнительные инструменты для поиска ошибок в коде, например PVS Studio. Подобные решения позволяют найти многие ошибки, но, конечно, не все. Ошибки случаются, и случаются у всех: и у частного разработчика-одиночки, и у международной корпорации вроде Microsoft.
К чему приводят ошибки? Например, программа не сработает должным образом. Если это антивирус, он не удалит обнаруженный троян или, наоборот, сработает слишком старательно и уничтожит вам системные файлы. Программа может просто доставать пользователя ошибками или постоянно «падать», вынуждая ее перезапускать.
Во времена моей учебы в ВУЗе популярный антивирус AVG после обновления перенес в карантин важный системный файл user32.dll, приняв его за троян. В итоге мой компьютер с курсовой работой просто перестал запускаться, и мне потребовалось немало усилий для поиска причины и реанимации Windows. Позже разработчик официально сообщил, что была допущена ошибка, которая и приводила к таким неприятным последствиям.
А чего стоит недавний пример с Microsoft, когда Windows 10 после обновления, призванного повысить стабильность системы, по ошибке удаляла пользовательские файлы. Удалялись файлы из папки «Мои документы»; именно там я когда-то и хранил свои курсовые...
Большинство ошибок можно «отловить» и исправить на этапе тестирования, однако некоторые ошибки воспроизводятся только при совершении нестандартных действий или в исключительных условиях, например при наличии какого-либо программного обеспечения или драйверов на устройстве пользователя,‒я называю их ситуативными багами.
Ситуативные баги
Обычно руководитель проекта или владелец продукта продумывает архитектуру, программисты пишут код, а так называемые тестировщики тестируют продукт. Для тестирования используются в том числе разворачиваемые виртуальные среды популярных операционных систем; команда, ответственная за тестирование, старается воспроизвести различные ситуации, проверить работоспособность всех функций. Часть тестов автоматизируется, а часть возможно воспроизвести исключительно вручную.
Только после полноценного теста и зеленого света от отдела тестирования приложение идет в релиз, иными словами, становится доступно пользователям.
Однако все варианты не воспроизвести: у пользователя могут быть уникальные настройки, особенности системы, свой набор софта, настройка firewall – все варианты даже представить себе невозможно, потому ошибки всегда будут.
Мы при разработке Panic Button (на 2021 год - проект закрыт.) тоже столкнулись с ситуативными багами, и они оттянули нам релиз программы на пару недель. Все шло хорошо, и мы уже готовились к релизу, тесты проходили на ура, в виртуальной среде и на рабочих компьютерах, за исключением некоторых мелочей, программа радовала глаз – и тогда я решил попробовать программу на стареньком домашнем ноутбуке, который тихо доживал свои дни в шкафу.
Я установил программу, проверил активацию паники комбинацией горячих клавиш, чистку данных, удаление файлов, отправку уведомлений – все работало, и тогда я поставил логическую бомбу с настройками по умолчанию. Но при перезагрузке ноутбука перегруженная установленными программами система запускалась так долго, что я просто не успел деактивировать логическую бомбу.
Почему это не было замечено в процессе тестирования? Виртуальные машины не нагружены лишним софтом, который запускается при загрузке системы, а рабочие компьютеры достаточно мощные и хорошо оптимизированные, чтобы быстро загружать операционную систему, но старенький ноутбук около двух минут загружал операционную систему и программы с автозапуском при старте.
Другой проблемой, с которой мы столкнулись, оказались устаревшие браузеры. Panic Button при активации должна удалить историю браузера, сохраненные вкладки и пароли, cookies, кэш и некоторую другую ценную информацию. На рынке представлено достаточно много браузеров, и мы работаем с самыми популярными: Mozilla, Chrome, Opera, Edge и Яндекс.Браузер.
В процессе тестирования и разработки мы ориентировались на актуальные версии браузеров, разумеется, и специалисты в области тестирования устанавливали последние версии браузеров. Но когда программа Panic Button была запущена на компьютере, где браузеры не обновлялись полгода, не все функции Panic Button отработали верно.
Это связано с изменениями в браузерах, произошедшими за это время. Например, в Chromium появились новые файлы в формате Sqlite3, в которых хранятся данные о сессии. При этом пара старых исчезла: их, видимо, разбили на более мелкие базы. В Firefox появился конфигурационный файл profile.ini в каталоге AppData/Roaming, и если его не удалять вместе с остальным профилем, браузер отказывался стартовать.
Как вы можете догадаться, открытость или закрытость кода слабо влияет на предотвращение багов, в том числе ситуативных. На их обнаружение влияет количество и уровень тестировщиков в команде и количество пользователей: если у приложения миллионы пользователей, вероятность проверки различных ситуаций и обнаружения проблемы выше, нежели у приложения с небольшой аудиторией.
В следующей части этой главы мы проговорим о бэкдорах и уязвимостях. Баги – это неприятно, но часто нестрашно, а вот бэкдоры и уязвимости могут нести реальную угрозу вашим устройствам и вашим данным.
