Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет информатики, математики и компьютерных наук

Программа подготовки бакалавров по направлению 09.03.04 Программная Инженерия

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Улучшение мобильного приложения

Васьков Алексей Александрович

Нижний Новгород, 2020



Аннотация

В данной работе будет рассмотрено улучшение мобильного приложения «Покупайка». Данное приложение предоставляет пользователям простой путь экономить деньги ежедневно при походах в магазин из-за того, что позволяет сравнивать цены на товары в различных магазинах и содержит большую базу данных из товаров и их стоимости из-за чего можно найти подходящий товар по выгодной цене. Приложение сделано в хорошем UI/UX дизайне и интуитивно понятно в использовании. Данное приложение можно скачать в Google Play для Android устройств и в AppStore для iOS. База данных приложения постоянно изменяется под влиянием пользователей так как каждый отсканированный товар или чек вносит корректировки в базу данных приложения. Данное приложение содержит некоторые ошибки и не содержит некоторый задуманный функционал.

Ключевые слова: улучшение, Android, интернет безопасность, исправление ошибок



Abstract

In this work, mobile application improvement for application “Pokupayka”. This application provides a simple way of saving money for users. Each person spends a lot of money in shops as there is no opportunity to compare the price of the product in different shops. This application contains a huge data base of products and their costs which wrapped for the perfect and intuitive UI and UX. As a result, was created an application for users who want to spend less money and can download our product from Google Play for Android devises and from Appstore for iOS devises. Ecosystem of this application regulates and develops app's community. Every time when a user checks the price of some product, our database extends and our tips of how to buy more profitable become more accurate. This Application has some bugs and hasn't some functions.

Key words: improvement, Android, web security, bugfix.



Введение

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

Сейчас разнообразие магазинов может запутать. Не всегда даже знаешь в каком магазине можно купить тот или иной товар. Сетевые супермаркеты, такие как «Лента» или «Ашан» могут продавать и резину для машины, и детское питание. В то же время есть магазины, которые специализируются отдельно на детском питании или отдельно на автомобилях. И не всегда верно утверждение, что специализированный магазин продает более качественный товар. Так же специализированный магазин может продавать ту же самую «Агушу» в полтора раза дороже, чем обычный продуктовый. И если не отслеживать цены и качество товаров в различных магазинах, можно тратить сильно больше денег, покупая товар более низкого качества.

Современный маркетинг научился манипулировать сознанием людей, заставляя покупать ненужный товар или вестись на скидку и покупать товар с учетом скидке дороже, чем в соседнем магазине.

Актуальность работы

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

Приложение «Покупайка» дает пользователю возможность сравнивать цены, видеть полезные ему товары, прочитать про товар перед его покупкой, посмотреть рейтинг магазина и обмениваться мнениями о товарах с другими пользователями.

Такое приложение уже есть, но оно не доработано:

1) Содержит ошибки, из-за которых приложение закрывается;

2) Не содержит некоторый задуманный разработчиками функционал;

3) Не до конца протестировано на безопасность и уязвимости.

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

Цели и задачи

Цель работы

Привести приложение к тому виду, в котором его можно будет показывать пользователям и не бояться потерять их из-за того, что приложением неудобно пользоваться. Обеспечить безопасность пользовательских данных.

Задачи

1) Исправить существующие ошибки

a. Найти причину ошибки

b. Устранить причину

c. Протестировать

d. Пройти ревью

2) Проверить приложение на наличие уязвимостей

a. Изучить виды возможных уязвимостей

b. Изучить способы диагностики уязвимостей

c. Провести аудит безопасности

d. Исправить уязвимые места

3) Добавить нереализованный функционал

a. Изучить архитектуру уже имеющихся модулей

b. Продумать реализацию своего модуля

c. Сделать свой модуль с аналогичной архитектурой

мобильный приложение программирование язык



1. Теоретическая часть

Я работаю с приложением на платформе Android, которое написано с использованием двух языков - Java и Kotlin.

