RU2755675C2 - Выявление факторов уязвимости безопасности в программных интерфейсах приложения - Google Patents

Выявление факторов уязвимости безопасности в программных интерфейсах приложения Download PDF

Info

Publication number
RU2755675C2
RU2755675C2 RU2019128540A RU2019128540A RU2755675C2 RU 2755675 C2 RU2755675 C2 RU 2755675C2 RU 2019128540 A RU2019128540 A RU 2019128540A RU 2019128540 A RU2019128540 A RU 2019128540A RU 2755675 C2 RU2755675 C2 RU 2755675C2
Authority
RU
Russia
Prior art keywords
api
authentication
endpoint
audit
vulnerability
Prior art date
Application number
RU2019128540A
Other languages
English (en)
Other versions
RU2019128540A (ru
RU2019128540A3 (ru
Inventor
Шейн УИЛТОН
Бенжамин Д. СЕДАТ
Энджел ИРИЗАРРИ
Майкл БОРОХОВСКИЙ
Эйнсли К. БРАУН
Original Assignee
Синопсис, Инк.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Синопсис, Инк. filed Critical Синопсис, Инк.
Publication of RU2019128540A publication Critical patent/RU2019128540A/ru
Publication of RU2019128540A3 publication Critical patent/RU2019128540A3/ru
Application granted granted Critical
Publication of RU2755675C2 publication Critical patent/RU2755675C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Computer And Data Communications (AREA)
  • Facsimiles In General (AREA)

Abstract

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

Description

Предшествующий уровень техники настоящего изобретения
[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] Наконец языковые формулировки, используемые в настоящем описании, выбраны главным образом так, чтобы обеспечить удобочитаемость и обучающий характер, и, вероятно, они не были выбраны для разграничения или ограничения патентных прав. Поэтому объем настоящего изобретения ограничивается только не его подробным раскрытием, а формулой изобретения, прилагаемой к настоящей заявке. Соответственно раскрытие вариантов осуществления приведено исключительно в качестве примера и не ограничивает объем правовой защиты настоящего изобретения, определенного прилагаемой формулой изобретения.

Claims (50)

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.
RU2019128540A 2017-03-01 2017-12-12 Выявление факторов уязвимости безопасности в программных интерфейсах приложения RU2755675C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/447,108 US11108803B2 (en) 2017-03-01 2017-03-01 Determining security vulnerabilities in application programming interfaces
US15/447,108 2017-03-01
PCT/US2017/065919 WO2018160252A1 (en) 2017-03-01 2017-12-12 Determining security vulnerabilities in application programming interfaces

Publications (3)

Publication Number Publication Date
RU2019128540A RU2019128540A (ru) 2021-04-01
RU2019128540A3 RU2019128540A3 (ru) 2021-04-01
RU2755675C2 true RU2755675C2 (ru) 2021-09-20

Family

ID=63355989

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2019128540A RU2755675C2 (ru) 2017-03-01 2017-12-12 Выявление факторов уязвимости безопасности в программных интерфейсах приложения

Country Status (6)

Country Link
US (1) US11108803B2 (ru)
GB (1) GB2573255B (ru)
IL (1) IL268789B (ru)
RU (1) RU2755675C2 (ru)
SE (1) SE1951004A1 (ru)
WO (1) WO2018160252A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2790005C1 (ru) * 2022-03-10 2023-02-14 Публичное Акционерное Общество "Сбербанк России" (Пао Сбербанк) Способ и система выявления эксплуатируемых уязвимостей в программном коде
WO2023172155A1 (ru) * 2022-03-10 2023-09-14 Публичное Акционерное Общество "Сбербанк России" Способ выявления уязвимостей в программном коде

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10754628B2 (en) * 2018-11-02 2020-08-25 Microsoft Technology Licensing, Llc Extracting web API endpoint data from source code to identify potential security threats
US11973787B2 (en) * 2019-03-13 2024-04-30 Sap Se Detecting web application vulnerabilities
US11190514B2 (en) * 2019-06-17 2021-11-30 Microsoft Technology Licensing, Llc Client-server security enhancement using information accessed from access tokens
JP7363497B2 (ja) * 2020-01-14 2023-10-18 富士通株式会社 制御方法、デバイス及び制御システム
US11265342B2 (en) 2020-07-02 2022-03-01 Qualys, Inc. Rest api scanning for security testing
US11281462B1 (en) 2020-11-13 2022-03-22 Salesforce.Com, Inc. Rule-based scoring for APIs
CN112580060B (zh) * 2021-01-21 2024-06-21 国网新疆电力有限公司信息通信公司 应用系统数据接口漏洞隐患排查系统
US11818102B2 (en) * 2021-04-16 2023-11-14 Nokia Technologies Oy Security enhancement on inter-network communication
US12028351B2 (en) 2021-11-15 2024-07-02 International Business Machines Corporation Protecting against API attacks by continuous auditing of security compliance of API usage relationship
WO2023141014A1 (en) * 2022-01-18 2023-07-27 Cisco Technology, Inc. Detecting broken object level and function level authorization issues with api services

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080209567A1 (en) * 2007-02-16 2008-08-28 Lockhart Malcolm W Assessment and analysis of software security flaws
US20110173693A1 (en) * 2007-02-16 2011-07-14 Wysopal Christopher J Assessment and analysis of software security flaws
RU2446459C1 (ru) * 2010-07-23 2012-03-27 Закрытое акционерное общество "Лаборатория Касперского" Система и способ проверки веб-ресурсов на наличие вредоносных компонент
US20120110174A1 (en) * 2008-10-21 2012-05-03 Lookout, Inc. System and method for a scanning api
US20140109227A1 (en) * 2012-10-16 2014-04-17 International Business Machines Corporation Transforming unit tests for security testing

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2446944T3 (es) * 2007-04-12 2014-03-10 Core Sdi, Incorporated Sistema, método y medio legible por ordenador para proporcionar pruebas de penetración de red
US20090158407A1 (en) * 2007-12-13 2009-06-18 Fiberlink Communications Corporation Api translation for network access control (nac) agent
KR101003598B1 (ko) 2008-12-31 2010-12-23 엔에이치엔(주) Ａｐｉ 테스트 케이스 자동 생성 방법, 그리고 이를 이용한테스트 방법
US8495748B2 (en) * 2011-02-24 2013-07-23 Red Hat, Inc. Mechanism for generating vulnerability reports based on application binary interface/application programming interface usage
US8745641B1 (en) 2011-07-14 2014-06-03 Google Inc. Automatic verification and anomaly detection in a representational state transfer (REST) application programming interface
US8656365B2 (en) 2011-09-01 2014-02-18 Infosys Limited Systems, methods, and computer-readable media for measuring quality of application programming interfaces
US9154479B1 (en) * 2012-09-14 2015-10-06 Amazon Technologies, Inc. Secure proxy
US9015730B1 (en) * 2013-12-17 2015-04-21 International Business Machines Corporation Natural language access to application programming interfaces
US10021089B2 (en) 2015-04-09 2018-07-10 Salesforce.Com, Inc. Customized user validation
CN106656907B (zh) * 2015-10-28 2021-03-02 阿里巴巴集团控股有限公司 用于认证的方法、装置、终端设备及系统
US10354066B2 (en) * 2016-02-26 2019-07-16 Cylance Inc. Retention and accessibility of data characterizing events on an endpoint computer
US10241890B2 (en) * 2016-07-28 2019-03-26 Salesforce.Com, Inc. Hybrid code modification in intermediate language for software application

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080209567A1 (en) * 2007-02-16 2008-08-28 Lockhart Malcolm W Assessment and analysis of software security flaws
US20110173693A1 (en) * 2007-02-16 2011-07-14 Wysopal Christopher J Assessment and analysis of software security flaws
US20120110174A1 (en) * 2008-10-21 2012-05-03 Lookout, Inc. System and method for a scanning api
RU2446459C1 (ru) * 2010-07-23 2012-03-27 Закрытое акционерное общество "Лаборатория Касперского" Система и способ проверки веб-ресурсов на наличие вредоносных компонент
US20140109227A1 (en) * 2012-10-16 2014-04-17 International Business Machines Corporation Transforming unit tests for security testing

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2790005C1 (ru) * 2022-03-10 2023-02-14 Публичное Акционерное Общество "Сбербанк России" (Пао Сбербанк) Способ и система выявления эксплуатируемых уязвимостей в программном коде
WO2023172155A1 (ru) * 2022-03-10 2023-09-14 Публичное Акционерное Общество "Сбербанк России" Способ выявления уязвимостей в программном коде
RU2818880C2 (ru) * 2022-08-29 2024-05-06 Федеральное государственное казенное военное образовательное учреждение высшего образования "Академия Федеральной службы охраны Российской Федерации" (Академия ФСО России) Устройство комплексной динамической оценки и обеспечения требуемой защищенности компьютерной сети

Also Published As

Publication number Publication date
SE1951004A1 (en) 2019-09-03
GB2573255B (en) 2021-10-27
US20180255089A1 (en) 2018-09-06
GB2573255A (en) 2019-10-30
RU2019128540A (ru) 2021-04-01
RU2019128540A3 (ru) 2021-04-01
IL268789B (en) 2022-04-01
US11108803B2 (en) 2021-08-31
GB201912077D0 (en) 2019-10-09
IL268789A (en) 2019-10-31
WO2018160252A1 (en) 2018-09-07

Similar Documents

Publication Publication Date Title
RU2755675C2 (ru) Выявление факторов уязвимости безопасности в программных интерфейсах приложения
Fett et al. The web sso standard openid connect: In-depth formal security analysis and security guidelines
Salas et al. Security testing methodology for vulnerabilities detection of xss in web services and ws-security
US9455997B2 (en) System and method for preventing web frauds committed using client-scripting attacks
US8875285B2 (en) Executable code validation in a web browser
CN111400722B (zh) 扫描小程序的方法、装置、计算机设备和存储介质
EP3188436A1 (en) Platform for protecting small and medium enterprises from cyber security threats
US8943599B2 (en) Certifying server side web applications against security vulnerabilities
US20150082424A1 (en) Active Web Content Whitelisting
CN111698250A (zh) 访问请求处理方法、装置、电子设备及计算机存储介质
US9336396B2 (en) Method and system for generating an enforceable security policy based on application sitemap
CN105187430A (zh) 一种反向代理服务器、反向代理系统和方法
Kumar et al. Exploring security issues and solutions in cloud computing services–a survey
Engelbertz et al. Security analysis of {eIDAS}–The {Cross-Country} authentication scheme in Europe
US12074903B2 (en) Passive detection of digital skimming attacks
Ravindran et al. A Review on Web Application Vulnerability Assessment and Penetration Testing.
US11729176B2 (en) Monitoring and preventing outbound network connections in runtime applications
CN114793171B (zh) 访问请求的拦截方法、装置、存储介质及电子装置
Gandikota et al. Web Application Security through Comprehensive Vulnerability Assessment
Vumo et al. Analysis of Mozambican websites: How do they protect their users?
Duraisamy et al. A server side solution for protection of web applications from cross-site scripting attacks
Salemi et al. " Automated rules generation into Web Application Firewall using Runtime Application Self-Protection
US20230344866A1 (en) Application identification for phishing detection
Radholm et al. Ethical Hacking of an IoT-device: Threat Assessment and Penetration Testing: A Survey on Security of a Smart Refrigerator
Häyrynen Evaluation of state-of-the-art web application vulnerability scanners