ВЫЯВЛЕНИЕ ФАКТОРОВ УЯЗВИМОСТИ БЕЗОПАСНОСТИ В ПРОГРАММНЫХ ИНТЕРФЕЙСАХ ПРИЛОЖЕНИЯ Российский патент 2021 года по МПК G06F11/30 G06F21/57 

Предшествующий уровень техники настоящего изобретения

[0001] Настоящее изобретение в целом относится к выявлению факторов уязвимости безопасности, более конкретно к выявлению факторов уязвимости безопасности в программных интерфейсах приложения.

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

[0003] Традиционные методы также не в состоянии устранить проблемы, связанные с доступом через проверку подлинности, кроме как используя логин и пароль или базовую проверку подлинности. Для большинства веб-приложений такого уровня проверки подлинности достаточно. Однако в случае использования API, как правило, требуется расширенная проверка подлинности, например, усложненные потоки OAuth2 в сочетании с другими требованиями для получения доступа, такими как подписи или заголовки авторизации. Из-за своей неспособности описывать или передавать такие сложные потоки проверки подлинности существующие методы не в состоянии работать на API, использование которых предполагает наличие таких потоков проверки подлинности.

[0004] Более того, существующие решения рассчитаны на нечастое использование (например, от одного раза в неделю до одного раза в год) со сканированием продолжительностью несколько дней, для инициирования которого и получения результатов требуется вмешательство человека. Такие временные рамки не согласуются с набирающей все большую популярность концепцией непрерывной доставки, для которой в день может выходить до ста новых версий программного обеспечения. Аналогично необходимость выполнения таких методов вручную исключает возможность их интегрирования в непрерывные механизмы обеспечения безопасности, основанные на мониторинге процессов обеспечения безопасности в реальном времени для реагирования на угрозы и оценки рисков.

Краткое раскрытие настоящего изобретения

[0005] Система безопасности сканирует программные интерфейсы приложений (API) для выявления факторов уязвимости. Для этого система безопасности получает документацию API от сторонней системы, связанной с API, и объединяет ее в спецификацию API, описывающую имя узла API и одну или несколько конечных точек API. Альтернативно система безопасности может генерировать спецификацию для API без получения документации API за счет перехвата трафика между API и использующим его приложением. Для каждой из конечных точек в спецификации API указывается универсальный код ресурса, метод, тип входного содержимого (если применимо), тип выходного содержимого (если применимо), сведения об авторизации, а также всевозможные связанные параметры или аргументы. Для каждого параметра конечной точки в спецификации API указывается имя параметра, является ли параметр для конечной точки обязательным или факультативным, и один или несколько допустимых типов данных его значения, а также, в соответствии с одним вариантом осуществления, пример действительного значения. Затем система безопасности выполняет задание на аудит для каждой комбинации конечных точек, потенциальных факторов уязвимости безопасности и (в некоторых вариантах осуществления) потоков проверки подлинности. Результаты заданий на аудит собираются в отчет о сканировании, в котором указываются выявленные уязвимости безопасности для сторонней системы.

[0006] В соответствии с некоторыми вариантами осуществления система безопасности также получает потоки проверки подлинности для API вместе с документацией API. Система безопасности предоставляет пользователю с правами администратора сторонней системы платформу для описания потоков проверки подлинности в виде нескольких отдельных блоков проверки подлинности, предлагаемых системой безопасности. Каждый блок проверки подлинности выполняет операцию проверки подлинности, например: добавление параметров запроса, добавление заголовков, выполнение подтверждения OAuth2, получение токена многофакторной проверки подлинности, построение подписи запроса, проксирование запроса через прокси или выполнение базовой HTTP-проверки подлинности. После этого система безопасности может получить доступ к частям API, для которых требуется проверка подлинности, используя поток проверки подлинности, и определяет уязвимости безопасности, связанные с проверкой подлинности, за счет управления блоками проверки подлинности, из которых состоит поток проверки подлинности.

Краткое описание фигур

[0007] На фиг. 1 показана структурная схема потока информации между системой безопасности и сторонней системой в соответствии с одним вариантом осуществления.

[0008] На фиг. 2 показана структурная схема системы безопасности, сообщающейся с несколькими API, в соответствии с одним вариантом осуществления.

[0009] На фиг. 3 показана блок-схема способа выполнения единичного аудита в соответствии с одним вариантом осуществления.

[0010] На фиг. 4 показана структурная схема потока проверки подлинности конечной точки API в соответствии с одним вариантом осуществления.

[0011] На фиг. 5 показана структурная схема, на которой изображены несколько примеров аудитов, которые могут быть выполнены с целью выявления факторов уязвимости проверки подлинности, в соответствии с одним вариантом осуществления.

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

Подробное раскрытие настоящего изобретения

Система и способ сканирования API

[0013] На фиг. 1 показана архитектура системы 100 безопасности в соответствии с одним вариантом осуществления. Система 100 безопасности, более подробно описанная далее, связывается со сторонней системой 200 для сканирования факторов уязвимости в API 210 сторонней системы 200. Несмотря на то, что изображена только одна сторонняя система 200, система 100 безопасности выполнена с возможностью одновременной связи с несколькими сторонними системами 200 или API 210, как описывается со ссылкой на фиг. 2.

[0014] Сторонняя система 200 образована одним или несколькими серверами, на которых располагаются API 210, и она выполнена с возможностью передачи данных в систему 200 безопасности и от нее. API 210 образован одной или несколькими конечными точками, каждая из которых указывает адресуемое расположение, которое предоставляет одну или несколько услуг, таких как выполнение подпрограммы или запрос ресурса. Конечные точки предоставляют точки соединения с API 210, которые позволяют другим системам получать доступ к его функциям и могут быть выражены, например, через универсальные коды ресурса (URI). В соответствии с некоторыми вариантами осуществления сторонняя система 200 связывается с системой 100 безопасности по сети, которая может включать любое сочетание локальных и/или глобальных сетей, с помощью проводных и/или беспроводных систем связи. В соответствии с одним вариантом осуществления работа сети обеспечивается стандартными технологиями и/или протоколами связи. Например, сеть содержит линии связи, использующие такие технологии, как Ethernet, 802.11, технология широкополосного доступа в микроволновом диапазоне (WiMAX), 3G, 4G, технология множественного доступа с кодовым разделением (CDMA), цифровая абонентская линия (DSL) и т.д. Примеры сетевых протоколов, используемых для передачи связи по сети, включают многопротокольную коммутацию по меткам (MPLS), протокол управления передачей/протокол интернет (TCP/IP), гипертекстовый транспортный протокол (HTTP), простой протокол передачи почты (SMTP) и протокол передачи файлов по сети (FTP). Обмен данными по сети можно представить с помощью любого подходящего формата, такого как язык гипертекстовой разметки (HTML) или расширяемый язык разметки (XML). Все линии связи сети или только их часть могут быть зашифрованы с помощью любой подходящей методики или методик. В соответствии с другими вариантами осуществления сторонняя система 200 может связываться с локальным экземпляром системы 100 безопасности, таким как виртуальная машина.

[0015] Система 100 безопасности содержит модуль 105 управления сканированием, хранилище 110 метаданных, хранилище 115 факторов уязвимости, модуль 120 контроля аудита, модуль 125 выполнения аудита, хранилище 130 данных о прогрессе, хранилище 135 отчетов и модуль 140 создания отчетов. В соответствии с другими вариантами осуществления система 100 безопасности может содержать дополнительные (несколько) или другие компоненты для различных приложений. Например, система 100 безопасности может дополнительно содержать веб-сервер, обслуживающий веб-страницы и управляющий ее соединением с сетью, по которой она связывается со сторонней системой 200. Стандартные компоненты, такие как сетевые интерфейсы, функции обеспечения безопасности, подсистемы балансировки нагрузки, серверы для отработки отказа, панели управления и выполнения сетевых операций и т.п. не показаны, чтобы не перегружать лишними деталями описание архитектуры системы.

[0016] Модуль 105 управления сканированием выполняет главным образом функции связи со сторонней системой 200, такие как сбор метаданных об API 210. К метаданным относятся документы, описывающие функции API 210 (далее - «документация API»), и описание одного или нескольких потоков проверки подлинности, используемых для получения доступа к API 210. В документации API описываются функции API 210 в машиночитаемом формате, таком как спецификация OpenAPI, Swagger, RAML или Blueprint. API 210 может выдавать различные разрешения пользователям различного типа (например, пользователям с правами администратора или обычным пользователям), создавая тем самым разные потоки проверки подлинности, которые предоставляют доступ к разным элементам или функциям API 210. Типы пользователей, связанные с разными потоками проверки подлинности, называются «субъектами». Подробное описание потоков проверки подлинности приводится далее со ссылкой на фиг. 4-5.

[0017] Модуль 105 управления сканированием анализирует документацию API, полученную от сторонней системы 200, и объединяет эту информацию в спецификацию API. В спецификации API описываются части документации API, связанные со сканированием, которые объединены в формат, понятный другим частям системы 100 безопасности. Информация, входящая в спецификацию API, более подробно будет описана со ссылкой на хранилище 110 метаданных. В соответствии с некоторыми вариантами осуществления спецификация API выполняется в пользовательский формат, а в соответствии с другими вариантами осуществления спецификация API выполняется в установленном формате, например, в указанных выше машиночитаемых форматах (т.е. спецификация OpenAPI, Swagger и т.п.). В соответствии с одним вариантом осуществления спецификация API выполняется в том же формате, что и документация API, а модуль 105 управления сканированием может просто использовать документацию API в качестве спецификации API.

[0018] В соответствии с некоторыми вариантами осуществления модуль 105 управления сканированием самостоятельно генерирует спецификацию API вместо того, чтобы получать документацию API от сторонней системы 200. Для этого модуль 105 управления сканированием может совершать обход веб-приложения, использующего API 210. Во время выполнения обхода модуль 105 управления сканированием перехватывает вызовы, совершаемые веб-приложением (например, через браузер). Каждый перехваченный вызов предоставляет модулю 105 управления сканированием информацию о запрошенной соответствующей конечной точке и методе, а также любых заголовках и параметрах, переданных такой конечной точке. Таким образом, предоставляемой информации достаточно для того, чтобы система 100 безопасности могла провести аудит конечных точек и параметров, которые она в состоянии перехватить. Такой способ перехвата также можно применять за пределами взаимодействий API с веб-приложениями. Например, модуль 105 управления сканированием может генерировать спецификацию для API серверной части, используя мобильное приложение на клиентском устройстве, посредством записи трафика, исходящего из клиентского устройства во время нормальной эксплуатации, например, пользователем, взаимодействующим с мобильным приложением или выполняющим функцию посредством автоматизации ввода в мобильное приложение.

[0019] Модуль 105 управления сканированием также управляет отчетами о сканировании, предоставляемыми сторонней системе 200, а в соответствии с некоторыми вариантами осуществления запрашиваемыми ею. Более подробно отчеты о сканировании описываются со ссылкой на модуль 140 создания отчетов. В соответствии с некоторыми вариантами осуществления модуль 105 управления сканированием также генерирует пользовательский интерфейс (например, на веб-странице), который сторонняя система 200 (или точнее администраторы сторонней системы 200) могут использовать для взаимодействия с модулем управления сканированием.

[0020] В хранилище 110 метаданных хранятся обработанные метаданные об API 210, такие как спецификация API и описание одного или нескольких потоков проверки подлинности. В спецификации API указывается имя узла сторонней системы 200, предоставляющей API 210, и одна или несколько конечных точек API 210. Сами по себе конечные точки представляют собой универсальные коды ресурса (URI), такие как унифицированные указатели ресурса (URL). Для каждой конечной точки в спецификации API указывается связанный URI, условие метода, тип входного содержимого, тип выходного содержимого (если применимо), сведения об авторизации и любые связанные параметры или аргументы. URI для конечных точек представляют собой обычные унифицированные указатели ресурса (URL). Сведения об авторизации могут включать информацию о прокси, один или несколько типов проверки подлинности или многофакторную проверку подлинности. Метод представляет собой условие, используемое для взаимодействия с конечной точкой. Например, условием способа является глагол HTTP (например, Get, Post, Put, Patch, Delete) для API, основанных на HTTP. Типы входного и выходного содержимого описывают ожидаемые типы входного содержимого и типы ожидаемого выходного содержимого, такие как JSON, XML, текст или HTML. Каждый параметр представляет возможное значение, используемое в конечной точке. Для каждого параметра конечной точки в спецификации API указывается имя параметра, является ли параметр для конечной точки обязательным или факультативным, и один или несколько допустимых типов данных его значения (например, строка, положительное, целое, плавающая точка, массив, логическое, перечислимое). Для параметров, разрешающих перечислимый (enum) тип данных, в спецификации API также указывается набор всех действительных значений (например, {bass, tenor, alto, soprano} или {440, 494, 523, 587, 659, 698, 784}). Дополнительно в спецификации API может указываться пример действительного значения для параметра. В соответствии с некоторыми вариантами осуществления в спецификации API указывается разная информация в зависимости от того, что актуально для сканируемого API 210. Например, спецификация для API 210, принимающего бинарные данные, может содержаться информация о, например, протоколе сериализации структурированных данных Protocol Buffers, используемом для кодирования бинарных данных.

[0021] В хранилище 115 факторов уязвимости хранится характерная для факторов уязвимости информация, используемая для выполнения отдельных заданий на аудит. В частности, в хранилище 115 факторов уязвимости могут храниться вредоносные тестовые полезные нагрузки (или команды для их построения), предназначенные для использования во время проведения аудита на наличие конкретной уязвимости. К таким факторам уязвимости может относиться утечка параметров проверки подлинности, обход авторизации, обход проверки подлинности, переполнение буфера, недостаточное подтверждение заголовка принятия, недостаточное подтверждение типа содержимого, недостаточная проверка типа, внедрение NoSQL, отраженный межсайтовый скриптинг (XSS), расщепление запроса, внедрение операторов структурированного языка запросов (SQL), подделка глагола, пропажа заголовков безопасности, внедрение внешней XML-сущности и внедрение YAML.

[0022] Модуль 120 контроля аудита выявляет количество и деталями конкретных заданий на аудит, выполняемых для сканирования, на основании спецификации API. Общее количество заданий на аудит, выполняемых в рамках одного сканирования, представляет собой декартово произведение количества конечных точек в спецификации API, количества предоставленных потоков проверки подлинности и количества факторов уязвимости, на которые проводится проверка. Например, если в API 210 нет потока проверки подлинности, проверка на уязвимость утечки параметров проверки подлинности и обход проверки подлинности проводиться не будет. Каждое задание на аудит может быть представлено в виде триады, например {уязвимости, конечной точки, субъекта}, передаваемой в модуль 125 выполнения аудита. В соответствии с некоторыми вариантами осуществления порядок заданий на аудит может задаваться по приоритету.