Операционная система Android - ОС для смартфонов, планшетов, электронных книг, цифровых проигрывателей, наручных часов, фитнес-браслетов, игровых приставок, ноутбуков, нетбуков, смартбуков, очков Google Glass, телевизоров и других устройств. Использует ядро Linux и собственную реализацию Java Virtual Machine от Google. Сейчас поддержкой и развитием Android занимается Open Handset Alliance - бизнес-альянс 84 компаний по созданию и развитию стандартов мобильных устройств. В мае 2017 года Google объявила, что за всю историю платформы Android было активировано более 2 млрд Android-устройств, в мае 2019 Google рассказала, что во всем мире активно примерно 2,5 млрд android-устройств. Эта статистика учитывает пользователей Google Play, то есть не учитывает пользователей из Китая, где эта платформа недоступна.

Язык Java - строго типизированный объектно-ориентированный язык программирования, который разработала компания Sun Microsystems, которую позже выкупила компания Oracle, которой до сих пор принадлежат права на торговую марку Java. Приложения написанные на Java транслируются в специальный байт-код, поэтому они могут работать на любой компьютерной архитектуре, если для неё есть Java Virtual Machine. Для компиляции Java на Android используется Android Software Development Kit, разработанный компанией Google.

Язык Kotlin - статически типизированный язык программирования, работающий поверх Java Virtual Machine. Разработан компанией JetBrains. Авторы языка хотели создать язык более лаконичный и типобезопасный относительно Java, но более простой, чем Scala. В результате получился достаточно быстро компилируемый язык, который хорошо поддерживается в IDE - Integrated Development Environment. Язык полностью совместим с Java и встраивается в Android приложение через Gradle, что открывает возможность разработчикам не переписывать старый код с Java на Kotlin, но иметь возможность писать новые части на Kotlin. Язык разрабатывается с 2010 года, релиз Kotlin 1.0 состоялся в феврале 2016 года. В мае 2017 года Google сообщила, что Kotlin будет включен в стандарт Android Studio 3.0, а на Google I/O 2019 года Google объявил, что Kotlin является более приоритетным языком разработки под Android.

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

M1 -- Неправильное использование платформы

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

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

M2 -- Небезопасное хранение данных

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

M3 -- Небезопасное общение с сервером

Существует такой тип хакерских атак, как man-in-the-middle, когда весь интернет трафик проходит через злоумышленника. Если не использовать шифрование при передаче данных или использовать слишком слабые алгоритмы шифрования передаваемые данные сможет прочитать тот, кто перехватит трафик.

M4 -- Небезопасная аутентификация

Если хакер обнаружит уязвимую схему аутентификации, он подделывает или обходит её, отправляя запросы на обработку серверу приложения, не используя это приложения. То есть, получив список запросов, хакер может найти такие запросы, которые он сможет посылать через бота от лица анонимного пользователя.

M5 -- Плохие алгоритмы криптографии

В результате реверс инжиниринга можно понять какой алгоритм шифрования используется для хранения или передачи данных и использовать эти знания для расшифровки. Некоторые алгоритмы, например, MD5 крайне не рекомендуется использовать так как они очень легко взламываются.

M6 -- Небезопасная авторизация

Часто путается с M4 так как использует тот же принцип с поиском и отправкой запросов с той лишь разницей, что M6 посылается не от анонимного пользователя, а от реального, то есть используя токен или другие данные пользователя.

M7 -- Качество клиентского кода

Проблема реализации кода, связанная с различием реализации кода на клиенте и на сервере. Здесь можно встретить такие проблемы как переполнение буфера, format string уязвимости.

M8 -- Фальсификация кода

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

M9 -- Обратная разработка

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

M10 -- Лишняя функциональность

Часто во время разработки приложений разработчики добавляют дополнительные экраны, которые помогают получить доступ к серверу или изменению настроек приложения. Так же такие экраны могут содержать информацию, которую пользователь не должен знать, например, логин и пароль от аккаунта администратора. Данная уязвимость заключается в том, что иногда такие экраны забывают убрать в конечной версии и пользователь может получить доступ туда, куда разработчики не хотели бы его пускать.

