Сегодня на 2014 год, российские компании, внедрившие продукты компании SAP потратили большое количество ресурсов на клиентскую доработку решений. Однако не привносят ли эти разработки дополнительные риски в ваши бизнес-процессы? Компания SAP гарантирует качество кода в своих приложениях благодаря ручному аудиту поставляемого кода и использованию самых современных механизмов статического и динамического анализа своих продуктов на различные уязвимости. Автор этих строк провел исследование в университете г. Саарбрюккен (Германия) целью которого являлся анализ кодов продуктов SAP (решения по электронной коммерции) самыми современными инструментами статического анализа и убедился в высоком качестве этого кода. Программный код компании SAP проходит ручной и автоматизированный анализ, тысячи специальных тест-кейсов. Клиентский программный код зачастую не может быть так полно проанализирован, особенно, в условиях сжатых сроков проектов, в которых приходится работать. Стоит задуматься о качестве клиентского кода в ваших системах. Важно понимать, что проверка авторизации пользователя (синоним безопасности SAP для многих предприятий) не поможет предотвратить использование такого рода ошибок, т.к. пользователь, использующий ошибки в коде, выходит за рамки полномочий, определенных системным администратором.
Рассмотрим ошибки, которые могут присутствовать в клиентском коде.
Инъекция кода
Оставленная возможность инъекции кода – одна из самых распространенных и самых опасных уязвимостей по классификации OWASP. Большинство широко известных уязвимостей, включая OpenSSL Heartbleed (29.04.2014) и взлом площадки Ebay (22.05.2014) связаны с непреднамеренно оставленной возможностью инъекции пользовательского ввода внутрь программы. Опасность такого рода ошибок заключается в практически непредсказуемых результатах исполнения уязвимых программ. Результатом инъекции SQL кода может быть как утечка паролей, так и полное удаление всех данных системы. Дополнительная проблема, связанная с такими уязвимостями заключается в сложности их поиска автоматизированными средствами. Поиск на основе правил и паттернов не даст положительного результата из-за большого количества ошибочно сформулированных предположений. Единственным по-настоящему эффективным способом поиска ошибок может быть статический анализ потока данных, поступающего в программу (Information Flow Control). Статический анализ потока данных позволяет проследить, какие данные поступают в потенциально опасные точки и выдвинуть наиболее точные предположения о наличии или отсутствии уязвимости инъекции кода.
Обход каталога
Другой опасной ошибкой программного кода является непреднамеренно оставленная возможность подмены данных ввода, которая позволяет обход каталога. Атакующий, использующий такую уязвимость получает возможность считывать или записывать данные, находящиеся вне предопределённого каталога. Таким образом, могут быть считаны критичные системные настройки или перезаписаны конфигурационные файлы, что может вывести систему из строя на достаточно долгий промежуток времени. Возможны достаточно специфические варианты использования этой ошибки. Например, вызов оператора OPEN DATASET dset FILTER iv_filter, открывающего файл на чтение, в системе Unix поставляет данные из считываемого файла в предопределённый процесс, который может осуществлять непредусмотренные действия на уровне операционной системы. Таким образом, некорректная конфигурация ОС и уязвимый код, не имеющие ошибок по отдельности, могут приводить к критичным последствиям работая совместно. О проблемах некорректных конфигураций вы узнаете в наших следующих статьях.
Ошибки авторизации
Руководствуются ли ваши программисты концепцией полномочий в разработке своих приложений? В соответствии с этой концепцией, доступ к любому функциональному блоку программы должен быть запрещен до тех пор, пока не определено обратное. К сожалению, на многих проектах, разграничение доступа происходит на уровне транзакций, что делает возможным комбинирование различных существующих полномочий с целью доступа к запрещенной информации. Например, использование оператора CALL TRANSACTION (который массово используется разработчиками) на проектах с разграничением доступа на уровне транзакций является небезопасным. Без указания WITH AUTHORITY-CHECK оператор CALL TRANSACTION позволяет переходить по любой другой транзакции. Возможен также случай, когда проверка авторизации есть, но сделана она неправильно. Такие случаи также нужно находить и исправлять.
Бэкдоры
До этого мы рассмотрели некоторые случаи уязвимостей, когда программисты совершили непреднамеренные ошибки, в результате чего код стал уязвимым. Однако, возможны также и случаи, когда программист намеренно изменяет ход исполнения программы для определенных пользователей («недокументированные возможности»), либо вообще оставляет так называемый бэкдор, который позволяет обходить все проверки, выставленные системой. Разработчик может делать бэкдор и без злонамеренных целей, как например получение полномочий SAP_ALL для более «эффективной» работы на проекте внедрения. Очевидно, что это не умоляет тех рисков, которые привносит наличие бэкдоров. В сети существует большое количество примеров таких бэкдоров, которые могут быть просто скопированы и перенесены в продуктивную систему. Отловить наличие недокументированных возможностей и бэкдоров очень сложно, во-первых из-за огромного количества клиентского кода, во-вторых из-за особенностей языка программирования SAP. ABAP позволяет исполнять код на лету и хранится в СУБД, т.е. может быть запрятан очень и очень глубоко.
Как искать ошибки?
Существует несколько различных способов поиска уязвимостей в коде, наиболее совершенным из которых является статический анализ потока данных. В SAP Netweaver AS присутствует модуль, реализующий анализ потока данных на наличие или отсутствие уязвимостей (Code Vulnerability Analysis). Есть сертифицированные партнерские решения, позволяющие сканировать код приложений на наличие уязвимостей. SAP Code Vulnerability Analysis (CVA) основан на инструменте Code Inspector, который уже много лет позволяет проверять клиентский код на наличие потенциально опасных конструкций, но в отличие от Code Inspector, использует в своей работе анализ потока данных. Наиболее целесообразным является использование CVA с первой же стадии проекта – со стадии разработки (до переноса разработок далее по ландшафту), т.к. внесение исправлений позже (например, при продуктивной эксплуатации) является более сложным и затратным. Внедрение CVA подразумевает не только поиск и исправление ошибок, но изменение самого подхода к стандартам разработки на предприятии. Внесение любой новой разработки в продуктивную систему должно быть санкционировано экспертом, руководствующимся в своей работе самыми современными инструмента анализа разработок.
Итог
Этой статьей мы хотели показать, что вопросы безопасности продуктов SAP намного более широки, чем это зачастую представляется нашим клиентам. Важно четко представлять себе весь спектр проблем, которые могут возникать при поддержке решений на базе SAP. Для этого нужно быть в курсе текущего состояния дел, об этом мы и будем рассказывать вам в рамках цикла статьей.
Автор: chdan
