Все
разделы

Публикации

Бездефектного кода не бывает. Даже в банковских приложениях

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

Во многих случаях несанкционированные операции становятся возможными из-за уязвимостей в системах дистанционного банковского обслуживания — как в мобильных приложениях, так и интернет-банках. А что такое уязвимость? Это дефект, который ставит под угрозу безопасность приложения и, соответственно, безопасность обрабатываемой информации.

За последние два года мы провели оценку безопасности в общей сложности почти 200 мобильных приложений. Многие операции детектирования уязвимостей удается автоматизировать, что позволяет поставить этой деятельность на поток. На тему дефектов в коде приложений написано очень много. В данной статье мы хотим отразить не очередные теоретические изыскания, а взгляд на проблематику дефектов мобильных приложений в ракурсе информационной безопасности (ИБ). В ходе работы мы имели возможность обсудить полученные результаты оценки защищенности мобильных приложений с их разработчиками.  И это позволяло увидеть жизнь такой, какая она есть.

Итак, откуда берутся уязвимости? Можно выделить следующие причины появления «неумышленных» уязвимостей в софте:

  1. Исторически сложившаяся культура разработки. Разработчик часто не уделяет должного внимания:
    • семантическим конструкциям в языке программирования;
    • заимствованному коду, используемому в разрабатываемом ПО; по статистике наших проектов, порядка 10—20% уязвимостей появляется вместе с заимствованным кодом;
    • безопасности связей между различными модулями системы. Например, может быть очень защищенное мобильное приложение, очень защищенный сервер, а соединение между ними — уязвимое.
  2. Недостаток времени:
    • техническое задание разрабатывается в сжатые сроки, порой в нем недостаточно четко отражаются даже функциональные требования, не говоря уже о требованиях к ИБ;
    • программное обеспечение разработается быстро, и очень часто приходится «срезать углы», чтобы выпустить релиз в срок.
  3. Разработчик обычно не является экспертом в области ИБ. Даже если в редком случае требования по ИБ закладываются в техзадание, при отсутствии механизма контроля со стороны заказчика реализация этих требований оставляет желать лучшего.
  4. Практика разработки мобильных приложений имеет специфику.
  5. Мобильные приложения часто разрабатываются на заказ, а требования к функциональности дорабатываются в процессе разработки.
  6. Сфера работы для программистов — новая и стремительно развивающаяся.

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

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

Как писать код без дефектов? Если отвечать кратко, то никак…Дефекты являются неотъемлемой частью написания кода. А вот предупреждать их появление, выявлять и устранять — можно и нужно.  

Золотое правило технологии SDLC (Secure Development Lifecycle — процесс безопасного написания софта, предполагающий системный и формализованный подход к безопасности на всех стадиях жизненного цикла системы) действительно работает: безопасностью надо озадачиваться еще при проектировании приложения, закладывать требования по безопасности в техзадание и тестировать безопасность перед вводом ПО в эксплуатацию.

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

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