Банковские веб-приложения: безопасность здесь и сейчас

- kbrbank

Банковские веб-приложения: безопасность здесь и сейчас

Отсутствие антивирусов, политик безопасности и элементарных мер обеспечения информационной безопасности (таких, например, как «смена предустановленного производителем пароля для входа в BIOS банкомата») — вправду неприемлемая обстановка для безопасности банка. Но ограничиваться лишь этими мерами запрещено: векторов атак значительно больше.

Создатель: Рами Мулейс, менеджер по продвижению продуктов PT Application Inspector и Approof, Positive Technologies

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

Об уязвимостях ДБО и интересе киберпреступников

Центробанк сказал о том, что в прошедшем сезоне число несанкционированных операций по картам сократилось, но наряду с этим часть мошеннических операций, проводимых в сети, значительно выросла. Так, мы замечаем тенденцию к перемещению заинтересованностей «карточных» мошенников из контактной инфраструктуры (банкоматы, материальные носители платежных карт) в более технологичную — совокупности дистанционного банковского обслуживания, электронные кошельки, мобильные- транзакции и интернет.

В половине изученных совокупностей ДБО (55%) нарушитель может взять контроль над СУБД и доступ к банковской тайне

Таковой сдвиг в сторону CNP-транзакций понятен: мошеннику увлекательнее воровать деньги через интернет, тем более что совокупности ДБО в большинстве собственном все еще уязвимы и эти уязвимости возможно эксплуатировать удаленно, вне территории прямого действия работ безопасности.

Уязвимость ДБО подтверждается и отечественной собственной статистикой: только в 10% изученных специалистами Positive Technologies совокупностей ДБО не было найдено критически страшных уязвимостей (наряду с этим в них были распознаны как минимум уязвимости средней степени риска).

В половине изученных совокупностей ДБО (55%) нарушитель может взять контроль над СУБД и доступ к банковской тайне; в каждой четвертой совокупности — похитить финансовые средства банка, владея пользовательским доступом к клиентскому приложению, еще в 5% случаев — сделать то же без каких-либо привилегий. Нарушитель может всецело вывести из строя совокупность ДБО, применяя контроль над ОС другие уязвимости и сервера (40% совокупностей).

Совокупности ДБО, поставляемые профильных фирмами, в среднем содержат в несколько раз больше уязвимостей, чем совокупности собственной разработки

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

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

Защита приложений как база безопасности

Новые способы взлома ДБО появляются чуть ли не каждый день, исходя из этого применение средств защиты приложений — такая же необходимость, как и наличие антивируса на рабочих станциях банка. Это находит отражение и в требованиях к безопасности, каковые выдвигает регуляторы и индустрия. К примеру, стандарт безопасности платежных карт PCI DSS в новой версии 3.0 требует снабжать защищенность приложений, проводя периодический анализ их защищенности.

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

PT Application Firewall применяет среди них и технологии «машинного обучения», разрешающие машинально строить типовую модель поведения пользователей приложения и отслеживать все отклонения от нее

Второй момент, на что обращают внимание регуляторы (и стандарт PCI DSS 3.0 в частности),— применение средств предупредительной защиты: специальных межсетевых экранов, трудящихся на уровне приложений (Web Application Firewall; WAF). Не нужно путать WAF с простым сетевым экраном: ФСТЭК России, к примеру, очевидно вводит разные типы межсетевых экранов, а также отдельный тип для экранов, защищающих приложения.

К такому типу ответов относится PT Application Firewall, сертифицированный ФСТЭК и второй год подряд попадающий в число визионеров квадрата Gartner. PT Application Firewall применяет среди них и технологии «машинного обучения», разрешающие машинально строить типовую модель поведения пользователей приложения и отслеживать все отклонения от нее, отлавливая все аномальные запросы к ДБО (от ботов до продвинутых мошенников).

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

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

Запустить приложение скоро либо безопасно?

Недавно, проводя анализ безопасности одной из платформ веб-приложений, которое обширно употребляется в сфере e-commerce, отечественные специалисты распознали в коде скрытое условие, при срабатывании которого простой пользователь приобретал права администратора приложения. Оно было в том, что хэш пароля ( посчитанный посредством не сильный метода md5) обязан соответствовать определенному значению. Другими словами в код был неявно зашит администраторский пароль, дававший доступ ко всей клиентской базе.

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

Что делать в этом случае?

Грубо говоря подходов кроме этого возможно два. Во-первых, как уже отмечалось выше, проводить постоянные аудиты перед каждым релизом приложения. Во-вторых — внедрить процессы надёжной разработки (SSDL — Secure Software Development Lifecycle).

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

Второй подход — внедрение процессов надёжной разработки, при которых сами разработчики участвуют в ходе исправления и поиска уязвимостей на этапе создания приложения, довольно давно и деятельно продвигают Микрософт, Cisco и другие ИТ-гиганты. В текущем году к данной истории подключилось и отечественное государство: создан ГОСТ Р 56939-2016 «Защита информации. Надёжная разработка ПО.

Неспециализированные положения». В качестве базы для внедрения процессов обеспечения информационной безопасности совокупностей ДБО на всех стадиях жизненного цикла смогут быть использованы выпущенные в 2014 году советы Банка России — РС БР ИББС-2.6-2014.

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

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

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

Исходя из этого действенным подходом в этом случае может стать необходимое проведение инструментального аудита на этапе приемки приложения. Для чего стоит применять решения по анализу кода, максимально автоматизированные и заточенные на поиск уязвимостей с минимальным «шумом». К примеру, PT Application Inspector машинально контролирует уязвимости приложения, применяет пара способов анализа, не ограничиваясь статическим.

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

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

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

Лекция 11: Безопасность web-приложений

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: