Не только уязвимости

Автор: Рустем Хайретдинов, заместитель генерального директора InfoWatch

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

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

Средства анализа исходного кода приложений обычно называют SAST (Static Application Security Testing), а процесс анализа – исследование методом белого ящика (whiteboxing). Большинство автоматизированных средств исследования исходного кода прежде всего фокусируется на уязвимостях. Компании-производители заслуженно гордятся количеством шаблонов (сигнатур, правил) уязвимостей, над которыми работают целые лаборатории и институты.

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

Некорректность программных конструкций может быть общая для всех программ: например, использование вводимых пользователем данных в SQL-запросах, без обработки, что может дать пользователю возможность провести атаку типа SQL-инъекция. Некорректность может быть и специфической для конкретной среды исполнения или реализации языка программирования. Она может быть и специфической для конкретного автоматизируемого приложением бизнес-процесса или архитектуры приложения. Примеров последнего типа некорректностей любой заказчик сможет привести множество:  это несоблюдение обязательного порядка действий (печать накладной только после ее занесения в базу накладных, например) или запрет на определенные операции с данными определенных таблицам (например, состояние счета клиента не может меняться в коде программы – только через интерфейс оператора или вызовом функции начисления процентов).

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

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

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

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

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

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

Каждый SDK к бизнес-платформе (1С, SAP, MS  Dynamix, Oracle EBS, IBM Lotus Notes) содержит сотни и тысячи рекомендаций – как выполнять конкретные вызовы и операции в среде этой платформы. Такие же рекомендации для безопасного web-программирования выпускает и общественная организация OWASP, а также другие независимые организации. Контроль правильности выполнения таких рекомендаций также ложится на плечи сотрудников, ответственных за приемку заказного бизнес-приложения.

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

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

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

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


Другие статьи
Поделиться:
 
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.