[0023] Модуль 125 выполнения аудита выполняет отдельные задания на аудит на API 210. Для каждого задания на аудит модуль 125 выполнения аудита генерирует тестовую полезную нагрузку, предназначенную для эксплуатации уязвимости, и записывает результаты в хранилище 135 отчетов. При необходимости модуль 125 выполнения аудита также обновляет состояния задания на аудит в хранилище 130 данных о прогрессе. В соответствии с некоторыми вариантами осуществления модуль 125 выполнения аудита выполнен в форме «рабочего пула», представляющего собой коллекцию конечного количества процессов. Каждый «рабочий процесс» в рабочем пуле выполняет только одно задание на аудит за раз. После завершения выполнения этого задания на аудит он получает следующее для выполнения, и так далее. Структура рабочего пула ограничивает потребление ресурсов и скорость сканирования, а также обеспечивает возможность распределения заданий на аудит по разным машинам или сетям. Такие способности обеспечивают мощный потенциал масштабирования в сочетании с детальными органами настройки. Более подробно задания на аудит описаны со ссылкой на фиг. 3.

[0024] Хранилище 130 данных о прогрессе представляет собой базу данных, в которую записывается состояние каждого задания на аудит во время сканирования. В частности, в хранилище данных о прогрессе содержатся сведения для каждого задание на аудит о том, было ли оно начато или нет, выполняется ли оно в текущий момент или было завершено. В хранилище 130 данных о прогрессе могут дополнительно содержаться сведения о том, что задание на аудит прошло неудачно, а также количество неудач.

[0025] Хранилище 135 отчетов представляет сбой базу данных, в которой хранятся результаты различных заданий на аудит. Результаты для каждой уязвимости, на наличие которой выполняется проверка, могут быть бинарными, например «Уязвимости не обнаружены» или «Обнаружена уязвимость». Результаты могут дополнительно содержать конкретные детали заданий на аудит, такие как используемая тестовая полезная нагрузка и время выполнения. Кроме того, результаты могут указывать на то, что конкретное задание на аудит прошло неудачно максимально допустимое количество раз для сканирования.

[0026] Модуль 140 создания отчетов генерирует и распространяет отчеты о сканировании, исходя из информации, полученной из хранилища 130 данных о прогрессе и хранилища 135 отчетов. Например, в отчете о сканировании может быть указано, какое задание на аудит было завершено, какие были получены результаты (в том числе какие факторы уязвимости были обнаружены), а также какие задания на аудит, или их подгруппу, еще необходимо завершить. Модуль 140 создания отчетов может доставлять отчеты о сканировании в файл в локальной файловой системе системы 100 безопасности или сторонней системы 200, в дистанционную пейджинговую службу или решение GRC (управление, риск и нормативно-правовое соответствие), такое как Lockpath. Модуль 140 создания отчетов генерирует отчеты о сканировании в соответствии с требованиями получателя.

[0027] Модуль 140 создания отчетов также может указывать на завершение сканирования, то есть тогда, когда все задания на аудит в хранилище 130 данных о прогрессе либо завершены, либо их выполнение не удалось (поэтому ни одно задание в текущий момент не выполняется). В соответствии с некоторыми вариантами осуществления каждый раз, когда в хранилище 130 данных о прогрессе и/или хранилище 135 отчетов поступает новая информация, модуль 140 создания отчетов генерирует новые отчеты о сканировании, в результате чего происходит доставка информации о сканировании в реальном времени.

[0028] На фиг. 1 также показан поток информации между системой 100 безопасности и сторонней системой 200 в соответствии с одним вариантом осуществления. Поток информации согласно фиг. 1 описан посредством перечисленных далее стадий с (1) по (14). На стадии (1) сторонняя система 200 подает в модуль 105 управления сканированием актуальную информацию об API 210, такую как документация API и описание ее одного или нескольких потоков проверки подлинности. Модуль 105 управления сканированием объединяет (т.е. посредством разбора) документацию API в спецификацию API, которая затем отправляется в хранилище 110 метаданных на стадии (2). На стадии (3) модуль 105 управления сканированием также отправляет информацию сканирования (такую как инициирование запуска санирования) в модуль контроля аудита. На стадиях (4) и (5) модуль 120 контроля аудита извлекает спецификацию API из хранилища 110 метаданных и информацию об факторах уязвимости, на которые будет проведена проверка из хранилища 115 факторов уязвимости, соответственно. Используя информацию о конечных точках в спецификации API, предоставленный один или несколько поток проверки подлинности и извлеченную информация об факторах уязвимости, модуль 120 контроля аудита генерирует отдельные задания на аудит, которые система 100 безопасности будет выполнять, и отправляет их в модуль 125 выполнения аудита на стадии (6). Далее на стадии (7) модуль 125 выполнения аудита выполняет задания на аудит на API 210.

[0029] Во время выполнения заданий на аудит на стадии (8) модуль 125 выполнения аудита обновляет хранилище 130 данных о прогрессе сведениями о состоянии заданий на аудит и на стадии (9) извлекает информацию о том, какие проверки необходимо снова выполнить. На стадии (10) после завершения выполнения заданий на аудит модуль 125 выполнения аудита также сохраняет результаты заданий на аудит в хранилище 135 отчетов.