Аналоги

Приложений с точно таким же функционалом нет. Есть приложения и сервисы, которые предоставляют часть функционала по отдельности.

Едадил

Проект Яндекса, в котором можно отслеживать скидки на товары в различных магазинах и торговых сетях. Является бесплатным приложением для платформ Android и iOS, а также представлен в виде интернет-сайта.

Приложения торговых сетей

В данной категории можно встретить такие приложения, как Пятерочка, Лента и так далее. Это приложения от одноименных торговых сетей, где представлено описание и наличие продукта, а также его стоимость и скидки. В таких приложениях так же можно посмотреть на карте расположение магазинов данной торговой сети.

Поисково-информационный картографические службы

Сюда относятся такие сервисы, как Яндекс.Карты или Google Maps, в которых можно на карте найти все возможные места, почитать о них отзывы или оставить свой, а также оценить место по пятибалльной шкале и загрузить фотографии места.

Отзовик.ру

Сервис в котором пользователи оставляют отзывы о различных товарах, а так же в комментариях к отзывам можно обсуждать конкретный отзыв, дополнять его и ставить ему оценку, был ли этот отзыв полезным или его нельзя считать достоверным.

Выбор инструментов

Так как приложение уже написано и мне предстоит работать с уже готовым приложением, языков для разработки используется два - Java используется как основной язык, но около трети всего кода написана на втором языке - Kotlin. Оба языка были описаны в теоретической части данной работы.

В качестве IDE для работы мной была выбрана Android Studio - официальная IDE от компании Google, которая предоставляет большой функционал для разработки и является самой удобной и известной IDE для разработки под Android лично для меня. А значит выбор данной IDE должен ускорить процесс анализа кода, дебага и написания новой функциональности.

Запуск, тестирование и отладка приложения будет проводиться с использованием реального девайса - моего Xiaomi Redmi Note 6 Pro с Android 8.1.0. А также в отдельных случаях понадобится использовать эмулятор Android, который можно установить вместе с Android Studio. Эмулятор позволит мне выбрать любую необходимую версию Android, размер экрана и предоставить возможность конфигурировать отдельные настройки системы.

В данном проекте разработчики используют Jira. Это коммерческая система отслеживания ошибок, разработанная компанией Atlassian, которая необходима в данном проекте для управления проектами. В Jira можно найти список задач, их статус (ready for dev, in progress. in review, done и другие), приоритет (low, middle, high, critical) и тип (bug, story, task и другие).

В качестве контроля версий используется Bitbucket от Atlassian. Bitbucket поддерживает Mercurial и Git. В данном проекте используется Git. Bitbucket очень удобно синхронизируется с Jira и в целом достаточно удобная платформа.

Wireshark будет необходим при поиске уязвимостей. Данная программа позволяет перехватывать интернет трафик и анализировать его. Программа написана на Си и C++ с использованием интерфейса Qt и имеет достаточно понятный UI, который упрощает работу.

2. Практическая часть

Работа над данным проектом делится на 3 логические части, каждая из которых будет рассмотрена отдельно.

Исправление ошибок

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

Первая такая ошибка была связанна с ошибкой Java: NumberFormatException. В одной из моделей кода есть функция, которая преобразовывает вводимый текст в число. Так как разработчики позаботились о том, чтобы пользователь мог вводить только числа - открывалась клавиатура, которая содержит только цифры, то от дальнейших проверок разработчики отказались. Но как оказалось, в поле ввода была доступна вставка раннее скопированного текста. Если раннее скопированный текст содержал буквы и иные знаки отличные от цифр - приложение при попытке преобразовать строку в число ловило критическую ошибку, которая никак не обрабатывалась и приложение падало. Данная проблема может решаться двумя путями.

Первый - запретить пользователю делать вставку. Но такой подход не совсем тривиальный так как для ввода используется обертка над стандартным полем ввода Android. При таком подходе необходимо переделывать логику UI компонента и это может занять приличное количество времени.

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

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

