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

- kbrbank

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

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

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

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

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

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

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

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

      Необходимо подчеркнуть, что тайные эти для каждого приложения будут разными. Разумеется, что самый «тёплый» комплект возможно встретить в банковских приложениях: логин, пароль, эти банковских карт, персональные эти.

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

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

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

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

      3 iOS приложения без которых я не могу жить.

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

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