Модуль 140 создания отчетов генерирует отчеты о сканировании на основании информации, извлеченной из хранилища 135 отчетов на стадии (11) и из хранилища 130 данных о прогрессе на стадии (12). Модуль 140 создания отчетов отправляет сгенерированные отчеты о сканировании в модуль 105 управления сканированием на стадии (13), иногда в ответ на подсказку от модуля 105 управления сканированием, запрашивающего отчет о сканировании. После этого на стадии (14) модуль 105 управления сканированием доставляет отчет о сканировании сторонней системе 200.

[0030] На фиг. 2 показана структурная схема системы 100 безопасности, сообщающейся с несколькими API 220a-n, в соответствии с одним вариантом осуществления. В соответствии с некоторыми вариантами осуществления система 100 безопасности выполняет несколько сканирования параллельно. Модуль 105 управления сканированием создает задания на сканирование 250a-n, каждое из которых соответствует сканированию, выполняемому на API 210a-n соответственно. Управление каждым заданием на сканирование выполняется в определенной степени независимо. Например, каждое задание на сканирование может быть связано с собственным модулем 120a-n контроля аудита и модулем 125a-n выполнения аудита (или их собственными подчастями). Другие модули, описанные со ссылкой на фиг. 1, могут быть выделены аналогичным образом. Каждый модуль 125a-n выполнения аудита содержит конечное число рабочих процессов 136a-n, 137a-n и 138a-n. Число рабочих процессов для каждого задания на сканирование 250a-n может определяться, исходя из вычислительных требований и/или ограничений системы 100 безопасности и/или сторонних систем 200, соответствующих API 210a-n. Например, сторонняя система 200 может задавать максимальную полосу пропускания для обработки, а система 100 безопасности может выбирать число рабочих процессов для выполнения сканирования таким образом, чтобы все месте они не превышали заданную максимальную полосу пропускания.

[0031] В соответствии с некоторыми вариантами осуществления сканирование единичного API 210 может быть разделено между несколькими заданиями на сканирование. Например, с момента последнего сканирования в ранее сканированный API 210 может быть добавлена некая новая конечная точка. Для новых конечных точек, по сравнению с конечными точками, сканированными ранее, может понадобиться сканирование на наличие новых (или других) факторов уязвимости, поэтому эффективнее будет разделить API 210 на конечные точки, которые уже были ранее сканированы и теперь сканируются только на наличие нескольких новых факторов уязвимости, и на новые конечные точки, сканируемые на наличие всех возможных факторов уязвимости.

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

[0033] В случае осуществления в виде распределенной сети система 100 безопасности может использовать для управления потоком запросов в API 210 алгоритмы leaky bucket (текущее ведро) или token bucket (алгоритм маркерной корзины), поскольку ограничение числа угроз для отправки запросов является неэффективным. Эти алгоритмы гарантируют системе 100 безопасности, что количество исходящих запросов соответствует и удовлетворяет требованиям, заявленным сторонней системой 200.

Способ сканирования конечных точек API

[0034] На фиг. 3 показана блок-схема способа 300 выполнения единичного задания на аудит в соответствии с одним вариантом осуществления. Стадии способа 300 необязательно должны выполняться в заявленном порядке, и в разных вариантах осуществления стадий может быть меньше, больше, или стадии могут отличаться.

[0035] Сначала система 100 безопасности идентифицирует 310 конечную точку, субъекта и уязвимость для задания на аудит. Вместе их можно обозначить как триаду {уязвимость, конечная точка, субъект}. Затем система 100 безопасности идентифицирует 320 ожидаемые входные данные для конечной точки, которые могут использоваться для корректного форматирования тестовой полезной нагрузки или эксплуатации связанных с входными данными факторов уязвимости. Система 100 безопасности генерирует 330 входные данные аудита (например, на основе тестовой полезной нагрузке), которые эксплуатируют идентифицированную уязвимость. Сгенерированные 330 входные данные аудита принимают форму действительного запроса (например, за счет выполнения форматирования и получения типа содержимого, которое ожидает конечная точка), но замещают тестовую полезную нагрузку в одном из полей. В соответствии с некоторыми вариантами осуществления система 100 безопасности учитывает отличия форматирования между конечными точками или API 210 посредством генерирования общих полезных нагрузок для такой уязвимости, и затем преобразует их в правильный формат. Таким образом система 100 безопасности может проводить единичную проверку на наличие уязвимости, которую можно применить к конечным точкам, используя разные протоколы передачи (например, JSON, XML и SOAP).