На этом работа с первой ошибкой была завершена. Вторая бага была связана с тем же экраном приложения, но ошибка была: StackOverflowError. Данный тип ошибки возникает в рекурсивных функциях, когда функция вызывает саму себя очень много раз подряд и JVM не может обработать цепочку вызовов и выдает ошибку и падает. После анализа кода компонента стало ясно, что рекурсивных функций нет. Просто обернуть в try-catch, как это было с прошлой багой, тоже не вариант так как данный тип ошибки может надолго вызвать зависание смартфона, так как данная ошибка связана с UI компонентом и задействует MainThread. Пользователь скорее закроет приложение, чем дождется отвисания. К тому же это не Exception, а Error - такие случаи не обрабатываются в try-catch. Значит нужно анализировать почему может возникнуть неявная рекурсия и устранять проблему. Все усложнилось тем, что кроме stack trace, который пришел от пользователя приложения при получении ошибки, у меня ничего не имеется. Проанализировав stack trace, я обнаружил, что есть около 20 функций, которые постоянно по порядку вызываются. Из этих 20 функций почти все системные кроме трех. Эти три функции как раз были в этом компоненте. Воспользовавшись отладчиком и подробно изучив логику компонента, я понял, что одна из функций вызывается при изменении текста UI-компонента. Другая же функция изменяет этот UI-компонент. Но первая функция вызывает вторую только при определенных условиях, которых должно быть достаточно для избегания рекурсии. И на моем физическом девайсе проверки, действительно, оказалось достаточно. Но мой stack trace не полностью совпадал с тем, что имелся в баг-репорте, из-за разных версий Android - в репорте был указан Android 9.0. Эмулятор с Android 9.0 совпадал по вызову системных функций, но тоже не воспроизводил ошибку ни при каких условиях. К тому моменту я уже понял, как можно вызвать рекурсию, но из-за специфики стандартных UI-компонентов я не смог это воспроизвести ни на эмуляторе, ни на своем девайсе. Однако из-за понимания, что существует множество различных Android смартфонов я добавил ещё одну проверку, которая обеспечивала уже невозможность вызова рекурсии и переполнения стека цепочки вызовов функций. Посовещавшись с другими разработчиками этого приложения, было решено оставить мое решение и объединить.

Следующая ошибка так же имела только stack trace по которому легко определилась проблемная строчка, открыв которую я увидел force unwrap - небезопасное преобразование optional переменной. Язык Kotlin поддерживает optional переменные, и, если при force unwrap в переменной будет лежать null - приложение упадет. Здесь именно такой случай. Решение максимально простое - можно безопасно извлечь значение и провести с ним операции в рамках одного блока, а если значение будет равно null - блок работы с этой переменной будет пропущен. Данный фикс необходимо проверить. Прежде всего необходимо понять, как можно воспроизвести данную ошибку. После анализа кода стало ясно, что разработчик подразумевал, что если интернет соединения не будет, то пользователь не сможет зайти на данный экран. Поэтому в дальнейшем он полагал что все ответы с сервера возможно будет преобразовать в нужную модель. Таким образом, если интернет соединение было в момент перехода на данный экран, а потом стало медленным или совсем пропало, произойдет ошибка, с которой я работаю. Однако я обнаружил, что, если интернета нет, то приложение падает в другом месте. Обсудив это с другими разработчиками было решено в рамках этой задачи починить только то место, о котором было известно ранее, а вторую ошибку исправить в рамках отдельной задачи. Я решил попробовать вариант с медленным интернет соединением. Для этого в настройках эмулятора я выставил самую медленную скорость интернета, перезапустил эмулятор и запустил приложение. Приложение видит наличие интернета и пускает меня на нужный экран, где я могу вызвать нужную функцию, пока приложение пытается обратиться на сервер и получить данные, из-за отсутствия которых приложение получает ошибку, которая возникнет, если интернет выключить. Все проходит успешно и приложение падает в нужном месте. Теперь повторяем все действия с моими изменениями и приложение больше не падает. Убедившись в том, что проблема исправлена, выкладываю её решение на проверку и исправляю ошибку, возникающую при отсутствии интернета тем же способом - безопасное извлечение значения из optional переменной.

