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

Рустэм Хайретдинов
СЕО компании Appercut Security

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

Как разрабатываются бизнес-приложения

Большинство бизнес-систем берут за основу некоторую специализированную платформу - ERP, docflow, CRM, SCM и др., - над которой с помощью встроенного языка программирования (скриптов) строится уже система, отражающая не идеальные, как заложено в платформе, а реальные процессы компании или ведомства. В некоторых случаях, особенно в государственном управлении, когда подходящую платформу сложно подобрать, приложения разрабатываются "с нуля" с использованием традиционных языков программирования.

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

Когда система поступает в промышленную эксплуатацию, на этом разработка ее не заканчивается - в этом и состоит главное отличие бизнес-приложений от системного ПО. Предприятие или ведомство - живой организм, который постоянно создает новые процессы, требующие немедленного воплощения в программном коде. Часто дописать модуль требуется так быстро, что на полноценное тестирование нет времени. Например, новая маркетинговая программа в розничной сети "купи что-то и получи что-то дополнительно" должна быть реализована в виде скрипта, загружаемого на десятки тысяч контрольно-кассовых машин, и запущена как можно скорее. Или письма от соответствующих министерств, предписывающие, как начислять зарплату сотрудникам или исчислять налоги. Не говоря о таких "стихийных бедствиях" для IT-служб, как слияние или, наоборот, разделение организаций.

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

Угрозы самостоятельной разработки бизнес-приложений

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

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

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

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

Ошибки в реализации процессов авторизации и ввода данных способны породить уязвимости приложения, которые позволят злоумышленникам получить доступ к данным и привилегии, которые не планировались при проектировании приложений. Это может, в свою очередь, привести к утечке или неправомерному изменению данных. Самые распространенные ошибки такого рода - использование вводимых пользователем данных без предварительной обработки и нормализации, в результате которой становится возможна реализация атаки класса Code Injection (например, SQL injection).

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

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

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

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

Что делать?

Опрос, проводившийся на сайте securitylab.ru, выявил, что 82% опрошенных компаний используют самостоятельно разрабатываемые или дорабатываемые бизнес-приложения, 66% признают наличие таких рисков, 13% сталкивались с проблемами злоупотребления программистов в своей компании и только 9% опрошенных что-то предпринимают для снижения таких рисков. В чем причина такого несовпадения желаемого и действительного? Ведь средств контроля кода - от ручного в лаборатории до автоматизированного с помощью мощнейших технических средств - довольно много.

Здесь есть несколько причин:

1. Психология "все плохое происходит с другими". Такой подход обычно характерен для небольших компаний с приходящими программистами. Он вызван непониманием всей полноты власти над приложением, которую имеет программист. Данные (в том числе и финансовые) и процессы (например, оплаты) полностью описываются им, а внутри компании-заказчика обычно даже нет человека, способного оценить, насколько грамотно и безопасно написана программа.
2. Большинство решений по аудиту кода рассчитаны на производителей ПО и эффективны только в случаях полного соблюдения жизненного цикла разработки (SDLC - Security Development Life Cycle). Такой цикл при разработке "для себя" является избыточным, поэтому практически никто ему не следует целиком.
3. Немаловажна также и стоимость таких средств - никто не будет ради разработки, которая стоит миллион рублей в год (два приходящих программиста) создавать и оснащать у себя лабораторию по анализу ПО стоимостью десятки миллионов рублей. Анализ бизнес-приложения в специализированной лаборатории или приглашение специалистов по аудиту кода тоже может стоить дороже разработки, а у нас не принято, чтобы "забор стоил дороже амбара". Хотя то, что "лежит в амбаре"-приложении - данные и процессы - могут стоить гораздо дороже.

Заключение

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