[0036] Система 100 безопасности применяет 340 входные данные аудита к конечной точке и получает выходные данные аудита. После идентификации 350 ожидаемых выходных данных для конечной точки система 100 безопасности сравнивает 360 выходные данные аудита с ожидаемыми выходными данными. Во многих случаях ожидаемые выходные данные не могут получить доступ к функциям конечной точки и/или ошибки. Если выходные данные аудита не совпадают с ожидаемыми выходными данными, задание на аудит обнаружило уязвимость. Наконец система 100 безопасности записывает 370 результат (например, о том, что обнаружена уязвимость, факторы уязвимости не обнаружены, проверка не удалась). В соответствии с некоторыми вариантами осуществления задание на аудит содержит несколько полезных нагрузок, каждая из которых обслуживает отдельный параметр конечной точки. В этом случае система 100 безопасности может только записать единичный результат (например, запись об уязвимости делается в том случае, если любые из входных данных аудита не приводят к ожидаемому исходу) или может записать отдельные результаты для каждого параметра (например, запись об уязвимости делается только для параметра, связанного с входными данными аудита, которые не привел к ожидаемому исходу).

[0037] В примере задания на аудит для уязвимости отраженного XSS система 100 безопасности выполняет поиск конечных точек API 210, которые могут принудительно реагировать на контролируемые злоумышленником данные, которые быть интерпретированы браузером как HTML. Система 100 безопасности перебирает каждый из входных векторов конечной точки (например, параметры запроса, параметры текста, параметры пути) и выполняет аудит каждого из них. Во время каждого прогона аудит система 100 безопасности строит действительный запрос для этой конечной точки, замещая значение входного вектора, для которого проводится аудит, полезной нагрузкой межсайтового скриптинга. Система 100 безопасности анализирует ответ, полученный от API 210, тем самым определяя, следует ли проводить дальнейший аудит. Если тип содержимого ответа представляет собой текст/html, в этом случае ответ будет трактоваться браузером как HTML, а конечная точка может быть уязвима для межсайтового скриптинга. Если тип содержимого ответа не указывается, а в ответе не содержится заголовок x-content-type-options со значением nosniff, в этом случае браузер может принудительно проверять ответ как HTML, а конечная точка может быть аналогично уязвима для межсайтового скриптинга. В обоих случаях система 100 безопасности проверяет, не появляется ли полезная нагрузка межсайтового скриптинга где бы то ни было в тексте ответа. Если появляется, система 100 безопасности записывает для этой конечной точки ошибку отраженного XSS.

Описание и аудит потоков проверки подлинности

[0038] Традиционно операции с потоками проверки подлинности проводят как операции с черным ящиком: на входе поступает запрос, подлинность которого не проверена, а на выходе появляется уже запрос, подлинность которого проверена. Однако система 100 безопасности предоставляет пользователям платформу для описания потоков проверки подлинности для меньших операций проверки подлинности (далее - «блоки проверки подлинности»). Благодаря этой платформе система 100 безопасности может более детально анализировать связанные с проверкой подлинности уязвимости и легче настраивает разные потоки проверки подлинности.

[0039] На фиг. 4 показана структурная схема потока 400 проверки подлинности API 210 и связанные с ней блоки 402a-n проверки подлинности в соответствии с одним вариантом осуществления. Поток 400 проверки подлинности получает запрос 410, подлинность которого не проверена, и преобразует его в запрос 420 с проверенной подлинностью, который может получать доступ к функциям связанной конечной точки. Пользователь, предоставляющий поток 400 проверки подлинности, выбирает из списка предварительно заданных блоков проверки подлинности, блоки 402a-n проверки подлинности, которые вместе представляют поток 400 проверки подлинности.

[0040] Каждый блок проверки подлинности получает входной запрос и выводит измененный запрос, так что измененный запрос, выданный последним блоком проверки подлинности в серии, является действительным запросом 420 с проверенной подлинностью. Блоки проверки подлинности могут предусматривать добавление параметров запроса, добавление заголовков, выполнение подтверждения OAuth2 (с помощью неявных клиентских учетных данных, паролей или типов выдачи кода авторизации), получение токена многофакторной проверки подлинности, построение подписи запроса, проксирование запроса через прокси и выполнение базовой проверки подлинности. В соответствии с некоторыми вариантами осуществления блоки проверки подлинности могут получать информацию от внешних систем (например, через SMS-сообщения, электронные письма) для выполнения двухфакторной проверки подлинности. Система 100 безопасности может дополнительно разрешать пользователю уточнять и добавлять пользовательские блоки проверки подлинности, представляющие функции, уже не представляемые доступными блоками проверки подлинности. За счет описания потока 400 проверки подлинности с точки зрения последовательности блоков 402a-n проверки подлинности система 100 безопасности может выполнять задания на аудит, нацеленные на конкретные аспекты потока 400 проверки подлинности, вместо того, чтобы просто нацеливаться на весь поток 400 проверки подлинности целиком.

[0041] На фиг. 5 показано несколько приведенных в качестве примера заданий 500а-с на аудит, которые могут быть выполнены для обнаружения факторов уязвимости проверки подлинности, в соответствии с одним вариантом осуществления. Приведенное в качестве примера задание 500а на аудит удаляет все блоки 402a-n проверки подлинности из потока 400 проверки подлинности для создания измененного потока 510 проверки подлинности. Когда система 100 безопасности вводит запрос 410, подлинность которого не проверена, в измененный поток 510 проверки подлинности, она ожидает, что выходные данные будут указывать на ошибку 502, что не позволит получить доступ к связанной функции API 210. Если это не так (т.е. запрос 410, подлинность которого не проверена, может получить доступ к функции конечной точки), система 100 безопасности записывает в журнал уязвимость обхода проверка подлинности.

[0042] Приведенное в качестве примера задание 500а на аудит показывает крайний пример уязвимости обхода проверки подлинности. Однако в приведенном в качестве примера задании 500b на аудит используются преимущества указанной выше платформы для описания потоков проверки подлинности, которая упрощает улавливание пропущенных факторов уязвимости обхода проверки подлинности. Приведенное в качестве примера задание 500b на аудит удаляет единичный блок 402b проверки подлинности из потока 400 проверки подлинности для создания измененного потока 520 проверки подлинности. Когда система 100 безопасности вводит запрос 410, подлинность которого не проверена, в измененный поток 520 проверки подлинности, она аналогично ожидает ошибку 502, которая не позволит получить доступ к связанной функции API 210, и записывает уязвимость обхода проверки подлинности, если этот запрос может получить доступ к такой функции. Такой тип уязвимости обхода проверки подлинности будет упущен, если система 100 безопасности не использует поток 400 проверки подлинности, описанный для блоков 402a-n проверки подлинности. Приведенное в качестве примера задание 500b на аудит также позволяет системе 100 безопасности точно определить источник уязвимости. Например, если система 100 безопасности также выполняет задания на аудит, при выполнении которого она удаляет только один из блоков 402a-n проверки подлинности, и приведенное в качестве примера задание 500b на аудит представляет собой только задание на аудит, которое успешно получает доступ к связанной функции, система 100 безопасности может уверенно указать на наличие проблемы с блоком 402b проверки подлинности, которая приведет к уязвимости обхода проверки подлинности. Система 100 безопасности может выполнять задания на аудит для всех комбинаций блоков 402a-n проверки подлинности и всех перестановок блоков 402a-n проверки подлинности, если поток проверки подлинности требует выполнения операций в определенном порядке.

[0043] Несмотря на то, что описание и аудит потоков проверки подлинности было раскрыто выше со ссылкой на API 210, эта платформа для описания и методика аудита также могут применяться к другим целям, предполагающим проверку подлинности, таким как сложные потоки проверки подлинности для веб-приложений.

Заключение

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

[0045] Местами в настоящем описании раскрываются варианты осуществления с использованием алгоритмов и символьного представления операций с информацией. Указанные описания и представления алгоритмов широко используются специалистами в области техники обработки данных, к которой относится настоящее изобретение, для наиболее эффективного пояснения принципов их работы другим специалистам в этой области техники. Эти операции, хотя они описаны функционально, вычислительно или логически, понимаются как реализуемые компьютерными программами или эквивалентными электрическими схемами, микрокодами и т.п. Более того, время от времени также оказывается удобным ссылаться на эти компоновки операций как на модули без потери общности. Описанные операции и связанные с ними модули могут быть выполнены в виде программного обеспечения, встроенного ПО, аппаратного обеспечения или любых их комбинаций.

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

[0047] Варианты осуществления также относятся к устройству для выполнения описанных в настоящем документе операций. Это устройство может быть специально выполнено для выполнения требуемых целей и/или же оно может содержать вычислительное устройство общего назначения, селективно активируемое или переконфигурируемое компьютерной программой, хранящейся на компьютере. Такая компьютерная программа может храниться в материальном энергонезависимом машиночитаемом носителе или в носителе любого типа, подходящем для хранения электронных команд, который может быть соединен с компьютерной системной шиной. Более того, любые вычислительные системы, упоминаемые в настоящем документе, могут включать единичный процессор или могут представлять собой архитектуры, в которых используются схемы с несколькими процессорами для повышения вычислительной мощности.

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

[0049] Наконец языковые формулировки, используемые в настоящем описании, выбраны главным образом так, чтобы обеспечить удобочитаемость и обучающий характер, и, вероятно, они не были выбраны для разграничения или ограничения патентных прав. Поэтому объем настоящего изобретения ограничивается только не его подробным раскрытием, а формулой изобретения, прилагаемой к настоящей заявке. Соответственно раскрытие вариантов осуществления приведено исключительно в качестве примера и не ограничивает объем правовой защиты настоящего изобретения, определенного прилагаемой формулой изобретения.

Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении возможности выявления факторов уязвимости безопасности в программных интерфейсах приложения. Способ, выполняемый компьютерной системой для автоматизации обнаружения уязвимостей безопасности программного интерфейса приложения (API), содержит: получение информации об API сторонней системы; прием потоков проверки подлинности для API; генерирование спецификации API на основании полученной информации, причем в спецификации API описываются конечные точки API; для каждой из конечных точек API, описанных в спецификации API: для каждого из потоков проверки подлинности для API: определение уязвимостей безопасности конечной точки API; для каждой определенной уязвимости безопасности выполнение задания на первый аудит для конечной точки API для определения указания на то, является ли конечная точка API уязвимой, и выполнение задания на второй аудит для потока проверки подлинности, чтобы определить указание на то, является ли поток проверки подлинности уязвимым; запись результатов выполненных первого и второго заданий на аудит; генерирование отчета о сканировании для API; отправку отчета о сканировании сторонней системе. 2 н. и 16 з.п. ф-лы, 5 ил.