Так же я заметил, что в приложении в некоторых местах слово «адрес» написано с двумя СС. Так же исправлю данную проблему в рамках текущей ошибки, так как под неё нет смысла заводить отдельную задачу из-за того, что она не влияет на поведение приложения.

Дальнейшая задача была связна не с ошибкой, а с отображением изображений. После некоторого анализа и нескольких вариантов как лучше сделать, стало понятно, что задача не очень тривиального и требует решения со стороны UI/UX. Поэтому время было затрачено, а результат работы не попал в релизный код. Подобные ситуации иногда встречаются в разработке ПО и это считается нормальным.

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

Аудит безопасности

На данном этапе мне не придется писать код, но работа ещё более объемная, чем в предыдущей части.

Пойдем по порядку и начнем с уязвимости M1. Сначала необходимо проанализировать доступные сервисы и разрешения для приложения и отдельных Activity. Для этого анализируется файл AndroidManifest.xml. Я проверил, что приложение не использует лишние permissions, правильно используются проверенные сервисы для работы с сетью, а также корректно настроен receiver и Activity реагируют только на необходимые и безопасные Intent'ы.

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

Анализ того, как хранятся данные и процесса логина показал, что приложение не хранит локально данные о пользователе. Таким образом можно утверждать, что приложение не содержит уязвимостей типа M2.

Для проверки дыр M3 я установил Wireshark и запустил приложение на эмуляторе. Wireshark собрал данные о том, какие пакеты данных мой компьютер получал и отправлял. Отфильтровав эти данные по ip эмулятора, я получил возможность просматривать все пакеты данных, которые прошли через эмулятор. На нем было запущенно только приложение, с которым я работаю, поэтому лишних пакетов данных или не должно быть, или их будет крайне мало. На картинке ниже можно увидеть, что все данные передаются через TLSv1.2. На данный момент существует TLSv1.3, но версия 1.2 в данном случае достаточна для обеспечения безопасности данных. Злоумышленник сможет получить параметры соединения и примерный объем передаваемых данных, но не сможет получить доступ к самим данным.

На изображении видно, что используется TCP. Это может насторожить, но TLS прежде чем отправить данные, связывается с сервером через TCP и обменивается данными о том, каким будет соединение, проверяет протоколы и так далее. Данный процесс является частью TLS и не несет никаких данных, которые будут интересны злоумышленнику. Таким образом я понимаю, что вся информация передается безопасно и уязвимостей M3 в приложении нет.

M4 и M6 можно объединить в один пункт так как они очень похожи и говорят про запросы на сервер. Проанализировав код сервера и прочитав дополнительную информацию про Spring, я понял, что местная система логина, завязанная на SecurityContextHolder, которая предоставляется Spring Security, исключают вероятные запросы злоумышленника из-под анонимного или реального пользователя.

Угроз со стороны M5 нет из-за того, что данные не хранятся локально, а с сервером общение происходит через хорошо зашифрованные протоколы. Таким образом выходит, что в данном проекте просто негде использовать плохие алгоритмы криптографии.

В силу того, что в данном проекте используется Java, а бекенд написанный на Java идеально сочетается с фронтом, написанным тоже на Java, таким образом получается избежать проблем со стороны M7.

Уязвимостей классификации M8 могут быть только от сторонних ресурсов и поэтому здесь их быть не может.

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

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

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

Добавление нового функционала

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

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

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

Я решил начать анализ кода не с визуально похожих частей, а с тех мест, где приложение передает серверу запросы на изменение данных о пользователе. Найдя экран, на котором пользователь может поменять своё имя, я проследовал по цепочке вызова функций до того места, где приложение отправляет серверу информацию на изменение данных. По ходу следования по этой цепочке стало понятно, что данные о пользователе обновляются не по отдельности, а одним запросом на сервер, который передает все новые данные. К тому же я узнал, что модули, которые общаются с сервером, используют архитектуру MVVM - Model View ViewModel, в которой основная логика лежит в ViewModel, которая содержит ссылку на репозиторий, который умеет общаться с сервером. И последнее важное, что я обнаружил ещё на первом этапе, сборка модуля происходит через Dependency Injection с использованием библиотеки, разработанной компанией Google - Dagger 2.

После того, как мне стал известен процесс обновления данных о пользователе, можно перейти от бизнес логике к презентационной логике и разобраться как устроены визуальные компоненты изнутри. В настройках есть очень похожий по смыслу экран, который изменяет иные настройки пользователя. Экран, который буду реализовывать я, внешне будет очень похожим на этот, поэтому имеет смысл изучить его. Данная часть приложения была написана на Kotlin и использовала описанную выше архитектуру MVVM.

В итоге новый модуль включил в себя 7 файлов:

· PrivacyItem - класс, используемый для хранения типа элемента, используемого на экране (SEPARATOR, CHECKED_PRIVACY, SAVE).

· CheckedSettingItem - расширение класса PrivacyItem, используемое для компонентов типа CHECKED_PRIVACY и добавляет объекту аттрибут, следящий за включением и выключением поля.

· PrivacyCheckedSettingItem - надтройка над CheckedSettingItem, используемая для создания компанента с предустановленным аттрибутом isChecked.

· SaveButtonSetting - расширение класса PrivacyItem, отвечающий за кнопку Save, которая умеет менять свое состояние - при изменении настроек кнопка доступна, до изменения - нет.

· PrivacySettingsViewModel - сборка модуля и логика по получению и отправке настроек пользователя происходит в данном классе.

· PrivacySettingsFragment - класс, который отвечает за визуальную составляющую и передающий данные в PrivacySettingsViewModel об изменении настроек пользователя.

· PrivacySettingsAdapter - вспомогательный класс, необходимый для возможности расширять список настроек и отображать их на экране. Данный компонент является адаптером у RecyclerView - UI компонента, используемого для отображения списка настроек.

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

Результаты работы

По итогу, опираясь на положительный отзыв команды, в котором говорится о том, что я своевременно выполнил все поставленные передо мной задачи, я считаю, что справился со своей работой достойно, выполнил весь запланированный объем работы, приобрел навык работы в небольшой команде, закрепил свои навыки участия в реальных проектах и в работе с платформой Android. А также провел достаточно большую исследовательскую работу на тему безопасности Android приложений.



Заключение

В рамках данной работы я принял участие в реальном проекте, которым пользуются люди ежедневно. Я провел работу по исправлению ошибок, допущенных до меня и пришел к выводу, что не всегда можно пропускать проверки из-за проверок, совершенных ранее. Особенно это касается тех случаев, когда между проверками может пройти некоторое время. Ещё один важный вывод, который нужно всегда держать в голове - если язык дает тебе какие-то возможности, их нужно использовать по полной и хорошо изучив, иначе будут возникать ситуации с force unwrap и подобные.

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

Несмотря на то, что приложение, как и любой другой продукт, по-прежнему содержит некоторые ошибки и не доведено до совершенства, однако я проделал с ним большую работу и поставленную цель, а именно: улучшение мобильного приложения, считаю достигнутой.



Список литературы

1. Venkat Subramaniam Programming Kotlin: Create Elegant, Expressive, and Performant JVM and Android Applications, 2019

2. Дэрси, Л. Разработка приложений для Android-устройств. Т. 1: Базовые принципы / Л. Дэрси, Ш. Кондер. - М.: Лори, 2014. - 402 c.

3. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Design Patterns, 2014

4. Nikolay Elenkov. Android Security Internals: An In-Depth Guide to Android's Security Architecture, 2014

5. Anmol Misra, Abhishek Dubey. Android Security: Attacks and Defenses, 2016

6. habr.com

7. stackoverflow.com

Размещено на Allbest.ru