Межкорпоративый документооборот под линзой OWASP

Включение партнеров в сквозные процессы один из перспективных методов ускорения и повышения эффективности бизнеса. Все больше компаний в России начинают использовать сервисы обмена документами для налаживания межкорпоративного документооборота. Одним из тормозящих факторов как раз становятся опасения по безопасности. Сервисы ЭДО – это всегда веб-сервисы, на которые распространяются известные уязвимости. К примеру, к веб-сервисам можно применить методологию тестирования безопасности веб-приложений OWASP (Open Web Application Security Project).

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

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

OWASP предлагает возможные варианты тестирования и список наиболее критичных угроз. Ежегодно список актуализируется, некоторые угрозы из года в год находятся в топе, но появляются и новые.

Для 2017 года список ТОП10 угроз такой:

1. Внедрение кода

2. Некорректная аутентификация и управление сессией

3. Межсайтовый скриптинг (XSS)

4. Нарушение контроля доступа

5. Небезопасная конфигурация

6. Утечка критических данных

7. Недостаточная защита от атак

8. Подделка межсайтовых запросов

9. Использование компонентов с известными уязвимостями

10. Использование незащищенных API

Рассмотрим каждую из угроз как можно более кратко, чтобы у читателя появилось общее представление.

Внедрение кода

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

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

Как защищаться

Использовать специализированные библиотеки, которые обрабатывают все поступающие запросы и отбрасывают запросы, содержащие инъекции, либо дополнительно проверять поступающие запросы на наличие ключевых слов «SELECT», «INSERT» и т.п. и отклонять такие запросы.

Некорректная аутентификация и управление сессией

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

Как защищаться

Среди вариантов решения ситуации могут быть:

●    хранение и проверка IP-адреса сессии,

●    малое время жизни куки,

●    запрет на использование более одной сессии с одной и той же кукой.

Межсайтовый скриптинг

Это одна из опаснейших атак сродни внедрению кода. Тогда такую атаку еще называют HTML-инъекцией. Она возможна также в случае недостаточной обработки получаемых от пользователя данных. К примеру, если в МКДО-сервисе есть поле комментария к документу и данные этого поля не достаточно проверяются, злоумышленник может отправить документ пользователю с комментарием, содержащим специально подготовленный javaSAFEscript, который может похитить аутентификационные данные либо другую важную информацию.

Как защищаться

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

Нарушение контроля доступа

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

Как защищаться

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

Небезопасная конфигурация

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

Как защищаться

Выполнять настройку платформы или сервера в соответствии с рекомендациями по безопасности для используемого программного обеспечения. Регулярно инспектировать эти настройки и производить мониторинг безопасности инфраструктуры.

Утечка критических данных

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

Как защищаться

Любая передача любых пользовательских данных должна выполняться по зашифрованному HTTPS соединению.

Недостаточная защита от атак

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

Как защищаться

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

Межсайтовая подделка запросов

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

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

Как защищаться

●   Самый простой и довольно надежный способ – использование капчи, но это зачастую затрудняет работу пользователей.

●   Наиболее надежный способ – использование сертификата или специализированного ключа для аутентификации на сервисе.

Использование компонентов с известными уязвимостями

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

Как защищаться

●   Регулярная установка обновлений.

●   Мониторинг уязвимостей используемых компонентов.

Использование незащищенных API

Согласно отчету High-Tech Bridge «ахиллесовой пятой» большинства корпоративных сервисов является API (программный интерфейс приложения). API используется прежде всего для удобного удаленного взаимодействия с веб-сервисами. API может быть недостаточно защищён, в этом случае у злоумышленника появляется возможность быстро и с комфортом собрать информацию о сервисе, выявить узкие места, и даже получить доступ к закрытой информации.

Как защищаться

Доступ к API должен быть ограничен как минимум паролем, но лучше также предусмотреть ограничение доступа к API по IP-адресам, так сделано у большинства хостинг-провайдеров.

Вместо заключения

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

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