OWASP Mobile Top 10: подробное руководство по противодействию рискам мобильных приложений

OWASP Mobile Top 10: подробное руководство по противодействию рискам мобильных приложений
Последнее обновление 14 сентября 2020 г., Говиндрадж Басатвар, глава международного бизнеса Опубликовано 23 января 2020 г.


В разделе «Запечатывание приложений» Новости, «Запечатывание приложений» БлогOWASP Mobile Top 10: Комплексное руководство для мобильных разработчиков по противодействию рискам 23 января 2020 г. //resources.appsealing.com/4-svc/wp-content/uploads/2019/09/13145928/appsealing-new-logo-new.png, запечатывание приложений https://resources.appsealing.com/4-svc/wp-content /uploads/2020/01/02081817/owasp-to-10-mobile-application-security-risks-appsealing_new_rev.jpg200px200px 0 С экспоненциальным ростом использования мобильных приложений, и потребители находят большее удобство и простоту использования для различных видов деятельности, также увеличилось количество уязвимостей, связанных с мобильными приложениями. OWASP Mobile Top 10 - это один из таких списков, в котором подчеркиваются недостатки и уязвимости безопасности, от которых разработчики должны защищать свои приложения. Почему стоит защищать мобильные приложения? На первый взгляд, мобильные устройства и приложения могут выглядеть безопасными, поскольку они поддерживаются признанными мировыми брендами. Однако реальность гораздо менее убедительна: в ноябре 2019 года компания, занимающаяся мобильной безопасностью, провела безопасное тестирование 250 популярных приложений для Android и обнаружила, что примерно в 70% приложений произошла утечка конфиденциальных личных данных. Исследование по мошенничеству с использованием личных данных, проведенное в 2019 году компанией Javelin Strategy & Research, показало, что почти 14,4 миллиона человек стали жертвами краж личных данных в США. Большое количество этих краж происходило через взломанные учетные записи мобильных телефонов. Практически все современные приложения используют и хранят учетные данные пользователей, банковскую информацию и личную информацию для обеспечения индивидуального взаимодействия с пользователем. С появлением сложных угроз безопасности разработчикам необходимо иметь полное представление о наиболее часто возникающих и существующих угрозах. Именно здесь список OWASP Mobile Top 10 становится важным инструментом для профессионалов в области безопасности. Что такое OWASP? Основанный в 2001 году проект Open Web Application Security Project (OWASP) представляет собой сообщество разработчиков, которое создает методологии, документацию, инструменты и технологии в в области безопасности веб-приложений и мобильных приложений. Его списки 10 основных рисков представляют собой постоянно обновляемые ресурсы, нацеленные на информирование сообщества разработчиков о возникающих угрозах безопасности для веб-приложений и мобильных приложений. Вы можете посмотреть полный список проектов OWASP здесь. Что такое OWASP Mobile Top 10? OWASP Mobile Top 10 - это список, который определяет типы угроз безопасности, с которыми мобильные приложения сталкиваются во всем мире. Этот список, который последний раз обновлялся в 2016 году, представляет собой действующее руководство для разработчиков по созданию безопасных приложений с учетом передовых практик программирования. Поскольку почти 85% приложений, протестированных к настоящему моменту в безопасности, оказались подвержены по крайней мере одному из 10 рисков OWASP Top, разработчикам становится важно понимать каждый из них и применять методы кодирования, которые сводят к нулю их появление, насколько это возможно. Ниже перечислены 10 основных рисков OWASP Mobile, которые отмечены от M1 до M10. M1: Неправильное использование платформы. Этот риск связан с неправильным использованием функции операционной системы или неправильным использованием средств управления безопасностью платформы. Это может включать намерения Android, разрешения платформы, связку ключей или другие элементы управления безопасностью, которые являются частью платформы. Это обычное явление, со средней обнаруживаемостью, и может серьезно повлиять на уязвимые приложения. Несоответствующее использование платформы Риски утечка данных из-за использования намерений Android. Интенты Android - это объекты обмена сообщениями в операционной системе, которые позволяют осуществлять обмен данными между различными действиями. Эти действия включают в себя взаимодействие с фоновыми службами, доступ к данным, хранящимся на мобильном устройстве или сервере другого приложения, широковещательную рассылку сообщений во время изменения событий, запуск или завершение действия, такого как открытие браузера или другого приложения, и т. Д. Поскольку существуют бесконечные возможности использования намерений вероятность утечки данных во время обмена сообщениями также становится высокой. украсть информацию из намерений. Эти приложения могут изучать шаблоны URL-адресов или информацию о пользователе, когда она передается между легитимным приложением и другими компонентами Android. Связка ключей iOS Риск Связка ключей для iOS - это безопасное хранилище, которое позволяет мобильному пользователю создавать трудно запоминаемые пароли, а это еще больше. их сложно взломать, что делает доступ к сторонним учетным записям, таким как банковские счета и учетные записи электронной почты, на мобильных устройствах более безопасным. iOS обеспечивает шифрование Keychain "из коробки", поэтому разработчику не требуется вводить свои собственные методы шифрования. Используя списки управления доступом и группы доступа Keychain, разработчик может решить, какие приложения и данные требуют шифрования, а какие можно оставить открытыми. Если пользователь не выбирает опцию Связка ключей, он может интуитивно выбирать легко запоминающиеся пароли, которые могут быть использованы хакерами. IOS TouchID RiskiOS позволяет разработчикам использовать опцию TouchID для аутентификации своих мобильных приложений. Обход параметра TouchID делает процесс аутентификации уязвимым для попыток взлома. M1: пример неправильного использования платформы Лучшие практики для предотвращения неправильного использования платформы iOS Keychain Лучшие практики не разрешают шифрование Keychain через серверный маршрут и вместо этого хранят зашифрованные ключи только на одном устройстве, поэтому что его нельзя использовать на других устройствах или на сервере. Защитите приложение, используя Связку ключей для хранения секрета приложения, который должен иметь специальный список управления доступом. Политика аутентификации пользователей из списка управления доступом может быть реализована с помощью OS. IOS Android Intent Лучшие практики используют маршрут разрешений, чтобы ограничить, каким приложениям разрешено взаимодействовать с их приложением, тем самым практически блокируя все попытки трафика, не внесенного в белый список. Другой вариант - запретить возможность экспорта намерений для одного или всех действий, служб и приемников широковещательной передачи с платформой Android, чтобы компоненты Android, у которых нет причин для связи с приложением, изначально сохранялись. На практике эту утечку можно контролировать путем определения явных намерений, в которых объект намерения четко определен, тем самым блокируя доступ всех остальных компонентов к информации, содержащейся в намерении. Кроме того, тщательно проверьте права доступа к файлам, прежде чем делать приложение общедоступным, чтобы убедиться, что требуемые разрешения имеются. M2: Небезопасное хранилище данных. OWASP отмечает возможность использования M2 как «легкую», распространенность «обычную», обнаруживаемость «среднюю» и воздействие «серьезное». Этот риск в списке OWASP информирует сообщество разработчиков о простых способах доступа злоумышленника. небезопасные данные на мобильном устройстве. Злоумышленник может либо получить физический доступ к украденному устройству, либо проникнуть в него с помощью вредоносного ПО или перепакованного приложения. В случае физического доступа к устройству файловая система устройства может быть доступна после подключения к компьютеру. Многие бесплатные программы позволяют злоумышленнику получить доступ к каталогам сторонних приложений и содержащимся в них данным, позволяющим установить личность. Небезопасное хранилище данных рискует скомпрометировать файловую систему, в то время как очевидным недостатком скомпрометированной файловой системы является потеря личной информации пользователя, владелец приложения также может потерять из-за извлечения конфиденциальной информации приложения с помощью мобильных вредоносных программ, модифицированных приложений или судебно-медицинские инструменты. С точки зрения пользователя, такой вид компрометации данных может привести к краже личных данных, нарушению конфиденциальности и мошенничеству для отдельного пользователя и ущербу репутации, нарушению внешней политики и материальным потерям в случае бизнес-пользователей. взломанное устройство для незащищенных данных. Они включают в себя базы данных SQL, файлы журналов, хранилища данных XML, хранилища двоичных данных, хранилища файлов cookie, SD-карты и синхронизируются с облаком, что происходит в основном из-за уязвимостей, имеющихся или возникающих из-за операционной системы, фреймворков, сред компилятора, нового оборудования. , а также рутированные / взломанные устройства. Незащищенные данные Использование незащищенных данных становится возможным из-за незнания разработчиками того, как устройство хранит данные кэша, изображения, нажатия клавиш и буферы. Аналитики заметили, что отсутствие надлежащей технической документации этих процессов на уровне операционной системы и среды разработки позволяет разработчикам игнорировать эти процессы безопасности и, таким образом, давать хакерам возможность манипулировать данными или процессами на устройстве. M2: пример небезопасного хранилища данных Лучшие методы предотвращения небезопасного хранилища данных i goat iOS Для устройств iOS OWASP рекомендует использовать целенаправленно уязвимые мобильные приложения, такие как i goat, для моделирования угроз для своих приложений и фреймворков разработки. Этот процесс позволяет разработчикам понять, как API-интерфейсы работают с информационными активами и процессами приложений, такими как кэширование URL-адресов, кэширование нажатия клавиш, кэширование буфера, использование связки ключей, фоновое ведение журнала, ведение журнала, хранение данных, управление файлами cookie браузера, обмен данными с сервером и трафик, отправляемый на Android Debug Bridge Разработчики Android могут использовать оболочку Android Debug Bridge (ADB) для проверки прав доступа к файлам целевого приложения и систему управления базами данных, такую ​​как sqlite3, для проверки шифрования базы данных. ADB также предлагает такие команды, как «logcat», позволяющие разработчикам проверять журналы ошибок, содержащиеся в журналах Android, которые могут привести к утечке конфиденциальной информации пользователя или информации о безопасности вредоносному ПО. Хотя общеизвестно, что обширные журналы ошибок помогают разработчикам в процессе разработки, но, если их оставить без присмотра, эти журналы могут привести к скомпрометированному приложению или данным. Разработчик Android также должен использовать такие инструменты, как Android Device Monitor и Memory Analysis Tool, чтобы гарантировать, что в памяти устройства не будет непреднамеренных данных в течение неопределенного времени, которые могут быть использованы хакером или неавторизованным лицом, которое может получить физический доступ к устройству. . M3: Незащищенная передача данных в мобильное приложение и из него обычно происходит через оператора связи и / или через Интернет. Хакеры перехватывают данные либо как злоумышленник, находящийся в локальной сети пользователей через взломанную сеть Wi-Fi, подключаясь к сети через маршрутизаторы, вышки сотовой связи, прокси-серверы, либо используя зараженное приложение с помощью вредоносного ПО. информации из этих категорий, мониторинг трафика через взломанные или незащищенные сети Wi-Fi - самый простой способ для злоумышленника украсть информацию. Однако OWASP ожидает, что разработчики будут отслеживать весь исходящий и входящий трафик на мобильное устройство, включая TCP / IP, Wi-Fi, Bluetooth / Bluetooth-LE, NFC, аудио, инфракрасный порт, GSM, 3G, SMS и т. Д. (MITM) атаки, хотя мобильные разработчики обычно знают об использовании SSL / TLS для аутентификации, они не проверяют эти сертификаты должным образом, оставляя возможности для сетевых злоумышленников для организации атак типа «человек посередине» (MITM). Такие атаки позволяют злоумышленнику просматривать и изменять трафик, передаваемый между приложением и его сервером, и перехватывать идентификаторы сеансов. Поскольку сертификаты безопасности зависят от домена, они недоступны на тестовых серверах. Разработчики, как правило, принимают самозаверяющие сертификаты на производственных серверах при тестировании кодов. Это оставляет пробел для атак MITM, поскольку самозаверяющий сертификат ничем не хуже незашифрованного соединения или соединения с открытым текстом. В случаях, когда разработчики запрещают самозаверяющие сертификаты, злоумышленники, как правило, используют разрешающую опцию проверки имени хоста, предложенную разработчиками. Если все имена хостов разрешены, злоумышленники могут просто использовать любой действительный сертификат, выданный центром сертификации, и использовать его для получения контроля над трафиком сервера приложения. Компрометация учетной записи администратора реальная опасность атаки MITM заключается не в том, что злоумышленник крадет данные пользователя, а когда небезопасная связь допускает кражу данных учетной записи администратора. Это может привести к взлому всего веб-сайта и всех его конфиденциальных данных. Такая атака также может повлиять или украсть ключи шифрования, пароли, личную информацию пользователя, данные учетной записи, сеанс. токены, документы, метаданные и двоичные файлы. M3: пример небезопасной связи Тестеры проникновения из Rapid7 провели хакерское упражнение, чтобы выявить потенциальные лазейки в детских GPS-часах. Лучшие методы предотвращения небезопасной связи Разработчики должны включить следующие предложения от OWASP для решения проблемы небезопасной связи: M4: Небезопасная аутентификация эта проблема возникает, когда мобильное устройство не может правильно распознать пользователя и позволяет злоумышленнику войти в приложение с учетными данными по умолчанию. Обычно это происходит, когда злоумышленник подделывает или обходит протоколы аутентификации, которые либо отсутствуют, либо плохо реализованы, и напрямую взаимодействует с сервером, используя либо вредоносное ПО, которое находится на мобильном устройстве, либо ботнеты, тем самым не устанавливая прямого взаимодействия с приложением. Риски Форм-фактор ввода Небезопасные форм-факторы ввода - частый источник манипуляций на мобильных устройствах, поскольку производители приложений и мобильных платформ поощряют легкодоступные четырех- или шестизначные пароли для облегчения доступа. Помимо слабого форм-фактора ввода, ненадежный доступ в Интернет на мобильных устройствах вынуждает разработчиков применять автономный-онлайн-подход для аутентификации сеансов. невозможно правильно записывать действия пользователя. Если такой пользователь использует данные или код с устройства или передает на него и с устройства, группа безопасности не может правильно установить источник и характер атаки. Более того, небезопасная аутентификация также наносит ущерб разрешениям пользователей на устройстве, поскольку операционная система не будет точно знать, какую роль назначить пользователю, который не прошел надлежащую аутентификацию. M4: Пример небезопасной аутентификации Рекомендации по предотвращению небезопасной аутентификации внимательно изучите схему аутентификации приложения и протестируйте ее с помощью бинарных атак в автономном режиме, чтобы определить, может ли оно быть потенциально использовано. Группа безопасности должна проверить, позволяет ли приложение выполнить команду POST / GET для установления соединения с сервером без токена доступа. Успешное соединение устанавливает уязвимости в приложении. Разработчик должен убедиться, что пароли и ключи безопасности не хранятся локально на мобильном устройстве. Такие данные чрезвычайно подвержены манипуляциям. Группа безопасности должна попытаться реализовать как можно больше из следующих методов, чтобы защитить мобильное приложение от небезопасной аутентификации: M5: Недостаточные криптографические данные в мобильных приложениях становятся уязвимыми из-за слабых процессов шифрования / дешифрования или недостатков в алгоритмы, запускающие процессы шифрования / дешифрования. Хакеры могут получить физический доступ к мобильному устройству, шпионить за сетевым трафиком или использовать вредоносные приложения на устройстве для доступа к зашифрованным данным. Используя недостатки в процессе шифрования, его цель состоит в том, чтобы расшифровать данные до их первоначальной формы, чтобы украсть или зашифровать их с помощью состязательного процесса и, таким образом, сделать их бесполезными для законного пользователя. Недостаточная криптография рискует украсть данные приложений и пользователей как Android, так и iOS принудительно выполняет шифрование кодов приложений с помощью сертификатов, выпущенных доверенными источниками, которые они дешифруют в памяти устройства после проверки подписи шифрования, когда приложение вызывается пользователем. Однако многие общедоступные инструменты позволяют обойти этот метод. Эти инструменты можно использовать для загрузки приложения на взломанное устройство, его расшифровки и создания снимка расшифрованного приложения обратно в память исходного устройства перед запуском приложения пользователем. Как только приложение запускается в этом скомпрометированном состоянии, хакер может дополнительно проанализировать приложение, чтобы провести бинарные атаки или украсть данные пользователей и приложений. Любой разработчик, который полагается на процесс шифрования по умолчанию, предоставляемый операционной системой, рискует подвергнуться манипуляциям с кодом. Доступ к зашифрованным файлам многие разработчики неправильно обрабатывают ключи шифрования, что позволяет злоумышленники, чтобы получить контроль над зашифрованными файлами, даже если они были защищены с использованием наилучших возможных алгоритмов. Разработчики также склонны размещать ключи шифрования в тех же каталогах, что и зашифрованные данные. Это упрощает хакерам доступ к ключам и их использование для дешифрования. M5: пример недостаточной криптографии - лучшие практики для предотвращения недостаточной криптографии M6: небезопасная авторизация многие люди путают риск M4 с риском M6, поскольку оба они касаются учетных данных пользователя. Разработчикам следует иметь в виду, что при небезопасной авторизации злоумышленник использует уязвимости в процессе авторизации для входа в систему как законный пользователь, в отличие от небезопасной аутентификации, при которой злоумышленник пытается обойти процесс аутентификации, войдя в систему как анонимный пользователь. Авторизация рискует нерегулируемым доступом к конечным точкам администратора под риском M6: как только злоумышленник получает доступ к приложению в качестве законного пользователя, следующей задачей для него является получение административного доступа путем принудительного просмотра конечной точки, где он может выполнять команды администратора. Злоумышленники обычно используют бот-сети или вредоносные программы на мобильном устройстве для использования уязвимостей авторизации. Результатом этого нарушения безопасности является то, что злоумышленник может проводить бинарные атаки на устройство в автономном режиме. Доступ к IDOR в некоторых случаях схема авторизации позволяет злоумышленнику запускать небезопасные прямые ссылки на объекты, обычно известные под аббревиатурой IDOR, где он может получить доступ к объекту, такому как базы данных или файлы, просто предоставив вводимые пользователем данные. Такие утечки могут дестабилизировать всю операционную систему или привести к потере данных и репутации. M6: пример небезопасной авторизации - лучшие практики по предотвращению небезопасной авторизации M7: низкое качество кода риск M7 возникает из-за некачественной или непоследовательной практики кодирования, когда каждый участник разработки команда придерживается другой практики кодирования и создает несоответствия в окончательном коде или не создает достаточно документации для других. Благодатью для разработчиков здесь является то, что даже если распространенность этого риска является обычным явлением, его обнаруживаемость невысока. Хакерам нелегко изучить закономерности плохого кодирования, и им часто требуется ручной анализ, что непросто. Автоматические инструменты, которые используются для выявления утечек памяти или переполнения буфера с помощью нечеткого тестирования, могут помочь получить доступ к информации, но не позволяют легко выполнить внешний код на мобильном устройстве. Низкое качество кода рискует безопасным Веб-код, Скомпрометированный в мобильных телефонах мобильный код может поставить под угрозу защищенное в остальном приложение, которое хорошо работает в веб-браузерах, позволяя агенту угрозы отправлять ненадежные входные данные всякий раз, когда на мобильном устройстве вызываются подмножества кода. Само собой, такой мобильный код не может быть вредоносным, но, разрешая выполнение ненадежного кода на устройстве, он может серьезно скомпрометировать информацию пользователя. К типичным уязвимостям этой категории относятся утечки памяти и переполнение буфера. Пробелы в сторонних библиотеках. Разработчикам следует проявлять осторожность при интеграции популярных библиотек в свои приложения. Даже опытные игроки непреднамеренно предлагают скомпрометированные библиотеки, что создает проблему безопасности для владельцев приложений. Часто разработчики не отслеживают появление новых версий сторонних библиотек, в которых разработчик библиотеки, возможно, исправил плохой код более ранних версий, что позволяет злоумышленникам использовать приложение, которое можно легко защитить. клиенты, разработчики пишут код, который принимает все входные данные как безопасные. Такая практика может привести к атакам поставщиков содержимого, поскольку вызов поставщика содержимого может содержать конфиденциальную информацию. Злоумышленник также может позвонить поставщику контента и получить доступ к незащищенной информации. M7: Примеры плохого качества кода Лучшие практики для предотвращения плохого качества кода для мобильных устройств. Самое простое решение для решения этой проблемы - это переписать код на мобильном устройстве, а не искать для устранения проблем на стороне сервера. Разработчики Следует иметь в виду, что плохое кодирование на уровне сервера отличается от кода на стороне клиента. Проблема с кодом на стороне сервера также отразится на веб-представлении приложения, но плохое кодирование на мобильной стороне повлияет только на мобильного пользователя. Статический анализ разработчик должен постоянно использовать сторонние инструменты статического анализа для выявления утечек памяти и переполнение буфера. Команде разработчиков следует попытаться устранить несоответствие между длиной входных данных буфера и целевым буфером. Логика кода Разработчику следует избегать простой логики в кодах, поскольку она, как известно, является фаворитом хакеров как на устройствах iOS, так и на Android. Хакеры могут изменить значение в коде с помощью простой логики и обойти весь аппарат безопасности. Такие коды могут быть атакованы на уровне сборки и выполнения. Разработчик может контролировать эту утечку, не позволяя ненадежным сеансам применять привилегии на уровне устройства, и вместо этого активировать их на сервере. Также рекомендуется удерживать разрешения до тех пор, пока сеанс не будет аутентифицирован с использованием OTP, секретных вопросов или проблем. Версия библиотеки, команда разработчиков должна создать список всех сторонних библиотек, используемых в приложении, и периодически проверять их новые версии, даже если он использовал библиотеки только из надежных источников. Разработчики поставщиков контента должны рассматривать все входные данные клиента как ненадежные и проверять их независимо от того, исходят ли они из приложения или от пользователя. Им следует тщательно устанавливать флажки разрешений на входах контент-провайдера, чтобы предотвратить любой несанкционированный доступ. M8: Подделка кода Хакеры предпочитают подделку кода приложений другим формам манипуляций, поскольку это позволяет им получить неограниченный доступ к приложению, поведению пользователя или даже ко всему мобильному устройству. Они, как правило, подталкивают пользователей загружать подделанные версии популярных приложений из сторонних магазинов приложений с помощью фишинговых атак и вводящей в заблуждение рекламы. Подделка кода рискует распространением вредоносного ПО после того, как пользователю было предложено загрузить подделанное приложение, он либо загрузил и установил приложение, основной двоичный файл которого был изменен, либо был изменен пакет ресурсов. Подделанные приложения позволяют хакерам изменять системные API, чтобы разрешить выполнение вредоносного внешнего кода на мобильном устройстве. Таким образом, хакеры, как правило, занимаются двоичным исправлением, модификацией резидентного кода в устройстве, модификацией памяти и кражей данных среди прочего. Часто кража данных, дополнительные функции предлагаются в модифицированных приложениях, которых нет в исходных приложениях, поэтому это становится стимул для пользователей принять их. Распространенность подделанных приложений настолько распространена, что компании вкладывают огромные ресурсы в обнаружение и удаление дубликатов приложений из магазинов приложений и информирование пользователей о возможных сценариях кражи данных. Однако их код должен находиться в среде, за которой они не наблюдают. Хакеры также могут использовать пробелы в операционной системе, чтобы повлиять на код законного приложения. Более того, когда пользователи разрешают рутирование или взлом устройств, они сознательно создают возможности для третьих лиц манипулировать резидентным кодом на устройстве. Таким образом, разработчики не должны заключать, что любое вмешательство нежелательно. Некоторые случаи могут быть несущественными, в то время как другие могут быть преднамеренными со стороны пользователей. Но в случае финансовых или игровых приложений разработчикам нужно быть особенно осторожными. В игровых приложениях, например, подделанные функции позволяют пользователям обходить опции freemium и переходить к следующему этапу, за который в противном случае им пришлось бы платить. Благодаря такому выгодному предложению для пользователей, хакер может легко внедрить шпионское ПО в свои устройства и украсть информацию о них. M8: пример подделки кода - лучшие методы предотвращения подделки кода при обнаружении времени выполнения. Разработчик должен убедиться, что приложение может обнаруживать изменение кода во время выполнения. Если подделанное приложение хочет запускаться на устройстве с root-доступом или взломанном устройстве, а разработчик не желает разрешать выполнение такого рода, лучше всего сообщить об этом взломе на сервер во время выполнения. RASP - это один такая технология, которую разработчики могут использовать для обнаружения и предотвращения векторов атак в режиме реального времени. При изменении контрольной суммы разработчик должен использовать контрольные суммы и оценивать цифровые подписи, чтобы увидеть, имело ли место фальсификация файлов. Поскольку подделка кода и файла почти всегда изменяет значение контрольной суммы, это самый простой способ определить враждебные действия. Стирание данных гарантирует, что код приложения, ключи и данные будут стерты после обнаружения подделки. Такое положение разрушит само основание для подделки и удержит хакеров от повторного нацеливания на одно и то же приложение. M9: Обратный инжиниринг Обратный инжиниринг мобильного кода - широко распространенное явление. Хакеры, как правило, используют внешние общедоступные инструменты проверки двоичных файлов, такие как IDA Pro, Hopper, otool и т. Д., Для изучения шаблонов кода исходного приложения и его связей с серверными процессами. Обратное проектирование рискует динамической проверкой во время выполнения некоторых языков, таких как Java, .NET, Objective C, Swift - более восприимчивы к обратному проектированию, чем другие, поскольку они позволяют динамический контроль во время выполнения. Помимо прочего, реверсивный код может повлиять на безопасность серверов, данных, содержащихся на мобильных устройствах, и на способность сервера обнаруживать взломанные или рутированные устройства. Обратный инжиниринг с кражей кода может использоваться конкурентами приложения, чтобы увидеть функциональные возможности приложения в потертостях и даже скопировать некоторые особенности незаметно. Таким образом, стоимость разработки нового кода снижается. Хакеры с премиум-функциями могут использовать этот метод для доступа к премиум-функциям приложения, минуя процесс аутентификации. Игровые читы могут получить несправедливое преимущество перед своими конкурентами с помощью этого метода.M9: Примеры обратного проектирования Лучшие практики, чтобы избежать использования обратного проектирования Подобные инструменты лучший способ защитить приложение от обратного проектирования - это использовать те же инструменты, которые хакеры используют для попыток обратный инжиниринг. Если эти инструменты могут легко анализировать таблицы строк приложения, путь потока управления, взаимодействие с серверами, криптографические константы и шифры, метаданные и т. Д., Код будет скомпрометирован. Разработчики также могут использовать такой инструмент, как запечатывание приложений, для обнаружения попыток обратного проектирования в режиме реального времени. Обфускация кода процесс обфускации должен включать в себя нацеливание на определенные сегменты исходного кода, строковые таблицы и методы, которые в наименьшей степени влияют на производительность кода. Разработчик должен убедиться, что уровень обфускации, который они используют, нельзя легко изменить с помощью инструментов деобфускации, таких как IDA Pro и Hopper. При использовании языков C рассмотрите возможность использования C и C ++, которые могут в значительной степени помочь в манипуляциях во время выполнения. Многие библиотеки этих двух языков легко интегрируются с Objective C. Аналогичный подход для приложений Android будет заключаться в использовании собственного интерфейса Java. Целью использования библиотек C и C ++ является защита средств выполнения или обратного проектирования, таких как class-dump, class-dump-z, Cycript или Frida. M10: Дополнительные функции до того, как приложение будет готово к производству, команда разработчиков часто сохраняет в нем код, чтобы иметь легкий доступ к внутреннему серверу, создавать журналы для анализа ошибок или переносить промежуточную информацию и детали тестирования. Этот код не имеет отношения к функционированию приложения, то есть он не используется для предполагаемого пользователя, когда приложение находится в производстве, и требуется только во время цикла разработки. Внешняя функциональность рискует. В большинстве случаев безобидный код не дает дополнительных преимуществ злоумышленнику, получившему доступ. Однако в некоторых случаях этот код может нести информацию, связанную с базами данных, сведениями о пользователях, разрешениями пользователей, конечными точками API и т. Д., Или отключать такие функции, как двухфакторная аутентификация. M10: Пример посторонней функциональности. Рекомендации по предотвращению посторонней функциональности. Разработчик должен знать, что автоматизированные инструменты не всегда могут обнаружить наличие риска M10. Чаще всего требуется ручное вмешательство, прежде чем приложение будет отправлено в магазины приложений. Перед выпуском приложения разработчик должен предпринять следующие шаги: приложение запечатывание - это комплексное решение безопасности для мобильных приложений Android и iOS, которое может защитить их от большинства угроз OWASP Mobile Top 10. Без какого-либо кодирования разработчик может легко и быстро надежно защитить приложения, добавив уровень безопасности приложения поверх двоичного файла. Он предлагает предприятиям интуитивно понятную панель управления для анализа потенциальных угроз и попыток злоумышленников в их приложениях в режиме реального времени. Благодаря тому, что более 600 мобильных приложений успешно защищены путем запечатывания приложений, добавьте этот дополнительный уровень безопасности в свои мобильные приложения прямо сейчас! Безопасность мобильных приложений, Android, iOS, обратный инжиниринг, риски мобильных приложений, Овасп Говиндрадж Басатвар - руководитель глобального бизнеса Техническо-коммерческий евангелист, который создает, развивает и реализует четкое видение для команд. Успешно создала бизнес-модель SaaS с многомиллионными доходами во всем мире. Доказанный опыт лидерства в создании иностранных компаний в Индии со стратегией выхода на рынок, бизнес-планом, продажами и деятельностью по развитию бизнеса. Оставить комментарий Отменить ответ
RELATED ARTICLES