Как искать баги в приложениях
Вы почти у цели. Финиш так близко, что вы уже предвкушаете бокал шампанского за победу и успешно завершенный проект. Но. но что-то не работает. В приложении есть баг, и вся команда разработчиков не может понять, где он завелся и как смог перевернуть всё с ног на голову. Работа застопорилась прямо у финишной прямой, которая недавно была так близко, а теперь вдруг оказалась за тысячу километров.
Тестирование мобильных приложений — дело нелёгкое. Всякий раз, когда я разговариваю с разработчиком, всегда оказывается, что тестирование — это одновременно волнующий и мучительный этап разработки. Волнующий потому, что продукт наконец-то близок к долгожданному состоянию полной готовности, а мучительный. ну, если вы хоть раз пробовали откапывать неизвестные ошибки в софте, вы меня понимаете. Чтобы провести тестирование правильно, необходим многоуровневый подход, который требует временных затрат, ресурсов и терпения. Есть несколько способов тестирования приложений, но не каждый из них подходит любому разработчику.
Многоуровневое тестирование
Мы попросили Ли Уильямсона, ведущего программиста IBM и члена CTO Team, рассказать нам о различных подходах, которые используют разработчики при тестировании приложений. Далеко не всегда тестирование приложения сводится к вылавливанию ошибок в исходном коде. Мобильные приложения — это зачастую узконаправленные программные системы с большим количеством взаимодействий между фронтендом, логикой и облачным бекендом. Таким образом, ваш код может безупречно работать на устройстве, но его работа будет подорвана ошибками, которые поступают из облака. Или проблема может быть в логике приложения — сторонних библиотеках, SDK, или сервисах. Так что иногда, если что-то не работает, найти ошибку легко, но чаще всего у вас даже идеи нет, в чем проблема.
Есть множество способов автоматизировать тестирование. Тестирование вручную, пожалуй, самое эффективное, хотя и требует наибольших усилий. Запустите код на устройстве и работайте с приложением как реальный пользователь.Когда что-то пойдет неправильно, пишите лог и на его основе откапывайте ошибку в коде.
«Есть ручное тестирование мобильных приложений. И несмотря на то,что это самый неэффективный и дорогостоящий способ, мы по-прежнему считаем, что в хорошо сбалансированной стратегии для него есть место. Потому мы пока не нашли способ, который может автоматизировать оценку юзабилити и привлекательности для мобильного приложения для конечного пользователя. Это те вещи, которые в конечном итоге должен оценивать реальный человек,» — говорит Уильямсон.
В идеале тестирование вручную является одним из завершающих этапов жизненного цикла разработки приложения. Все сделано и почти готово к поступлению в продажу. Этот этап может быть менее болезненным, если, например, воспользоваться услугами стартапов, таких как Crashlytics (Бостон) — они предоставят вам SDK, который с точностью до строчки в коде определит, почему приложение падает, и предоставит данные о его состоянии на момент сбоя.
Действительно ли облако мешает работе вашей системы?
Как только разработчики переходят на облака в качестве бекенда, появляется новый уровень, требующий проверки. По мнению сотрудников IBM, такая проверка — их сильная сторона в области тестирования. Они могут изолировать или симулировать уровень логики и облачный бекенд, чтобы ещё до фактической интеграции между устройствами, серверами и облаком дать разработчикам представление о том, как будет работать приложение. Это осуществляется при помощи Green Hat — тестовой платформы IBM для различных облачных сервисов. Мобильные облачные сервисы, работающие по схеме бекенд-как-сервис, например Kinvey, дают разработчикам экземпляр структуры своего облака (которое работает через Rackspace, Azure или Amazon). Он позволяет конкретному компьютеру выполнять функции мобильного устройства.
«Это позволяет компании использовать непрерывную интеграцию при разработке мобильных приложений, которая постоянно отслеживает изменения кода, запуская таким образом автоматическую сборку бинарных файлов для приложений для различных мобильных устройств. Также это позволяет переносить обновленную версию приложения на реальные мобильные устройства и запускать код на устройствах с симулированными сервисами и облачным бекендом, потому что на мобильном устройстве он всегда будет реагировать так же,» — прокомментировал Уильямсон.
Другой вид облака
Недавно один разработчик жаловался мне на тестирование приложений, и его сетования заключались вот в чем: «Есть слишком много мобильных устройств, на которых установлено до черта версий операционных систем, установленных на различных смартфонах от различных производителей. Протестировать всё это просто невозможно». Это была суть его жалоб. Только слова, которые он использовал были . поострее.
А ведь он прав. На мировом рынке продается более 300 различных типов смартфонов на базе Android. Количество телефонов на базе Windows также растет, не говоря о разработчиках, которым нужно, чтобы приложения или сайты запускались на BREW, Symbian и Bada девайсах. Даже тестирование приложений для iPhone усложнилось из-за наличия на рынке трёх версий устройства (3GS, 4, 4S), которые использует большинство покупателей. При этом существуют также различные версии iOS (не все знают как их обновлять, а некоторых это просто не заботит), работающие на различных носителях. iOS не фрагментирована, как Android, но всё-таки есть ещё фрагменты, которые должны быть протестированы в самой системе.
Чтобы протестировать работу приложений на различных устройствах, разработчик может приобрести все эти смартфоны и планшеты, связать с сервером и зависать над спецификацией каждого устройства. Это непрактично, трудоемко и дорого. Есть несколько сторонних сервисов, которые могут предоставить разработчикам «облако устройств» для тестирования приложений одновременно на многих устройствах. IBM использует Perfecto Mobile и Device Anywhere для своих облаков девайсов, но есть также другие решения от таких компаний, как Apkudo.
«Это тоже часть нашей стратегии — принятие во внимание того, что существует много различных методов мобильного тестирования, и что некоторые из этих методов применимы для мобильных приложений, но по каким-то другим причинам клиент может посчитать тот или иной метод неприемлемым,» — говорит Уильямсон.
Выбор . а он вообще есть?
IBM работает на рынке уже очень давно — более 100 лет, на самом деле. Это одна из первых компаний в области компьютерной техники, которая начинала с разработки аппаратного обеспечения, а позже перешла к корпоративному программному обеспечению. IBM знает себе цену. В этой компании тщательно анализируют проблемы, с которыми сталкиваются разработчики, и создают всесторонние комплексные решения, чтобы их решить. И выставляют вам счет, иногда на кругленькую сумму.
В работе с IBM есть ощутимые преимущества. Например, не так много других компаний предлагают услуги по системному тестированию. Если у компании нет готового решения, она может либо приобрести его у другой компании (GreenHat), либо работать совместно с компанией, которая им обладает (Device Anywhere). Сам же Уильямсон согласен с тем, что системное тестирование может быть проведено и без прибегания к услугам IBM, но это может не оправдать затраченных усилий.
«Конечно, есть и другие пути разработки качественного комплексного решения по тестированию, но в таком случае клиент сам должен будет заниматься интеграцией, то есть, по сути, быть самому себе системным интегратором, в то время как в IBM мы делаем это на профессиональном уровне,» — говорит Уильямсон.
Отлавливание багов и тестирование – задача разработчиков. Как найти надежных?
Можно воспользоваться данными рейтинга мобильных разработчиков. Он представляет собой перечень самых успешных и опытных компаний, специализирующихся на создании мобильных приложений.
Вы можете не только узнать, кто лучше всего делает приложения на конкретной платформе (например, iOS или Windows Phone), но и буквально в 2 клика провести тендер между понравившимися компаниями.
Менеджер по развитию бизнеса в Touch Instinct
Автоматизация тестирования приложений, в смысле не unit-тестов, а тестирования приложения целиком, сейчас вполне возможна (UIAutomation, Robotium), но в подавляющем большинстве случаев не рентабельна. Для автоматизации вам потребуются тестировщики гораздо более высокой квалификации и больше времени, фактически автоматизация это написание еще одной программы. Это оправданно для длительных проектов с большим количеством итераций и небольшими интерфейсными изменениями. Думаю, такие проекты есть только у Яндекса или другой большой компании. Мы все тестируем вручную, при этом проверяется не только наличие ошибок, но и отзывчивость и удобство приложения.
Облака устройств Perfecto Mobile и Device Anywhere, на мой взгляд так же не помогут вам в тестировании. Когда я их тестировал полгода назад, работа со смартфонами ужасно тормозила и не передавала реальных ощущений работы с приложением, с которыми столкнутся ваши пользователи. В таких условиях тестировщики не смогут нормально работать. Так что закупка всевозможных устройств — верный путь, которому следуют все известные мне российские разработчики приложений.
Руководитель департамента мобильных решений в AREALIDEA
Как точно подмечено автором, тестирование мобильных приложений действительно может быть не простой задачей из-за большого разнообразия устройств и версий ОС.
Пример с Android устройствами очень верный: немалое число официальных версий операционной системы, плюс большое число разных устройств от разных производителей, которые легко могут «доработать ОС под себя», а так же разнообразие железа в устройствах, вот и получается ужас для тестировщика. Проверить приложение на всех устройствах просто невозможно.
Описанное в статье решение от IBM по тестированию в «облаке девайсов» является, на самом деле, очень заманчивым. Если оно действительно позволяет покрыть большой объём устройств и различных ОС для тестирования — это может спасти проект от множества проблем и сделать его более качественным. Однако за удовольствие надо платить, и цена за такое тестирование может быть высока. Если да, то данный сервис, имеет смысл использовать только крупным компаниям, которые готовят к выпуску какой-либо серьёзный продукт, и хотят проверить его как можно детальнее.
В действительности, использование описанных ниже методов, может быть вполне достаточно для выпуска качественного продукта:
- Покрытие Unit-тестами исходного кода приложения для отлавливания потенциальных багов в работе приложения.
- Создание автоматизированных тестов для проверки UI приложения с моделированием различных возможных сценариев поведения пользователя (для сайтов — это Selenium, для Android ОС — специальная библиотека Robotium).
- Ручное тестирование на виртуальной машине, которая обычно идёт вместе с соответствующей SDK, и позволяет проверить приложение на разных версиях ОС и на разных разрешениях экрана.
- Ручное тестирование на реальных устройствах.
Хотя, конечно, это и не даёт возможность заранее проверить приложение на разных устройствах, как облачный сервис от IBM.
Для небольших компаний, стартапов или компаний-аутсорсеров облачные сервисы — незаменимый инструмент, это правда. Но не стоит забывать о том, что подобные решения не являются панацеей, и компаниям, чей профиль — именно разработка мобильных приложений, более выгодно будет всё-таки завести свой парк девайсов, так как существуют важные кейсы, которые не воспроизвести с помощью устройства из облака.
Все-все-все девайсы, которые существуют на рынке, не нужны — достаточно топовых и популярных моделей с наиболее распространенными разрешениями экрана, графическими чипами и официальными прошивками. Новые модели планшетов и смартфонов выходят часто, но многие устройства держатся в топе по нескольку лет, поэтому постоянно что-то докупать не придется — обновлять парк имеет смысл при выходе чего-то принципиально нового — нового чипсета, нового разрешения экрана у флагмана. Для хорошего парка достаточно правильно подобранных девайсов.
Стоит помнить о том, что пытаться протестировать всё и везде — экономически нецелесообразно. Сколько бы тестовых окружений мы не создали, всегда найдется какой-нибудь особо хитрый кейс у пары десятков юзеров. Что можно с этим сделать? Только правильно расставлять приоритеты при разработке и тестировании, чтобы до релиза было найдено как можно больше багов на тех окружениях, которые чаще всего встречаются у реальных пользователей.
Генеральный директор в CleverPumpkin
Количество сервисов, так или иначе связанных с мобильными приложениями, стремительно увеличивается. Часть из них, безусловно, посвящена теме тестирования, а именно упрощения этого процесса в контексте мобильных приложений. Помимо сервисов, описанных в статье, есть и другие интересные проекты, так или иначе связанные с тестированием. Например, TestFlight, HockeyApp, Fixber. Все они призваны помочь разработчикам выпустить качественный продукт, что, на мой взгляд, является крайне позитивным моментом.
После прочтения заголовка и первогоабзаца в голове установилась ассоциация с главными страницами сайтов жёлтой прессы, что- то в духе «мальчик сделал такое, никто не ожидал!». Где в конце фразы обязательно ставиться восклицательный знак
О чём начало текста? О том, что в приложениях, даже мобильных есть, будут и были баги. Конечно же, все кто связан с разработкой программного обеспечения клюнули на такой заголовок и первые строчки. А потом.
Внимание вопрос, выше скопированный монолог уважаемого Дэна к чему должен сподвигнуть читателя?
Иногда возникает необходимость узнать, какие баги были найдены в каком-нибудь топовом приложении для Android. Причин для этого может быть масса: от попыток раскрутить вектор дальше и поиска схожих уязвимостей до банальных проверок на хардкод. Попробуем провернуть, а поможет нам в этом связка HackApp + Vulners.
С помощью Vulners и HackApp можно искать по уязвимостям более чем 22 025 топовых Android-приложений из Google Play! Store. Для поиска нужно указать тип type:hackapp . В результатах поиска отображается тайтл, количество уязвимостей по степени критичности (красный кружок — критичные, желтый кружок — средняя критичность, серый кружок — примечание), информация о приложении (иконка, текущая версия, разработчик и дата релиза).
Поиск уязвимостей по базе HackApp
Описание бага на сайте HackApp
Ищем захардкоженные в Android-приложение креды от AWS
Отлично, у нас есть AWS_KEY . Теперь нужен еще AWS_SECRET_KEY . Давай не будем останавливаться и заглянем в «домик» разработчиков? 🙂
На сайте HackApp можно удобно посмотреть добытый AWS_ACCESS_KEY ключ
Уязвимый APK можно удобно скачать прямо с сайта HackApp. Дальше раскрываем всем известным способом:
Запускаем grep и. вуаля! Кажется, мы что-то и правда нашли:
Достали секретный AWS-ключ!
Что тут скажешь: pwned in less than 1 minute!
Комбинируя эти два инструмента и простой полнотекстовый поиск, можно вытащить еще много постыдных секретов мобильных приложений :).
Сразу предупрежу, что большинство задач, которые мы сегодня разберем, будут на PHP. Это неспроста — на нем написано подавляющее большинство сайтов и сервисов в Интернете. Так что, несмотря на испорченную репутацию этого языка, вам придется его понять, чтобы серьезно взломать. Теперь, в рамках этого урока, знание PHP необязательно, но, конечно, это будет очень серьезным подспорьем.
warning
Применение материалов этой статьи против любой системы без разрешения ее владельца преследуется по закону.
Сегодня мы разберем несколько задач, которые я решил сам в рамках тренинга. Они могут показаться вам пугающими, но пусть это не пугает вас — всегда есть возможность отточить свои навыки на специализированных хакерских сайтах.Я сейчас говорю о HackTheBox и Root-me, которыми пользуюсь сам и всячески советую другим. Две из сегодняшних задач взяты именно оттуда.
Задача 1
Сначала я приведу код, с которым мы сейчас будем работать.
По сути, тут всего три строки кода. Казалось бы, где тут может закрасться уязвимость?
Тут прямо написан ответ, как обойти защиту (подсказка: ищи справа).
Видишь точку? А шапочку ( ^ )? Та строка читается как «если в начале строки находится любое количество любых символов, кроме переноса строки, и это заканчивается слешем, удалить соответствующую часть строки».
Ключевое тут «кроме переноса строки». Если в начале строки будет перенос строки — регулярка не отработает и введенная строка попадет в include() без фильтрации.
Задача 2
В задании нам дается простой файлообменник и просят получить доступ к панели админа.
Пользовательский интерфейс очень прост: есть кнопка для загрузки файла на сервер и просмотра загруженных файлов по прямым ссылкам. Забегая вперед, скажу, что загрузка скриптов в PHP, Bash и др. бесполезна, проверки выполнены правильно, а ошибка в другом.
Обрати внимание на нижнюю часть страницы, а точнее — на фразу «frequent backups: this opensource script is launched every 5 minutes for saving your files». И приведена ссылка на скрипт, вызываемый каждые пять минут в системе.
Давай глянем на него пристальнее:
Казалось бы — что тут такого? На параметры ты влиять не можешь, а мантру призыва tar вообще знаешь как свои пять пальцев. А проблема в самой мантре: тут она написана не полностью. Точнее, не в том виде, как ее увидит сам tar.
Что делает звездочка? Вместо нее bash подставит имена всех файлов в текущей папке. Вроде ничего криминального.
А давай обратимся к мануалу на Tar, который нам любезно предоставлен вместе с условием задачи.
Теперь вспомним про звездочку: вместо нее шелл (bash) подставит список всех файлов в текущей папке, при этом они могут иметь любые имена. В том числе такие, которые будут восприняты архиватором как специальные параметры.
Таким образом, нам надо подсунуть файлы с именами в виде аргументов tar. Я использовал такие: --checkpoint=1 , --checkpoint-action=exec=sh shell.sh (пустые) и shell.sh (полезная нагрузка). В shell.sh находится следующий код:
Задача 3
Тут у нас плагин для WordPress, который позволяет запись аудио и видео.
Я не буду просить тебя найти уязвимость, а сразу покажу ее.
Как видно из строк 247–251 на скриншоте, не предусмотрено никаких проверок на тип или содержимое файла — это просто классическая загрузка!
Есть, правда, ограничение: файл грузится в стандартную директорию WordPress ( /wordpress/wp-content/uploads// ). Это значит, что листинг содержимого нам по умолчанию недоступен. А в строке 247 генерируется случайный идентификатор, который подставляется в начало имени файла, то есть обратиться к /wordpress/wp-content/uploads/2021/01/shell.php уже не выйдет. Непорядок!
Но непорядок не в том, что имя файла меняется, а в том, что делается это с помощью функции uniqid() . Обратимся к документации:
Получает уникальный идентификатор с префиксом, основанный на текущем времени в микросекундах.
Внимание. Эта функция не гарантирует получения уникального значения. Большинство операционных систем синхронизирует время с NTP либо его аналогами, так что системное время постоянно меняется. Следовательно, возможна ситуация, когда эта функция вернет неуникальный идентификатор для процесса/потока
Смекаешь? Уникальный идентификатор, полученный с помощью uniqid() , не такой уж уникальный, и это можно проэксплуатировать. Зная время вызова, мы можем угадать возвращаемое значение uniqid() и узнать реальный путь к файлу!
Так как PHP — проект открытый, мы можем подсмотреть исходники функций стандартной библиотеки. Открываем исходник uniqid() на GitHub, переходим к строке 76 и наблюдаем следующее:
Что тут происходит? А то, что возвращаемое значение зависит исключительно от текущего времени, которое в рамках одной планеты вполне предсказуемо.
Хоть выходная последовательность и выглядит случайной, она таковой не является. Чтобы не быть голословным, вот пример имени файла, сгенерированного таким алгоритмом:
Полученное значение легко можно конвертировать обратно в дату и время его генерации:
Конечно, не все реальные кейсы требуют глубоких познаний в PHP или другом серверном языке. Многие ошибки можно найти, даже не открывая код — с помощью автоматических сканеров.
Я набросал простой скрипт на Python для демонстрации такой возможности. Его код представлен ниже:
Нам нужно запустить его несколько раз, чтобы подобрать минимальное время между отправкой запроса и получением ответа — это позволит уменьшить время перебора.
Также нужно помнить, что разбежки все же могут быть, и чисто на всякий случай стоит проверить, насколько локальное время соответствует времени на сервере. Частенько оно возвращается сервером в заголовке Last-Modified и позволяет понять, какую величину коррекции внести в свои расчеты.
Как бы еще оптимизировать перебор?
Вот так на ровном месте мы сократили перебор на 200 000 запросов. Много это или мало? В моем случае это сократило количество запросов еще примерно на треть.
Осталось порядка 500 000 вариантов, которые можно перебрать в пределах часа или даже меньше — у меня это заняло минут 15.
Теперь давай напишем еще один скрипт, который и будет искать наш шелл с использованием этого алгоритма:
Вот и всё: запускаешь, через некоторое время получаешь путь, и хост захвачен!
Другой способ
Есть и способ попроще. Заключается он в следующем: новый путь к файлу формируется как <стандартная папка загрузок> + <новое имя файла> . При этом новое имя файла равно uniqid() + "_" + <имя файла от пользователя> . Валидации пользовательского имени не происходит, так что мы можем в конечном итоге заставить переместить файл по пути <папка загрузок> + <случайное значение> + "_/../shell.php" , передав в имени значение /../shell.php . Теперь наш шелл станет доступен по известному пути <путь к текущему wp-upload>/shell.php .
Задача 4
Только — вот незадача — Gobuster никаких признаков админки не обнаружил. Придется изучать, что нам доступно. А доступен логин (там форма авторизации) и ссылка на неработающий эфир
Попробуем залогиниться и перехватить запрос на авторизацию с помощью Burp.
Запрос отправляем в Repeater (повторитель). Пусть пока там полежит.
Я попробовал перейти на страницу /page_index и получил ошибку как на скрине ниже.
В первом сообщении об ошибке видна часть пути ( corp_pages/fr/index ), которая заканчивается на то же, что передано в URL после /page_ . Проверим нашу догадку — перейдем по пути /page_xakep.php .
И действительно — сайт просто подставляет параметр в путь и пытается прочитать несуществующий файл xakep.php . Пользовательский ввод подставляется в путь — значит, у нас есть возможность повеселиться на сервере!
Методом научного тыка был обнаружен параметр /?action= . Он оказался почти такой же по действию, как /page_ . Попробуем прочитать index.php в корне сайта.
Видно не все, но если открыть ответ в Burp или даже просто просмотреть код страницы браузером — открывается полный исходник. Вот тебе и directory traversal налицо.
Помнишь, мы не могли найти путь к админке? А на скриншоте он есть: именно на него будет редирект, когда скрипт проверит логин и пароль.
Взглянем поподробнее на функцию safe . Она принимает некоторую строку, экранирует спецсимволы и, опционально, удаляет спецсимволы HTML (если второй параметр равен 1). Экранирование спецсимволов делается функцией addslashes , которая без проблем обходится с помощью мультибайтовой кодировки, например китайской. Все было бы совсем радужно, если бы сервер поддерживал нужную кодировку, но, к сожалению, у нас этого нет.
Код успешно прочитан, и видна интересная функция decrypt , принимающая некую строку и ключ.
Если вы прочтете код дальше, вы увидите защиту от специальных символов в имени пользователя, затем пароль извлекается из базы данных и расшифровывается вышеуказанной функцией. Казалось бы, это так, но сначала нам нужно узнать имя пользователя, которого у нас еще нет. Забегая вперед: все ошибки этого приложения находятся в двух изученных файлах, других нет.
Теперь, чтобы эксплуатировать дальше, давай вернемся к прошлому файлу и рассмотрим его код еще раз.
Присмотрись к вызову функции хеширования: помнишь ли ты, что означает второй параметр ( true ) в функции sha1 ? Я тоже нет, так что давай посмотрим мануал:
Список параметров
Если необязательный аргумент binary имеет значение true , хеш возвращается в виде бинарной строки из 20 символов, иначе он будет возвращен в виде 40-символьного шестнадцатеричного числа.
И для этого нужно только подобрать такой символ из мультибайтовой кодировки, чтобы его последний байт был равен 5c . А в нашем случае нужно подобрать такой пароль, хеш которого заканчивался бы на 5c . Это уже проще простого — ведь мы не ограничены в том, что передаем в функцию. Я написал для этого простой скрипт на PHP.
Печально, правда, что никакого результата из запроса не выводится. Как это побороть? Использовать любые шаблоны time-based, boolean-based или error-based.
Мой любимый payload в таких случаях — AND extractvalue(1,concat(0x3a,(select version() from users limit 0,1))) . На всякий случай заменим пробелы на плюсы, подставим в поле логина в Burp и отправим запрос. Видим в ответе следующее
Инъекция работает, пусть и выводит не больше 31 символа за раз. А нам большего и не надо. Видоизменим инъекцию немного, чтобы получить логин
И теперь пароль:
Но не все так просто. Как ты помнишь, длина хеша SHA-1 в шестнадцатеричной кодировке — 40 символов, а нам вернулись 31. Непорядок! Чтобы это исправить, просто возьмем функцию right :
И вот наши последние 20 символов:
Полный хеш — e79c4da4f94b86cba5a81ba39fed083dbaf8bce5 .
Дальше нужно обойти проверки в logged.php . После некоторых упрощений и очистки его кода от мусора полезный вариант будет выглядеть так:
Это все осталось лишь обернуть в заголовки PHP и запустить — и пароль у нас в руках!
Напоминаем, что рабочий процесс — это не рутина, а творческий процесс, который определяет широту вашей мысли. Относитесь к своей работе как к новому вызову, и вы обязательно начнете получать не только удовольствие, но и вдохновение и желание развиваться. Задачи тестировщика очень многогранны: им нужно разобраться в задаче веб-приложения, понять, как оно должно работать, какие задачи решать, какие преимущества принести пользователям, а затем несколько раз перепроверить все, чтобы выпустить проект в мир. Их нужно собирать и дерзать выпускать проекты, которыми может гордиться вся команда =)
Почта, календарь, список контактов, менеджер паролей, сотни фотографий — все это хранится у нас на телефоне. Смартфон становится своеобразным ключиком ко всему: многие сервисы привязывают номер телефона для возможности восстановления пароля. При этом мы по какой-то необъяснимой причине на подсознательном уровне считаем, что все содержимое смартфона априори находится в безопасности. Худшее, что может произойти, в глазах обычного обывателя — это потеря или кража девайса. Однако на этом список угроз не заканчивается.
Мобильные приложения по сути своей мало чем отличаются от обычных. И глупо было бы говорить о том, что они более безопасны. Напротив, мобильные разработчики не сильно запариваются насчет безопасности, расставляя приоритеты в сторону функциональности и юзабилити. Программисты здесь еще не научены горьким опытом и пока мало задумываются о безопасности — главное, чтобы все хорошо работало и пользователи скачивали/покупали приложения. Поэтому нет ничего странного, что в огромном количестве приложений (в том числе банковских) кроются уязвимости — и выявляются они чаще всего простейшим анализом. Неудивительно, что безопасность мобильных приложений вызывает все больший интерес как среди злоумышленников, так и среди исследователей. Хороший пример: компания «Яндекс» в конце 2012 года добавила в конкурс «Охота за ошибками», помимо вебсервисов, свои приложения для iOS и Android. В нашей программе сегодня — разобраться с основными типами уязвимостей в мобильных приложениях для мобильной платформы Android. Но прежде — освоим матчасть.
Операционная система Android устроена таким образом, что каждое приложение запускается под специальной виртуальной машиной Dalvik. Ее отличительная особенность — низкое энергопотребление, что хорошо подходит для ARM-устройств. Программы для Android пишутся на Java (с использованием внешних библиотек на других языках благодаря расширению NDK), однако стандартный байт-код не используется. Вместо этого Dalvik использует свой формат — dex. Обычные class-файлы конвертируются в dex с помощью утилиты dx, входящей в Android SDK.
Читайте также: