Мобильное приложение журнала
Google Play Apple Store
курс цб на 08.04: USD 75.455 EUR 82.012
криптовалют: BTC 7206.2$ ETH 164.6$
lupa
Журнал ПЛАС » Архив » 2016 » ЖУРНАЛ ПЛАС № 3(226) » 653 просмотра

Жизненный цикл безопасной разработки платежных приложений

Жизненный цикл безопасной разработки платежных приложений

Кристина Андреева, инженер по защите информации компании Deiteriy, CISA, PCI QSA Интеллект и квалификация специалиста, решающего задачу взлома приложения и обхода его защитных механизмов, позволят найти неочевидные пути нарушения безопасности, невидимые для автоматических средств

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

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

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

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

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

При проведении тестирования настоятельно не рекомендуется использовать настоящие пользовательские данные, например, номера реальных платежных карт

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

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

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

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

Не следует забывать и о том, что любой работник, задействованный в процессе разработки либо тестирования приложения, должен быть обучен правилам безопасной разработки программных продуктов. Обучение специалистов должно быть регулярным, багаж знаний следует пополнять постоянно. Это могут быть специальные курсы, пособия, отраслевые практики, изучение руководств OWASP, SANS CWE, CERT Secure Coding и другие. Согласитесь, сложно написать безопасный код, если разработчик не обучен тому, как избегать общеизвестные уязвимости. Хотя наличие именно этих «глупых» ошибок в первую очередь проверяется хакерами при взломе приложения.

Тем читателям журнала «ПЛАС», кто еще не знаком с общеизвестными уязвимостями программного кода платежных приложений и не знает методов защиты от них, настоятельно рекомендуем обратиться к сайту OWASP, стандарту PA-DSS либо к разделу 6 стандарта PCI DSS. Также весьма полезными будут рекомендации Банка России, изложенные в документе РС БР ИББС-2.6-2014 «Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем.

13 ПРИНЦИПОВ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ ПРИ РАЗРАБОТКЕ ВЕБ-ПРИЛОЖЕНИЯ

Существенно повысить безопасность любого веб-приложения поможет со- блюдение как минимум следующих принципов при разработке:

1. Фильтрация всех вводимых и выводимых данных;
2. Корректная обработка ошибок;
3. Безопасная работа с оперативной памятью, файловой системой, базами данных и сетью;
4. Использование стойких криптографических алгоритмов для защиты критичных данных во всех представлениях и на всех этапах обработки;
5. Эффективное комментирование кода;
6. Запрет встраивания в код аутентификационных данных;
7. Корректное управление сессиями и защита сессионных данных;
8. Корректное управление доступом и его разграничение через ролевую модель;
9. Применение методов контроля целостности кода;
10. Обеспечение защищенного взаимодействия с внешними системами;
11. Использование модульного программирования;
12. Безопасная работа с HTTP-запросами;
13. Корректная регистрация событий.

Читайте в этом номере:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


Перейти к началу страницы

Подпишитесь на новости индустрии

Нажимая на кнопку "подписаться", вы соглашаетесь с


политикой обработки персональных данных