Мобильная разработка и безопасность
25) Чем отличается нативная мобильная разработка от кроссплатформенной? Назовите плюсы и минусы каждого подхода.
Нативная мобильная разработка — приложение создается отдельно под каждую платформу.
Примеры:
Android → Kotlin / Java
IOS → Swift / Objective-C
Особенности: приложение максимально учитывает особенности платформы, используются “родные” компоненты интерфейса, высокая производительность, требуется отдельная разработка под Android и IOS.
Плюсы:
Высокая скорость работы
Лучший доступ к возможностям устройства
привычный интерфейс для пользователей Android и IOS
удобно для сложных и больших коммерческих приложений
Минусы:
Нужно писать два приложения
Выше стоимость разработки
Больше времени на поддержку
Кроссплатформенная мобильная разработка — приложение создается на одной технологии, а затем запускается на нескольких платформах.
Примеры:
Kivy
Flutter
React Native
Особенности: один код может работать на обеих мобильных ОС, быстрее делать MVP и учебные проекты, проще поддерживать одну кодовую базу, иногда сложнее добиться полного соответствия каждой платформе
Плюсы:
Один код для нескольких платформ
Быстрее разработка
Проще сопровождать проект
Удобно для обучения, прототипов и MVP
Минусы:
Иногда ниже гибкость
Возможны ограничения при работе со специфическими функциями платформы
Иногда внешний вид и поведение нужно дополнительно адаптировать
26) Что такое Kivy и для каких задач его целесообразно использовать? Какие ограничения есть у Kivy при создании мобильных приложений?
Фреймворк — набор готовых инструментов, правил и компонентов, которые помогают быстрее создавать программы.
Kivy — открытый Python-фреймворк для создания графических интерфейсов и multitouch-приложений. Он подходит для мобильных, настольных и интерактивных приложений. В Kivy есть виджеты, события, макеты расположения элементов на экране, multitouch (поддержка касаний, жестов и интерактивных интерфейсов).
Ограничения:
Kivy удобен для старта, прототипов и учебных проектов, но не всегда подходит для сложных коммерческих приложений.
Не всегда нативный внешний интерфейс — интерфейс Kivy рисуется своими средствами, поэтому приложение может выглядеть не совсем как обычное Android / IOS-приложение.
Сложнее сборка под мобильные платформы — для Android обычно используют Buildozer/python-for-android, а для IOS нужен отдельный процесс с Xcode-проектом. Это может быть сложнее, чем запуск обычного Python-файла.
Ограничения при работе с функциями устройства — камера, Bluetooth, фоновые сервисы, push-уведомления и другие системные возможности могут потребовать дополнительных библиотек или нативного кода.
Меньше “стандартности” для индустрии — в коммерческой мобильной разработке чаще используют Kotlin / Swift, Flutter или React Native, поэтому готовых примеров и вакансий по Kivy меньше.
Не лучший выбор для больших приложений — если приложение требует сложной интеграции с системой, идеальной производительности и строгого соответствия платформе, лучше рассмотреть нативную разработку.
27) Назовите основные свойства информационной безопасности: конфиденциальность, целостность, доступность, аутентификация и авторизация.
Информационная безопасность - защита информации и информационных систем от несанкционированного доступа, изменения, уничтожения или раскрытия.
Основные свойства:
Конфиденциальность - данные доступны только авторизованным пользователям
Целостность - данные не изменяются без разрешения
Доступность - система работает стабильно и доступна пользователям
Аутентификация - проверка личности пользователя
Авторизация - проверка прав доступа
Валидация входных данных - проверка данных, поступающих от пользователя
Безопасная разработка - написание кода с учетом возможных атак
Пример: небезопасный код
Такой код уязвим к SQL Injection - атакующий может передать строку или изменить SQL-запрос.
Безопасный вариант:
Здесь используются параметризованные запросы, которые отделяют данные пользователя от SQL-команды.
28) Какие ошибки в коде и проектировании чаще всего приводят к уязвимостям приложения? Приведите примеры и объясните их возможные последствия.
Уязвимость - слабое место в программном обеспечении, архитектуре, настройках сервера или процессе разработки, которое может быть использовано для нарушения безопасности системы
Большинство инцидентов безопасности происходит не из за “гениального хакера”, а из за обычных ошибок в проектировании, коде, настройках и работе с данными. Типичные ошибки:
Доверие к пользовательскому вводу
Разработчик предполагает, что пользователя введет корректные данные: имя, email, номер телефона, файл или комментарий. На практике любые входные данные считаются недоверенными. Примеры рисков:
SQL Injection
XSS - атаки
загрузка вредоносных файлов
обход бизнес-логики
Неправильная работа с авторизацией
Частая ошибка - пользователя вошел в систему, но может получить доступ к чужим данным. Пример:
IDOR - Insecure Direct Object Reference - пользователь меняет user_id в URL и видит профиль другого человека
Хранение секретов в коде
Разработчики иногда оставляют в проекте пароли, API-ключи, токены доступа, ключи от баз данных и другую приватную информацию. Особенно опасно если такой код попадет в GitHub или общий репозиторий.
Отсутствие валидации и санитизации данных
Валидация проверяет, соответствует ли ввод ожидаемому формату. Санитизация очищает данные от потенциально опасного содержимого.
Пример:
поле возраста принимает отрицательное число
email не проверяется на корректность
HTML-теги сохраняются в комментарии
файл загружается без проверки расширения и MIME-типа
Небезопасная обработка ошибок
Подробные сообщения об ошибках полезны разработчику, но опасны для пользователя. Плохо когда приложение показывает:
путь к файлам на сервере
SQL-запрос
версию фреймворка
stack trace
внутренние имена таблиц и переменных
Такая информация помогает атакующему понять устройство системы
Использование устаревших зависимостей
Современные приложения используют библиотеки, фреймворки и пакеты. Если зависимости не обновляются, в проекте могут оставаться известные уязвимости:
dependency vulnerability
CVE
vulnerable package
supply chain attack