1. Способ, выполняемый компьютерной системой для автоматизации обнаружения уязвимостей безопасности программного интерфейса приложения (API), причем способ предусматривает:

получение информации об API сторонней системы;

прием одного или нескольких потоков проверки подлинности для API;

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

для каждой из одной или нескольких конечных точек API, описанных в спецификации API:

для каждого из одного или нескольких потоков проверки подлинности для API:

определение на основании информации о потоках проверки подлинности для API и конечной точки API в спецификации API, одной или более уязвимостей безопасности конечной точки API;

для каждой определенной одной или более уязвимостей безопасности выполнение задания на первый аудит для конечной точки API для определения указания на то, является ли конечная точка API уязвимой для потенциальной уязвимости безопасности, и выполнение задания на второй аудит для потока проверки подлинности, чтобы определить указание на то, является ли поток проверки подлинности уязвимым для потенциальной уязвимости безопасности, причем выполнение задания на второй аудит включает изменение потока проверки подлинности в зависимости от потенциальной уязвимости безопасности путем удаления одного или более блоков проверки подлинности и тестирования измененного потока проверки подлинности; и

запись результатов выполненных первого и второго заданий на аудит;

генерирование отчета о сканировании для API на основании записанных результатов; и

отправку отчета о сканировании сторонней системе.

2. Способ по п. 1, в котором выполнение первого и второго заданий на аудит для конечной точки API предусматривает:

генерирование тестовой полезной нагрузки для эксплуатации потенциальной уязвимости безопасности для конечной точки API;

выявление ожидаемых выходных данных конечной точки API для тестовой полезной нагрузки;

применение тестовой полезной нагрузки к конечной точке API;

сравнение выходных данных конечной точки API в ответ на применение тестовой полезной нагрузки к ожидаемым выходным данным; и

определение результата задания на аудит на основании данных сравнения.

3. Способ по п. 2, в котором результат представляет собой указание на наличие уязвимости, если выходные данные конечной точки API не совпадают с ожидаемыми выходными данными.

4. Способ по п. 1, в котором получение одного или нескольких потоков проверки подлинности предусматривает:

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

5. Способ по п. 4, в котором по меньшей мере один или несколько блоков проверки подлинности выполняют одно или несколько из перечисленного далее: добавление параметров запроса, добавление заголовков, выполнение подтверждения OAuth2, получение токена многофакторной проверки подлинности, построение подписи запроса, проксирование запроса через прокси и выполнение базовой проверки подлинности.

6. Способ по п. 1, в котором по меньшей мере один или несколько потенциальных факторов уязвимости безопасности представляет собой уязвимость обхода проверки подлинности.

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

8. Способ по п. 1, в котором получение информации об API сторонней системы содержит получение документации для API.

9. Способ по п. 1, в котором получение информации об API сторонней системы содержит перехват вызова, выполняемый приложением, взаимодействующим с API.

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

получение информации об API сторонней системы;

прием одного или нескольких потоков проверки подлинности для API;

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

для каждой из одной или нескольких конечных точек API, описанных в спецификации API:

для каждого из одного или нескольких потоков проверки подлинности для API:

определение на основании информации о потоках проверки подлинности для API и конечной точки API в спецификации API, одной или более уязвимостей безопасности конечной точки API;

для каждой определенной одной или более уязвимостей безопасности выполнение задания на первый аудит для конечной точки API для определения указания на то, является ли конечная точка API уязвимой для потенциальной уязвимости безопасности, и выполнение задания на второй аудит для потока проверки подлинности, чтобы определить указание на то, является ли поток проверки подлинности уязвимым для потенциальной уязвимости безопасности, причем выполнение задания на второй аудит включает изменение потока проверки подлинности в зависимости от потенциальной уязвимости безопасности путем удаления одного или более блоков проверки подлинности и тестирования измененного потока проверки подлинности; и

запись результатов выполненных первого и второго заданий на аудит;

генерирование отчета о сканировании для API на основании записанных результатов; и

отправку отчета о сканировании сторонней системе.

11. Энергонезависимый машиночитаемый носитель данных по п. 10, в котором выполнение задания на аудит для конечной точки API предусматривает:

генерирование тестовой полезной нагрузки для эксплуатации потенциальной уязвимости безопасности для конечной точки API;

выявление ожидаемых выходных данных конечной точки API для тестовой полезной нагрузки;

применение тестовой полезной нагрузки к конечной точке API;

сравнение выходных данных конечной точки API в ответ на применение тестовой полезной нагрузки к ожидаемым выходным данным; и

определение результата задания на аудит на основании данных сравнения.

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

13. Энергонезависимый машиночитаемый носитель данных по п. 10, в котором получение одного или нескольких потоков проверки подлинности предусматривает:

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

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

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

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

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

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