Журнал "Information Security/ Информационная безопасность" #3, 2018

Чтобы не допустить в будущем атаки на ваши Web-приложения, обращай- те внимание разработчиков на то, что они сохраняют, к примеру, в LOG-файлы. Вроде бы банально звучит, но это один из самых популярных ляпов в мире! В стенах компании WILD- BERRIES умение быстро меняться "на ходу" – это не ожидание, а, скорее, требо- вание. – В чем их особенно- сти? – В одном из предыдущих номеров* уже освещал тему безопасности мобильных при- ложений, но повторение в ИБ только на пользу. Общемировая практика атак на мобильные приложения показывает, что нередко "нападающий" получает воз- можность нападения за счет добытой информации из, в частности, лог- и манифест- файлов, баз данных и cook- ies-файлов, которые хранят ее в открытым виде. Периодиче- ски в лог-файлы сохраняются ошибки, содержащие инфор- мацию о типах используемого программного обеспечения на серверной стороне. Кроме того, есть случаи, когда в опи- саниях ошибок есть логин и пароль для подключения к базе данных. Попавшие в руки злоумышленника авториза- ционные cookies-файлы будут проанализированы. В лучшем случае пострадает один поль- зователь. В худшем может получиться так, что атакую- щий сможет понять механизм авторизации и при помощи подмен получить доступ к большинству личных кабине- тов пользователей, где могут храниться персональные дан- ные или, к примеру, данные для проведения оплат. Так уж сложилось, что есть несколько популярных мобильных платформ и в идеале под каждую требуется держать свою команду разра- ботчиков. Это позволит погру- зиться в особенности плат- формы. Но по факту в целях экономии на одних и тех же разработчиков могут быть воз- ложены обязанности ведения проектов на двух, а то и на трех платформах. Кроме того, нередко прибегают к исполь- зованию универсальных реше- ний, благодаря им становится возможным написание едино- го кода, который в дальней- шем будет применяться к про- екту на требуемой платформе. Все это ведет к тому, что не учитываются (или слабо учи- тываются) особенности той или иной платформы, включая набор средств безопасности, разработанных конкретно для той или иной операционной системы (далее ОС), а также рекомендации производите- лей. Для наглядности можно рассмотреть безопасное хра- нилище IOS Keychain – защи- щенное место для хранения секретных данных приложений и самой ОС. Данные о сессиях, паролях и т.п., хранящиеся не в этом хранилище, а, напри- мер, в локальном, доступны злоумышленнику. Часто разработчики остав- ляют для себя "лазейки" с бла- гими намерениями: быстро проверить тот или иной функ- ционал, посмотреть, что доступно самому привилеги- рованному пользователю без авторизации. Либо делают волшебную кнопку отключе- ния двухфакторной авториза- ции, чтобы не тратить время на вход в приложение по пол- ному циклу. И весь этот арсе- нал может стать доступным человеку, способному на атаку через приложение! Простой пример. Человек зарегистри- ровался в мобильном прило- жении, указав номер контакт- ного телефона, который при- надлежит человеку с прилич- ной суммой на счете. Через оставленную разработчиками "лазейку" отключил СМС-под- тверждение (проверку на вла- дение телефонным номером). Попросил систему восстано- вить логин и пароль по СМС. В мировой практике исполь- зования мобильных приложе- ний нередки случаи, когда решение об авторизации при- нимает приложение и сервер- ная часть доверяет этому решению. Таким образом, раз- работчики открывают двери злоумышленникам и подвер- гают систему атаке, которая именуется "небезопасная авторизация". Серверная сто- рона может быть богата на различные методы, от предо- ставления данных для отчетов до редактирования прав досту- па. Авторизовавшись в при- ложении с самыми простыми правами, для которых само же приложение и ограничива- ет набор серверных методов, атакующий подбирает вызов методов для более привиле- гированных пользователей. Что касается фальсифика- ции кода, то серверная сторо- на всегда должна с опаской относиться к запросам своей "второй половинки" – мобиль- ному приложению, ведь логику работы установленного мобильного приложения можно скорректировать в интересах злоумышленника. Более того, ранее были слу- чаи, когда оригинальные при- ложения модифицировались силами "плохих ребят" и выкладывались в официаль- ные "места раздачи". – Какие шаги необходи- мо предпринять, чтобы не допустить этого в даль- нейшем? – Заставлять изучать инфор- мацию о том, как устроена та или иная система, какие воз- можности она предоставляет и какие ограничения накла- дывает. Обязательно исполь- зовать безопасное хранилище платформы. Обращать внимание разра- ботчиков на то, что они сохра- няют, к примеру, в LOG- файлы. Вроде бы банально звучит, но это один из самых популярных ляпов в мире! Шифрование криптостойкими алгоритмами и детальная про- работка потоков сохраняемой информации в данном случае позволит минимизировать угрозы атак либо свести их к нулю. Кроме того, необходимо проверять привилегии авто- ризованного пользователя на серверной стороне на предмет возможности использовать тот или иной метод. Для готового продукта использовать защит- ный подход Оbfuscating (запу- тывание). Стоит также убедиться, что каналы передачи данных защищены. Нельзя защитить приложение, передавая информацию с использовани- ем некриптостойких алгорит- мов, и не стоит верить инфор- мации, которая передается без контрольного значения. – Что нового ожидается в ближайшее время в вашем приложении? – В этом году запустим более совершенный механизм распознавания одежды. Это когда вы фотографируете, к примеру, куртку своего зна- комого, а приложение (на основе сделанного фото) пока- зывает вам похожие куртки из каталога нашего магазина. Сейчас также запускаем проект, посредством которого клиент сможет с высокой точ- 6 • В ФОКУСЕ * Ревяшко А. Защита Web-приложений // Information Security. – 2017. – № 5. – С. 14–15.